GHSA-6qc9-mqvw-jg7x: n8n authz bypass exposes shared

Q: Is GHSA-6qc9-mqvw-jg7x actively exploited?

No confirmed active exploitation of GHSA-6qc9-mqvw-jg7x has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-6qc9-mqvw-jg7x?

Patch to n8n 1.123.67, 2.31.5, or 2.32.1 or later — this is the only complete fix. If immediate patching isn't possible: disable the HTTP Request node instance-wide by adding n8n-nodes-base.httpRequest to the NODES_EXCLUDE environment variable (breaks workflows that rely on it); restrict instance access to fully trusted users only, since exploitation requires an authenticated account with workflow edit rights; and audit existing credential sharing plus workflow membership to identify who can reach which credential IDs today. For detection, review audit/execution logs for HTTP Request node executions referencing credential IDs outside a user's normal working set, and rotate any credential that was shared into a workflow accessible to users outside its original owner group as a precaution.

Q: What systems are affected by GHSA-6qc9-mqvw-jg7x?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow/automation orchestration, credential and secrets management for AI integrations.

Q: What is the CVSS score for GHSA-6qc9-mqvw-jg7x?

No CVSS score has been assigned yet.

CISO Take

A flawed permission check in n8n lets any workflow editor swap in another user's stored credential inside an HTTP Request node simply by supplying the credential type through an expression instead of a literal value, since the pre-execution ownership check compared the unresolved expression rather than the real credential type and silently let the wrong credential load at runtime. n8n sits at the center of many AI automation stacks — chaining LLM API keys, cloud secrets, and database credentials into agent workflows — so this bug turns a routine 'give a teammate edit access' decision into a path for stealing every credential in the shared workspace, provided the attacker can discover the credential ID. There's no public exploit or CISA KEV listing yet and exploitation requires an authenticated account with edit rights, which caps the blast radius to insiders and compromised low-privilege accounts rather than anonymous internet attackers. Still, with 16 downstream dependents and 166 other CVEs already recorded against n8n, this is a heavily used, heavily scrutinized package, so treat any instance with broad workflow-sharing as exposed until patched. Upgrade to 1.123.67, 2.31.5, or 2.32.1 immediately; if that's not possible today, exclude the HTTP Request node via NODES_EXCLUDE and audit who has edit access to shared workflows and which credentials they can reach.

Sources: GitHub Advisory ATLAS OpenSSF

What is the risk?

High severity, low complexity to exploit once inside, but exploitation requires an authenticated account with edit access to a shared workflow plus knowledge of the target credential's identifier — this is a privilege-escalation / lateral-movement bug for insiders and compromised accounts, not an unauthenticated remote attack surface. No public PoC, no Nuclei template, and not listed in CISA KEV, so opportunistic scanning-based exploitation is unlikely; the realistic threat model is a malicious or compromised internal user (contractor, disgruntled employee, or an account taken over via credential stuffing/phishing) pivoting from workflow-edit access to credential theft. Given n8n's role as connective tissue in AI agent stacks — often holding LLM API keys, vector DB tokens, and cloud provider secrets — a successful exploit can cascade into broader AI supply-chain compromise, not just a single leaked credential.

How does the attack unfold?

Initial Access

Attacker obtains authenticated, workflow-edit access to a shared n8n workflow (as a legitimate low-privilege teammate, contractor, or via a compromised account).

AML.T0012

Credential Discovery

Attacker identifies the identifier of another user's credential that they were not granted access to.

AML.T0084

Authorization Bypass

Attacker sets the credential type via an expression in an HTTP Request node; the pre-execution check validates the unresolved expression instead of the real credential type, skipping the ownership check.

AML.T0098

Impact

At execution the real credential loads and the attacker uses or exfiltrates it, gaining unauthorized access to the underlying LLM API, database, or cloud service.

AML.T0083

Initial Access

Attacker obtains authenticated, workflow-edit access to a shared n8n workflow (as a legitimate low-privilege teammate, contractor, or via a compromised account).

AML.T0012

Credential Discovery

Attacker identifies the identifier of another user's credential that they were not granted access to.

AML.T0084

Authorization Bypass

Attacker sets the credential type via an expression in an HTTP Request node; the pre-execution check validates the unresolved expression instead of the real credential type, skipping the ownership check.

AML.T0098

Impact

At execution the real credential loads and the attacker uses or exfiltrates it, gaining unauthorized access to the underlying LLM API, database, or cloud service.

AML.T0083

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.67	`1.123.67`
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Patch to n8n 1.123.67, 2.31.5, or 2.32.1 or later — this is the only complete fix. If immediate patching isn't possible: disable the HTTP Request node instance-wide by adding n8n-nodes-base.httpRequest to the NODES_EXCLUDE environment variable (breaks workflows that rely on it); restrict instance access to fully trusted users only, since exploitation requires an authenticated account with workflow edit rights; and audit existing credential sharing plus workflow membership to identify who can reach which credential IDs today. For detection, review audit/execution logs for HTTP Request node executions referencing credential IDs outside a user's normal working set, and rotate any credential that was shared into a workflow accessible to users outside its original owner group as a precaution.

How is it classified?

Auth Bypass Data Leakage Agent Plugin AML.T0012 - Valid Accounts AML.T0083 - Credentials from AI Agent Configuration AML.T0098 - AI Agent Tool Credential Harvesting

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

ISO 42001

A.6.2 - AI system operation and resource access control

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is GHSA-6qc9-mqvw-jg7x?

A flawed permission check in n8n lets any workflow editor swap in another user's stored credential inside an HTTP Request node simply by supplying the credential type through an expression instead of a literal value, since the pre-execution ownership check compared the unresolved expression rather than the real credential type and silently let the wrong credential load at runtime. n8n sits at the center of many AI automation stacks — chaining LLM API keys, cloud secrets, and database credentials into agent workflows — so this bug turns a routine 'give a teammate edit access' decision into a path for stealing every credential in the shared workspace, provided the attacker can discover the credential ID. There's no public exploit or CISA KEV listing yet and exploitation requires an authenticated account with edit rights, which caps the blast radius to insiders and compromised low-privilege accounts rather than anonymous internet attackers. Still, with 16 downstream dependents and 166 other CVEs already recorded against n8n, this is a heavily used, heavily scrutinized package, so treat any instance with broad workflow-sharing as exposed until patched. Upgrade to 1.123.67, 2.31.5, or 2.32.1 immediately; if that's not possible today, exclude the HTTP Request node via NODES_EXCLUDE and audit who has edit access to shared workflows and which credentials they can reach.

Is GHSA-6qc9-mqvw-jg7x actively exploited?

No confirmed active exploitation of GHSA-6qc9-mqvw-jg7x has been reported, but organizations should still patch proactively.

How to fix GHSA-6qc9-mqvw-jg7x?

Patch to n8n 1.123.67, 2.31.5, or 2.32.1 or later — this is the only complete fix. If immediate patching isn't possible: disable the HTTP Request node instance-wide by adding n8n-nodes-base.httpRequest to the NODES_EXCLUDE environment variable (breaks workflows that rely on it); restrict instance access to fully trusted users only, since exploitation requires an authenticated account with workflow edit rights; and audit existing credential sharing plus workflow membership to identify who can reach which credential IDs today. For detection, review audit/execution logs for HTTP Request node executions referencing credential IDs outside a user's normal working set, and rotate any credential that was shared into a workflow accessible to users outside its original owner group as a precaution.

What systems are affected by GHSA-6qc9-mqvw-jg7x?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow/automation orchestration, credential and secrets management for AI integrations.

What is the CVSS score for GHSA-6qc9-mqvw-jg7x?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow/automation orchestrationcredential and secrets management for AI integrations

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0083 Credentials from AI Agent Configuration

AML.T0098 AI Agent Tool Credential Harvesting

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

## Impact An authenticated member with edit access to a shared workflow could reference another user's credential in an HTTP Request node while specifying the credential type through an expression. Because the pre-execution permission check compared the unresolved expression instead of the real credential type, the ownership check was skipped and the credential was loaded at execution time, letting the member use or exfiltrate a credential they were never granted. Exploitation required knowing the target credential's identifier. ## Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. ## Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict n8n instance access to fully trusted users only. - Exclude the HTTP Request node by adding `n8n-nodes-base.httpRequest` to the `NODES_EXCLUDE` environment variable, if the node is not required. - Audit credential sharing and workflow access to limit exposure of credential IDs to untrusted users. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

Exploitation Scenario

An organization runs a shared n8n instance where an AI engineering team builds LLM-powered automation workflows; a contractor or junior team member is given edit access to a shared workflow for a narrow, legitimate task. The contractor notices — or obtains through a misconfigured share, log leakage, or simple enumeration — the credential ID of a teammate's LLM API or database credential that they were never granted access to. Inside an HTTP Request node, they set the credential type field to an expression rather than picking it from the UI dropdown; because n8n's pre-execution permission check validates the raw expression string instead of the credential type it evaluates to, the ownership check passes even though the resolved credential belongs to someone else. At execution time, n8n loads the real credential and the contractor's HTTP Request node fires with the stolen API key or database secret, letting them exfiltrate the credential value in the response or reuse it to access the underlying LLM API, cloud service, or database directly.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.