n8n has SQL Injection in Oracle Database Node via Limit Field
Medium9.8CVE-2026-42233 · Published Apr 29, 2026 · updated May 8, 2026
## 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...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| n8n npm | < 1.123.32 | 1.123.32 |
| >= 2.18.0, < 2.18.1 | 2.18.1 | |
| >= 2.0.0, < 2.17.4 | 2.17.4 |
Details and references
## 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.
More n8n advisories
All n8n| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Apr 29 | n8n has XML Node Prototype Pollution that to RCE Critical9.9Apr 29 | Critical9.9 | 1.123.32+2 more |
| Apr 29 | n8n has Prototype Pollution in XML Webhook Body Parser that Leads to RCECritical10.0Apr 29 | Critical10.0 | 1.123.32+2 more |
| Apr 29 | n8n Vulnerable to XSS via MCP OAuth clientHigh8.2Apr 29 | High8.2 | 1.123.32+2 more |
| Apr 29 | n8n's Credential Authorization Bypass in dynamic-node-parameters Allows Foreign API Key ReplayHigh8.5Apr 29 | High8.5 | 1.123.33+1 more |
| Apr 29 | n8n has a Python Task Runner Sandbox Escape VulnerabilityHigh7.5Apr 29 | High7.5 | 1.123.32+2 more |
| Apr 29 | n8n has Public API Variables IDOR that Allows Cross-Project Secret DisclosureMedium7.7Apr 29 | Medium7.7 | 1.123.32+2 more |