deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-q5f4-99jv-pgg5
Package: n8n (NPM)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n has Prototype Pollution in XML Webhook Body Parser that Leads to RCE

Details:
## Impact
A flaw in the `xml2js` library used to parse XML request bodies in n8n's webhook handler allowed prototype pollution via a crafted XML payload. An authenticated user with permission to create or modify workflows could exploit this to pollute the JavaScript object prototype and, by chaining the pollution with the Git node's SSH operations, achieve remote code execution on the n8n host.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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:
- Limit workflow creation and editing permissions to fully trusted users only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

---
n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
GitHub Security Advisory: GHSA-537j-gqpc-p7fq
Package: n8n (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: >= 2.17.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n Vulnerable to XSS via MCP OAuth client

Details:
## Impact
An unauthenticated attacker could register a malicious MCP OAuth client with a crafted `client_name`. If a victim user authorized the OAuth consent dialog and a second user subsequently revoked that access, a toast notification would render the injected script. Clicking the link would execute arbitrary JavaScript in the victim's authenticated n8n browser session, enabling credential and session token theft, workflow manipulation, or privilege escalation.

## Patches
This issue has been fixed in n8n version 2.14.2. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Restrict access to the n8n instance and the MCP OAuth registration endpoint to trusted users only.
- Disable MCP server functionality if it is not actively required.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-537j-gqpc-p7fq
Package: n8n (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n Vulnerable to XSS via MCP OAuth client

Details:
## Impact
An unauthenticated attacker could register a malicious MCP OAuth client with a crafted `client_name`. If a victim user authorized the OAuth consent dialog and a second user subsequently revoked that access, a toast notification would render the injected script. Clicking the link would execute arbitrary JavaScript in the victim's authenticated n8n browser session, enabling credential and session token theft, workflow manipulation, or privilege escalation.

## Patches
This issue has been fixed in n8n version 2.14.2. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Restrict access to the n8n instance and the MCP OAuth registration endpoint to trusted users only.
- Disable MCP server functionality if it is not actively required.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-537j-gqpc-p7fq
Package: n8n (NPM)
Severity: HIGH (CVSS 8.2)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-87: Improper Neutralization of Alternate XSS Syntax
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n Vulnerable to XSS via MCP OAuth client

Details:
## Impact
An unauthenticated attacker could register a malicious MCP OAuth client with a crafted `client_name`. If a victim user authorized the OAuth consent dialog and a second user subsequently revoked that access, a toast notification would render the injected script. Clicking the link would execute arbitrary JavaScript in the victim's authenticated n8n browser session, enabling credential and session token theft, workflow manipulation, or privilege escalation.

## Patches
This issue has been fixed in n8n version 2.14.2. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Restrict access to the n8n instance and the MCP OAuth registration endpoint to trusted users only.
- Disable MCP server functionality if it is not actively required.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-r4v6-9fqc-w5jr
Package: n8n (NPM)
Severity: HIGH (CVSS 8.5)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 1.123.33
Patched in: 1.123.33

Summary: n8n's Credential Authorization Bypass in dynamic-node-parameters Allows Foreign API Key Replay

Details:
## Impact
The `dynamic-node-parameters` endpoints did not verify whether the authenticated caller was authorized to use a supplied credential reference. An authenticated user with access to a shared workflow could supply a foreign credential ID in the request body, causing the backend to decrypt and use that credential in a helper execution path where the caller also controls the destination URL. This allowed the caller to force the backend to authenticate against attacker-controlled infrastructure using a credential belonging to another user, effectively exfiltrating a reusable API key.

The issue is not limited to any single node type; any node that resolves credentials dynamically through these endpoints may be affected.

## Patches
The issue has been fixed in n8n version 2.18.0. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Restrict n8n access to fully trusted users only.
- Avoid sharing workflows with users who should not have access to the credentials those workflows reference.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-r4v6-9fqc-w5jr
Package: n8n (NPM)
Severity: HIGH (CVSS 8.5)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 2.17.0, < 2.17.5
Patched in: 2.17.5

Summary: n8n's Credential Authorization Bypass in dynamic-node-parameters Allows Foreign API Key Replay

Details:
## Impact
The `dynamic-node-parameters` endpoints did not verify whether the authenticated caller was authorized to use a supplied credential reference. An authenticated user with access to a shared workflow could supply a foreign credential ID in the request body, causing the backend to decrypt and use that credential in a helper execution path where the caller also controls the destination URL. This allowed the caller to force the backend to authenticate against attacker-controlled infrastructure using a credential belonging to another user, effectively exfiltrating a reusable API key.

The issue is not limited to any single node type; any node that resolves credentials dynamically through these endpoints may be affected.

## Patches
The issue has been fixed in n8n version 2.18.0. Users should upgrade to this version or later to remediate the vulnerability.

## Workarounds
If upgrading is not immediately possible, administrators should consider the following temporary mitigations:
- Restrict n8n access to fully trusted users only.
- Avoid sharing workflows with users who should not have access to the credentials those workflows reference.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-44v6-jhgm-p3m4
Package: n8n (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 2.17.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n has a Python Task Runner Sandbox Escape Vulnerability

Details:
## Impact
An authenticated user with permission to create or modify workflows containing a Python Code Node could escape the sandbox and achieve arbitrary code execution on the task runner container.

- This issue only affects instances where the Python Task Runner is enabled.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Python Code node by adding `n8n-nodes-base.code` to the `NODES_EXCLUDE` environment variable, or disable the Python Task Runner entirely.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-44v6-jhgm-p3m4
Package: n8n (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n has a Python Task Runner Sandbox Escape Vulnerability

Details:
## Impact
An authenticated user with permission to create or modify workflows containing a Python Code Node could escape the sandbox and achieve arbitrary code execution on the task runner container.

- This issue only affects instances where the Python Task Runner is enabled.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Python Code node by adding `n8n-nodes-base.code` to the `NODES_EXCLUDE` environment variable, or disable the Python Task Runner entirely.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-44v6-jhgm-p3m4
Package: n8n (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n has a Python Task Runner Sandbox Escape Vulnerability

Details:
## Impact
An authenticated user with permission to create or modify workflows containing a Python Code Node could escape the sandbox and achieve arbitrary code execution on the task runner container.

- This issue only affects instances where the Python Task Runner is enabled.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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:
- Limit workflow creation and editing permissions to fully trusted users only.
- Disable the Python Code node by adding `n8n-nodes-base.code` to the `NODES_EXCLUDE` environment variable, or disable the Python Task Runner entirely.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-756q-gq9h-fp22
Package: n8n (NPM)
Severity: MODERATE (CVSS 7.7)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 2.0.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n has Public API Variables IDOR that Allows Cross-Project Secret Disclosure

Details:
## Impact
An authenticated user with a valid API key scoped to `variable:list` could read variables from projects they are not a member of by supplying an arbitrary `projectId` query parameter to the public API variables endpoint. The handler queried the variables repository directly without enforcing project membership checks, bypassing the authorization-aware service layer used by the internal enterprise controller. 

If variables were misused to store sensitive information such as credentials or tokens, they should be rotated immediately.

This issue only affects licensed enterprise or team deployments with multiple projects and the variables feature enabled.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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 access and API key issuance to fully trusted users only.
- Audit existing project variables for sensitive values and rotate any secrets that may have been exposed.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-756q-gq9h-fp22
Package: n8n (NPM)
Severity: MODERATE (CVSS 7.7)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n has Public API Variables IDOR that Allows Cross-Project Secret Disclosure

Details:
## Impact
An authenticated user with a valid API key scoped to `variable:list` could read variables from projects they are not a member of by supplying an arbitrary `projectId` query parameter to the public API variables endpoint. The handler queried the variables repository directly without enforcing project membership checks, bypassing the authorization-aware service layer used by the internal enterprise controller. 

If variables were misused to store sensitive information such as credentials or tokens, they should be rotated immediately.

This issue only affects licensed enterprise or team deployments with multiple projects and the variables feature enabled.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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 access and API key issuance to fully trusted users only.
- Audit existing project variables for sensitive values and rotate any secrets that may have been exposed.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-756q-gq9h-fp22
Package: n8n (NPM)
Severity: MODERATE (CVSS 7.7)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n has Public API Variables IDOR that Allows Cross-Project Secret Disclosure

Details:
## Impact
An authenticated user with a valid API key scoped to `variable:list` could read variables from projects they are not a member of by supplying an arbitrary `projectId` query parameter to the public API variables endpoint. The handler queried the variables repository directly without enforcing project membership checks, bypassing the authorization-aware service layer used by the internal enterprise controller. 

If variables were misused to store sensitive information such as credentials or tokens, they should be rotated immediately.

This issue only affects licensed enterprise or team deployments with multiple projects and the variables feature enabled.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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 access and API key issuance to fully trusted users only.
- Audit existing project variables for sensitive values and rotate any secrets that may have been exposed.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-49m9-pgww-9vq6
Package: n8n (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.0.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n Vulnerable to Unauthenticated Denial of Service via MCP Client Registration

Details:
## Impact
The MCP OAuth client registration endpoint accepted unauthenticated requests and stored client data without adequate resource controls. An unauthenticated remote attacker could exhaust server memory resources by sending large registration payloads, rendering the n8n instance unavailable. The MCP enable/disable toggle gates MCP access but did not restrict client registrations, meaning the endpoint is reachable regardless of whether MCP access is enabled on the instance.

The patches address the unbound registration with an upper bound of registered clients and disabling creation when MCP is disabled on the instance. Mean to restrict the payload size of requests already exist and can be used to control additional risks.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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 network access to the n8n instance to prevent requests from untrusted sources.
- Reduce the maximum accepted payload size by lowering the `N8N_PAYLOAD_SIZE_MAX` environment variable from its default value.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-49m9-pgww-9vq6
Package: n8n (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n Vulnerable to Unauthenticated Denial of Service via MCP Client Registration

Details:
## Impact
The MCP OAuth client registration endpoint accepted unauthenticated requests and stored client data without adequate resource controls. An unauthenticated remote attacker could exhaust server memory resources by sending large registration payloads, rendering the n8n instance unavailable. The MCP enable/disable toggle gates MCP access but did not restrict client registrations, meaning the endpoint is reachable regardless of whether MCP access is enabled on the instance.

The patches address the unbound registration with an upper bound of registered clients and disabling creation when MCP is disabled on the instance. Mean to restrict the payload size of requests already exist and can be used to control additional risks.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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 network access to the n8n instance to prevent requests from untrusted sources.
- Reduce the maximum accepted payload size by lowering the `N8N_PAYLOAD_SIZE_MAX` environment variable from its default value.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-49m9-pgww-9vq6
Package: n8n (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n Vulnerable to Unauthenticated Denial of Service via MCP Client Registration

Details:
## Impact
The MCP OAuth client registration endpoint accepted unauthenticated requests and stored client data without adequate resource controls. An unauthenticated remote attacker could exhaust server memory resources by sending large registration payloads, rendering the n8n instance unavailable. The MCP enable/disable toggle gates MCP access but did not restrict client registrations, meaning the endpoint is reachable regardless of whether MCP access is enabled on the instance.

The patches address the unbound registration with an upper bound of registered clients and disabling creation when MCP is disabled on the instance. Mean to restrict the payload size of requests already exist and can be used to control additional risks.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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 network access to the n8n instance to prevent requests from untrusted sources.
- Reduce the maximum accepted payload size by lowering the `N8N_PAYLOAD_SIZE_MAX` environment variable from its default value.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-f77h-j2v7-g6mw
Package: n8n (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 2.0.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n Vulnerable to Hijacking of Unauthenticated Chat Execution 

Details:
## Impact
The `/chat` WebSocket endpoint used by the Chat Trigger node's Hosted Chat feature did not verify that an incoming connection was authorized to interact with the target execution. An unauthenticated remote attacker who could identify a valid execution ID for a workflow in a waiting state could attach to that execution, receive the pending prompt intended for the legitimate user, and submit arbitrary input to resume or influence downstream workflow behavior.

Exploitation requires the following conditions:
- The instance exposes a public Hosted Chat workflow with authentication set to `None`.
- A target execution is in a waiting state at the time of the attack.
- The attacker can obtain or discover the execution ID of that waiting execution.

## Patches
The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.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:
- Enable authentication on all Chat Trigger nodes by setting the Authentication field to `n8n User Auth` rather than `None`.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

---
n8n has adopted CVSS 4.0 as primary score for all security advisories. CVSS 3.1 vector strings are provided for backwards compatibility.

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N