GHSA-6qc9-mqvw-jg7x: n8n — HIGH

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?

Update to patched version: n8n 1.123.67.

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

No CVSS score has been assigned yet.

## 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...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.67	`1.123.67`
197.0K OpenSSF 6.6 16 dependents Pushed 4d ago 61% patched ~6d 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

N/A

What should I do?

Patch available

Update n8n to version 1.123.67

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is GHSA-6qc9-mqvw-jg7x?

## 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.

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?

Update to patched version: n8n 1.123.67.

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

No CVSS score has been assigned yet.

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.

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.