CVE-2026-77076: n8n: GraphQL error leaks decrypted credential secret
HIGHA flaw in n8n's GraphQL node causes connection-level errors to be stored unmodified in workflow execution history, and those raw errors include the decrypted credential secret pulled straight from the live request's headers. Any authenticated user who can view the resulting execution record — not just the workflow owner — can pull the plaintext credential out of stored run data with no exploit tooling and no special skill, which is why this rates high severity despite the low technical bar. n8n itself carries meaningful supply-chain weight here: 16 downstream dependents, a package risk score of 69/100, an OpenSSF Scorecard of 6.6/10, and 201 other CVEs already on record, and it's frequently used to orchestrate AI agents and LLM API calls, so the leaked secret is often a high-value AI service key rather than a throwaway credential. There is no CISA KEV listing, no public exploit, and no Nuclei template, so this is not a mass-exploitation scenario today — it's an insider-risk and access-control problem. Patch to 1.123.69, 2.33.4, or 2.34.1 immediately, then audit stored execution logs for any past GraphQL node connection failures and rotate every credential ever attached to a GraphQL node.
What is the risk?
Rated high severity and driven entirely by CWE-209 (information exposure through error messages) rather than by exploitation complexity — there is no privilege escalation or code execution required, just the ability to view a workflow's execution history, which in many n8n deployments is granted to broad sets of authenticated collaborators. There is no evidence of active exploitation (not in CISA KEV, no SSVC decision, no public PoC or Nuclei template, EPSS unavailable), so this is not an imminent mass-scanning target, but the trivial exploitation path (trigger a connection error, read the stored execution) combined with n8n's poor security track record (201 other CVEs, Scorecard 6.6/10) and its role as an AI agent orchestration hub elevates real-world risk well above what the missing CVSS score alone suggests.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | — | No patch |
Do you use n8n? You're affected.
How severe is it?
What should I do?
1 stepUpgrade n8n to 1.123.69, 2.33.4, or 2.34.1 immediately, where the GraphQL node wraps connection-level errors in n8n's standard error type instead of re-throwing the raw HTTP client error. Until patched, restrict execution-log read access to the minimum necessary users/roles for any workflow containing a GraphQL node, and treat any credential ever used in a GraphQL node as potentially exposed — rotate it. Audit historical execution data (including exports and backups) for GraphQL node failures and scan stored error payloads for header-like strings resembling API keys, bearer tokens, or authorization values. Going forward, monitor GraphQL node executions for connection-level failures as a detection signal, since a spike in such failures on a given credential may indicate an attacker deliberately forcing errors to harvest secrets.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-77076?
A flaw in n8n's GraphQL node causes connection-level errors to be stored unmodified in workflow execution history, and those raw errors include the decrypted credential secret pulled straight from the live request's headers. Any authenticated user who can view the resulting execution record — not just the workflow owner — can pull the plaintext credential out of stored run data with no exploit tooling and no special skill, which is why this rates high severity despite the low technical bar. n8n itself carries meaningful supply-chain weight here: 16 downstream dependents, a package risk score of 69/100, an OpenSSF Scorecard of 6.6/10, and 201 other CVEs already on record, and it's frequently used to orchestrate AI agents and LLM API calls, so the leaked secret is often a high-value AI service key rather than a throwaway credential. There is no CISA KEV listing, no public exploit, and no Nuclei template, so this is not a mass-exploitation scenario today — it's an insider-risk and access-control problem. Patch to 1.123.69, 2.33.4, or 2.34.1 immediately, then audit stored execution logs for any past GraphQL node connection failures and rotate every credential ever attached to a GraphQL node.
Is CVE-2026-77076 actively exploited?
No confirmed active exploitation of CVE-2026-77076 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-77076?
Upgrade n8n to 1.123.69, 2.33.4, or 2.34.1 immediately, where the GraphQL node wraps connection-level errors in n8n's standard error type instead of re-throwing the raw HTTP client error. Until patched, restrict execution-log read access to the minimum necessary users/roles for any workflow containing a GraphQL node, and treat any credential ever used in a GraphQL node as potentially exposed — rotate it. Audit historical execution data (including exports and backups) for GraphQL node failures and scan stored error payloads for header-like strings resembling API keys, bearer tokens, or authorization values. Going forward, monitor GraphQL node executions for connection-level failures as a detection signal, since a spike in such failures on a given credential may indicate an attacker deliberately forcing errors to harvest secrets.
What systems are affected by CVE-2026-77076?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration / automation pipelines, credential vaults.
What is the CVSS score for CVE-2026-77076?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0055Unsecured CredentialsAML.T0098AI Agent Tool Credential HarvestingCompliance Controls Affected
What are the technical details?
Original Advisory
n8n versions before 1.123.69, 2.33.4, and 2.34.1 contain an information disclosure vulnerability in the GraphQL node. When a GraphQL request fails at the connection level, the node re-throws the underlying HTTP client error unchanged instead of wrapping it in n8n's standard error type. That error contains the live request's headers, including a decrypted credential secret, which the execution engine persists verbatim. Any authenticated user able to read the resulting execution can retrieve the decrypted credential secret from the stored run data.
Exploitation Scenario
An authenticated but low-privileged n8n user (e.g., a team member with view access to a shared workflow, or a contractor with limited scope) identifies a workflow that uses the GraphQL node to call an AI vendor's API. They reconfigure or trigger the node against an unreachable or malformed endpoint — pointing it at a dead host, an invalid port, or a TLS-broken URL — causing a connection-level failure. n8n's execution engine stores the resulting HTTP client error verbatim, including the decrypted API key embedded in the request's Authorization header, inside the execution record. The attacker simply opens that execution in the UI or via the API, reads the credential secret out of the stored error payload, and reuses it to access the AI provider's API directly — bypassing n8n entirely, incurring costs, exfiltrating data, or pivoting into other systems that trust the same credential.
Weaknesses (CWE)
CWE-209Generation of Error Message Containing Sensitive InformationPrimaryCWE-209Generation of Error Message Containing Sensitive InformationCWE-209 — Generation of Error Message Containing Sensitive Information: The product generates an error message that includes sensitive information about its environment, users, or associated data.
- [Implementation] Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- [Implementation] Handle exceptions internally and do not display errors containing potentially sensitive information to a user.
Source: MITRE CWE corpus.
References
- github.com/n8n-io/n8n/security/advisories/GHSA-9fqj-7wc5-cwhxvendor-advisory
- vulncheck.com/advisories/n8n-before-credential-leak-via-graphql-node-errorthird-party-advisory
Timeline
Related Vulnerabilities
CVE-2026-3366310.0n8n: member role steals plaintext HTTP credentials
Same package: n8nCVE-2026-3366010.0TensorFlow: type confusion NPD in tensor conversion
Same package: n8nCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same package: n8nCVE-2026-275779.9n8n: Code Injection enables RCE
Same package: n8nCVE-2026-274959.9n8n: Code Injection enables RCE
Same package: n8n