deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-f77h-j2v7-g6mw
Package: n8n (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

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
GitHub Security Advisory: GHSA-f77h-j2v7-g6mw
Package: n8n (NPM)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

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
GitHub Security Advisory: GHSA-mp4j-h6gh-f6mp
Package: n8n (NPM)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 2.0.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n has SQL Injection in SeaTable Node

Details:
## Impact
A flaw in the SeaTable node's `row:search` and `row:get` operations allowed user-controlled input to be concatenated directly into SQL query strings without escaping or parameterization. In workflows where external user input is passed via expressions into the SeaTable node's search or row retrieval parameters, an attacker could manipulate the constructed query to retrieve unintended rows from the connected SeaTable base, bypassing row-level filtering logic implemented in the workflow.

Exploitation requires a specific workflow configuration:
- The SeaTable node must be used with user-controlled input passed via expressions (e.g., from a form or webhook) into the `searchTerm` or `rowId` parameters.

## 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 SeaTable node by adding `n8n-nodes-base.seaTable` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into SeaTable node search or row retrieval parameters via expressions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-mp4j-h6gh-f6mp
Package: n8n (NPM)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n has SQL Injection in SeaTable Node

Details:
## Impact
A flaw in the SeaTable node's `row:search` and `row:get` operations allowed user-controlled input to be concatenated directly into SQL query strings without escaping or parameterization. In workflows where external user input is passed via expressions into the SeaTable node's search or row retrieval parameters, an attacker could manipulate the constructed query to retrieve unintended rows from the connected SeaTable base, bypassing row-level filtering logic implemented in the workflow.

Exploitation requires a specific workflow configuration:
- The SeaTable node must be used with user-controlled input passed via expressions (e.g., from a form or webhook) into the `searchTerm` or `rowId` parameters.

## 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 SeaTable node by adding `n8n-nodes-base.seaTable` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into SeaTable node search or row retrieval parameters via expressions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-mp4j-h6gh-f6mp
Package: n8n (NPM)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n has SQL Injection in SeaTable Node

Details:
## Impact
A flaw in the SeaTable node's `row:search` and `row:get` operations allowed user-controlled input to be concatenated directly into SQL query strings without escaping or parameterization. In workflows where external user input is passed via expressions into the SeaTable node's search or row retrieval parameters, an attacker could manipulate the constructed query to retrieve unintended rows from the connected SeaTable base, bypassing row-level filtering logic implemented in the workflow.

Exploitation requires a specific workflow configuration:
- The SeaTable node must be used with user-controlled input passed via expressions (e.g., from a form or webhook) into the `searchTerm` or `rowId` parameters.

## 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 SeaTable node by adding `n8n-nodes-base.seaTable` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into SeaTable node search or row retrieval parameters via expressions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-f6x8-65q6-j9m9
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 2.0.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n has Open Redirect in MCP OAuth Consent Flow

Details:
## Impact
The `/mcp-oauth/register` endpoint accepted OAuth client registrations without authentication, allowing arbitrary `redirect_uri` values to be registered. When a user denies the MCP OAuth consent dialog, the `handleDeny` handler redirects the user to the registered `redirect_uri` without validation, enabling an open redirect to an attacker-controlled URL. An attacker can craft a phishing link and send it to a victim; if the victim clicks "Deny" on the consent page, they are silently redirected to an external site.

## 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 untrusted users from reaching the MCP OAuth endpoints.
- Limit access to the n8n instance to fully trusted users only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-f6x8-65q6-j9m9
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n has Open Redirect in MCP OAuth Consent Flow

Details:
## Impact
The `/mcp-oauth/register` endpoint accepted OAuth client registrations without authentication, allowing arbitrary `redirect_uri` values to be registered. When a user denies the MCP OAuth consent dialog, the `handleDeny` handler redirects the user to the registered `redirect_uri` without validation, enabling an open redirect to an attacker-controlled URL. An attacker can craft a phishing link and send it to a victim; if the victim clicks "Deny" on the consent page, they are silently redirected to an external site.

## 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 untrusted users from reaching the MCP OAuth endpoints.
- Limit access to the n8n instance to fully trusted users only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-f6x8-65q6-j9m9
Package: n8n (NPM)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n has Open Redirect in MCP OAuth Consent Flow

Details:
## Impact
The `/mcp-oauth/register` endpoint accepted OAuth client registrations without authentication, allowing arbitrary `redirect_uri` values to be registered. When a user denies the MCP OAuth consent dialog, the `handleDeny` handler redirects the user to the registered `redirect_uri` without validation, enabling an open redirect to an attacker-controlled URL. An attacker can craft a phishing link and send it to a victim; if the victim clicks "Deny" on the consent page, they are silently redirected to an external site.

## 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 untrusted users from reaching the MCP OAuth endpoints.
- Limit access to the n8n instance to fully trusted users only.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-r6jc-mpqw-m755
Package: n8n (NPM)
Severity: MODERATE (CVSS 9.8)
CWE: CWE-20: Improper Input Validation, CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 2.0.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n has SQL Injection in Oracle Database Node via Limit Field

Details:
## Impact
A flaw in the Oracle Database node's select operation allowed user-controlled input passed into the `Limit` field via expressions to be interpolated directly into the SQL query without sanitization or parameterization. In workflows where external input is passed into the `Limit` field (e.g., from a webhook), an attacker could inject arbitrary SQL and exfiltrate data from the connected Oracle database.

Exploitation requires a specific workflow configuration:
- The Oracle Database node must be used with user-controlled input passed via expressions into the `Limit` field.
- Authentication requirements depend on the workflow's configuration (e.g., an unauthenticated webhook endpoint would allow unauthenticated exploitation).

## 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 Oracle Database node by adding `n8n-nodes-base.oracleDatabase` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into the Oracle Database node's `Limit` field via expressions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-r6jc-mpqw-m755
Package: n8n (NPM)
Severity: MODERATE (CVSS 9.8)
CWE: CWE-20: Improper Input Validation, CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n has SQL Injection in Oracle Database Node via Limit Field

Details:
## Impact
A flaw in the Oracle Database node's select operation allowed user-controlled input passed into the `Limit` field via expressions to be interpolated directly into the SQL query without sanitization or parameterization. In workflows where external input is passed into the `Limit` field (e.g., from a webhook), an attacker could inject arbitrary SQL and exfiltrate data from the connected Oracle database.

Exploitation requires a specific workflow configuration:
- The Oracle Database node must be used with user-controlled input passed via expressions into the `Limit` field.
- Authentication requirements depend on the workflow's configuration (e.g., an unauthenticated webhook endpoint would allow unauthenticated exploitation).

## 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 Oracle Database node by adding `n8n-nodes-base.oracleDatabase` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into the Oracle Database node's `Limit` field via expressions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-r6jc-mpqw-m755
Package: n8n (NPM)
Severity: MODERATE (CVSS 9.8)
CWE: CWE-20: Improper Input Validation, CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n has SQL Injection in Oracle Database Node via Limit Field

Details:
## Impact
A flaw in the Oracle Database node's select operation allowed user-controlled input passed into the `Limit` field via expressions to be interpolated directly into the SQL query without sanitization or parameterization. In workflows where external input is passed into the `Limit` field (e.g., from a webhook), an attacker could inject arbitrary SQL and exfiltrate data from the connected Oracle database.

Exploitation requires a specific workflow configuration:
- The Oracle Database node must be used with user-controlled input passed via expressions into the `Limit` field.
- Authentication requirements depend on the workflow's configuration (e.g., an unauthenticated webhook endpoint would allow unauthenticated exploitation).

## 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 Oracle Database node by adding `n8n-nodes-base.oracleDatabase` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into the Oracle Database node's `Limit` field via expressions.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-hp3c-vfpm-q4f7
Package: n8n (NPM)
Severity: MODERATE (CVSS 8.2)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 2.0.0, < 2.17.4
Patched in: 2.17.4

Summary: n8n has SQL Injection in Snowflake and MySQL Nodes

Details:
## Impact
The fix for [GHSA-f3f2-mcxc-pwjx](https://github.com/advisories/GHSA-f3f2-mcxc-pwjx) did not cover the Snowflake node or the legacy MySQL v1 node. Both nodes construct SQL queries by directly interpolating user-controlled table names, column names, and update keys into query strings without identifier escaping, enabling SQL injection against the connected database.

Exploitation requires a specific workflow configuration:
- The Snowflake or MySQL v1 node must be used with user-controlled input passed via expressions (e.g., from a form or webhook) into identifier fields such as table name, column name, or update key.

Successful exploitation could allow data exfiltration, modification, or deletion on the downstream database.

## 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.
- Migrate workflows from the legacy MySQL v1 node to the MySQL v2 node, which already implements identifier escaping.
- Disable the Snowflake node by adding `n8n-nodes-base.snowflake` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into table name, column name, or update key fields via expressions in the affected nodes.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-hp3c-vfpm-q4f7
Package: n8n (NPM)
Severity: MODERATE (CVSS 8.2)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 2.18.0, < 2.18.1
Patched in: 2.18.1

Summary: n8n has SQL Injection in Snowflake and MySQL Nodes

Details:
## Impact
The fix for [GHSA-f3f2-mcxc-pwjx](https://github.com/advisories/GHSA-f3f2-mcxc-pwjx) did not cover the Snowflake node or the legacy MySQL v1 node. Both nodes construct SQL queries by directly interpolating user-controlled table names, column names, and update keys into query strings without identifier escaping, enabling SQL injection against the connected database.

Exploitation requires a specific workflow configuration:
- The Snowflake or MySQL v1 node must be used with user-controlled input passed via expressions (e.g., from a form or webhook) into identifier fields such as table name, column name, or update key.

Successful exploitation could allow data exfiltration, modification, or deletion on the downstream database.

## 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.
- Migrate workflows from the legacy MySQL v1 node to the MySQL v2 node, which already implements identifier escaping.
- Disable the Snowflake node by adding `n8n-nodes-base.snowflake` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into table name, column name, or update key fields via expressions in the affected nodes.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
GitHub Security Advisory: GHSA-hp3c-vfpm-q4f7
Package: n8n (NPM)
Severity: MODERATE (CVSS 8.2)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 1.123.32
Patched in: 1.123.32

Summary: n8n has SQL Injection in Snowflake and MySQL Nodes

Details:
## Impact
The fix for [GHSA-f3f2-mcxc-pwjx](https://github.com/advisories/GHSA-f3f2-mcxc-pwjx) did not cover the Snowflake node or the legacy MySQL v1 node. Both nodes construct SQL queries by directly interpolating user-controlled table names, column names, and update keys into query strings without identifier escaping, enabling SQL injection against the connected database.

Exploitation requires a specific workflow configuration:
- The Snowflake or MySQL v1 node must be used with user-controlled input passed via expressions (e.g., from a form or webhook) into identifier fields such as table name, column name, or update key.

Successful exploitation could allow data exfiltration, modification, or deletion on the downstream database.

## 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.
- Migrate workflows from the legacy MySQL v1 node to the MySQL v2 node, which already implements identifier escaping.
- Disable the Snowflake node by adding `n8n-nodes-base.snowflake` to the `NODES_EXCLUDE` environment variable.
- Avoid passing unvalidated external user input into table name, column name, or update key fields via expressions in the affected nodes.

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