Package Instance

n8n has SQL Injection in Data Table Node via orderByColumn Expression
## Impact
An authenticated user with permission to create or modify workflows could exploit a SQL injection vulnerability in the Data Table Get node. On default SQLite DB, single statements can be manipulated and the attack surface is practically limited. On PostgreSQL deployments, multi-statement execution is possible, enabling data modification and deletion.

## Patches
The issue has been fixed in n8n versions 1.123.26, 2.13.3, and 2.14.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 Data Table node by adding `n8n-nodes-base.dataTable` to the `NODES_EXCLUDE` environment variable.
- Review existing workflows for Data Table Get nodes where `orderByColumn` is set to an expression that incorporates external or user-supplied input.

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

n8n Unsafe Workflow Expression Evaluation Allows Remote Code Execution
n8n contains a critical Remote Code Execution (RCE) vulnerability in its workflow Expression evaluation system. Expressions supplied by authenticated users during workflow configuration may be evaluated in an execution context that is not sufficiently isolated from the underlying runtime.

An authenticated attacker could abuse this behavior to execute arbitrary code with the privileges of the n8n process. Successful exploitation may lead to full compromise of the affected instance, including unauthorized access to sensitive data, modification of workflows, and execution of system-level operations.

n8n has XML Node Prototype Pollution that to RCE
## Impact
An authenticated user with permission to create or modify workflows could achieve global prototype pollution via the XML Node leading to RCE when combined with other nodes exploiting the prototype pollution.

## 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 XML node by adding `n8n-nodes-base.xml` to the `NODES_EXCLUDE` environment variable.

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

n8n Vulnerable to Denial of Service via Malformed Binary Data Requests
Denial of Service vulnerability in `/rest/binary-data` endpoint when processing empty filesystem URIs (`filesystem://` or `filesystem-v2://`).

n8n is Vulnerable to Credential Theft via Name-Based Resolution and Permission Checker Bypass in Community Edition
## Impact
An authenticated user with the `global:member` role could exploit chained authorization flaws in n8n's credential pipeline to steal plaintext secrets from generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) belonging to other users on the same instance.

The attack abuses a name-based credential resolution path that does not enforce ownership or project scope, combined with a bypass in the credentials permission checker that causes generic HTTP credential types to be skipped during pre-execution validation. Together, these flaws allow a member-role user to resolve another user's credential ID and execute a workflow that decrypts and uses that credential without authorization.

Native integration credential types (e.g. `slackApi`, `openAiApi`, `postgres`) are not affected by this issue.

This vulnerability affects Community Edition only. Enterprise Edition has additional permission gates on workflow creation and execution that independently block this attack chain.

## Patches
The issue has been fixed in n8n versions 1.123.27, 2.13.3, and 2.14.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 instance access to fully trusted users only.
- Audit credentials stored on the instance and rotate any generic HTTP credentials (`httpBasicAuth`, `httpHeaderAuth`, `httpQueryAuth`) that may have been exposed.

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

n8n has Unauthenticated Expression Evaluation via Form Node
A second-order expression injection vulnerability existed in n8n's Form nodes that could allow an unauthenticated attacker to inject and evaluate arbitrary n8n expressions by submitting crafted form data. When chained with an expression sandbox escape, this could escalate to remote code execution on the n8n host.

The vulnerability requires a specific workflow configuration to be exploitable:
1. A form node with a field interpolating a value provided by an unauthenticated user, e.g. a form submitted value.
2. The field value must begin with an `=` character, which caused n8n to treat it as an expression and triggered a double-evaluation of the field content.
For example, a workflow uses a multi-step Form where a downstream Form node renders user-provided input back in an HTML field and precedes it with an `=` sign:
`=<h2>Thank you, {{ $input.first().json[\"Name\"] }}!</h2>`

There is no practical reason for a workflow designer to prefix a field with `=` intentionally — the character is not rendered in the output, so the result would not match the designer's expectations. If added accidentally, it would be noticeable and very unlikely to persist. An unauthenticated attacker would need to either know about this specific circumstance on a target instance or discover a matching form by chance.

Even when the preconditions are met, the expression injection alone is limited to data accessible within the n8n expression context. Escalation to remote code execution requires chaining with a separate sandbox escape vulnerability.

Due to these real-world constraints — the unlikely workflow configuration, the need for an additional sandbox escape, and the difficulty of discovery — we have assessed the severity as High rather than Critical, diverging from the base CVSS score to better reflect actual exploitability.

n8n: SQL Injection in MySQL, PostgreSQL, and Microsoft SQL nodes
An authenticated user with permission to create or modify workflows and access to a database credential could unknowingly create a workflow that was vulnerable to SQL injection, even while expecting inputs to be handled safely through escaped parameters. By supplying specially crafted table or column names, an attacker could inject arbitrary SQL because the MySQL, PostgreSQL, and Microsoft SQL nodes did not escape identifier values when constructing queries, enabling injection through node configuration parameters.

n8n has OS Command Injection in Git Node
Vulnerabilities in the Git node allowed authenticated users with permission to create or modify workflows to execute arbitrary system commands or read arbitrary files on the n8n host.

n8n Vulnerable to Unauthenticated Denial of Service via MCP Client Registration
## 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.