CVE-2026-77081 is a high severity (7.1 in the record) allowed-domains bypass in n8n's GraphQL node. With two credentials attached and expression mode on, only the first credential's domain policy is enforced, so another can be sent to an attacker's endpoint. Upgrade to 1.123.69, 2.33.4 or 2.34.1 or later.
What's affected
The record says n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 are affected. GitHub's advisory lists the same range and says the patched versions are 1.123.69, 2.33.4 and 2.34.1 or later.
The component is the GraphQL node's Authentication parameter. Exploitation needs workflow-authoring rights, two credentials of different types on the node, and the parameter set to expression mode. The impact is limited to the permissions of the leaked credential.
Where sources differ. The advisory scores this Moderate 5.1 on CVSS 4.0, and the record's CVSS 3.1 score is different, so the two numbers describe the same flaw through different scoring models. The record also says the range is 2.x before 2.33.4 and 2.x before 2.34.1, which reads as the same two lines the advisory names.
How to check if you're exposed
Find every n8n instance, including ones a team stood up on its own, and print the version:
n8n --version
docker exec <container> n8n --version
npm ls -g n8n
The first works where the CLI is installed, the second for a Docker container, the third for a global npm install. Compare with the patched versions: 1.123.69 on the 1.x line, 2.33.4 on 2.33, and 2.34.1 on 2.34. Also audit GraphQL nodes where the Authentication parameter is set by expression.
GitHub lists these temporary mitigations in the advisory:
- Restrict n8n instance access to fully trusted users only.
- Audit existing workflows for GraphQL nodes where the Authentication parameter is in expression mode with multiple credentials attached, and remove or reconfigure them.
- Restrict network egress from the n8n host, to prevent connections to attacker-controlled endpoints.
GitHub is clear that they do not fully remediate the risk and are short-term measures. A dependency scan is the quickest way to find this kind of component across many projects. Safeguard's free in-browser scan at gold.safeguard.sh/scan checks your dependencies against known CVEs, and reachability analysis helps you separate libraries your code actually calls from ones that only sit in the tree.
What to do now
- Upgrade n8n to 1.123.69, 2.33.4, or 2.34.1 or later, whichever matches your release line.
- Until you can, apply the advisory's temporary mitigations, which GitHub says reduce risk without fully fixing it.
- Review who has accounts on the instance and what role each holds. Remove people who do not need access.
- Look through existing workflows for the feature involved, and confirm nothing unexpected has been added.
- Re-check the version afterward and record it.
Why it matters
n8n credentials can carry an allowed-domains list so a key cannot be sent to the wrong host. In expression mode, every authentication-gated credential selector on the GraphQL node counted as active. With two credentials of different types attached, the node looked up the domain policy of only the first while still attaching material from both. A restricted credential could therefore reach a host its list should have blocked. The record files it under CWE-639.
Severity here is a place where sources differ: the record says 7.1 High, while GitHub's advisory calls it Moderate at 5.1. The practical fix does not depend on which you believe. Egress filtering is the control that would have limited it, and it is worth having for every automation host. The record does not mark it as a CISA KEV entry.
Quick check
How serious is it?
The record says 7.1 High and GitHub's advisory says Moderate, 5.1. The impact is limited to the leaked credential's permissions, and it needs workflow-authoring rights.
What helps besides patching?
Restricting network egress from the n8n host, so a credential cannot be sent to an unknown endpoint.
Sources
Last reviewed: 18 October 2026.
