CVE-2026-42233: n8n: SQL injection in Oracle node allows data exfiltration

GHSA-r6jc-mpqw-m755 UNKNOWN
Published April 29, 2026
CISO Take

n8n's Oracle Database node contains an unparameterized SQL injection flaw where user-controlled input routed through webhook expressions into the Limit field is directly concatenated into SQL queries without sanitization. Any organization running n8n AI agent workflows that accept external webhook data and query Oracle databases is exposed to full database compromise and arbitrary data exfiltration. With 75 CVEs on record for this package, an OpenSSF score of 6/10, and an EPSS placing this in the top 85th percentile for exploitation likelihood, this vulnerability reflects compounding security debt in a widely-deployed agent orchestration platform. Patch immediately to 1.123.32, 2.17.4, or 2.18.1; if patching is delayed, audit all Oracle node workflows to ensure no external input flows unvalidated into expression-driven Limit fields and restrict webhook endpoints to authenticated sources.

Sources: NVD EPSS GitHub Advisory ATLAS OpenSSF

What is the risk?

High risk for organizations using n8n with Oracle database integrations that accept external webhook input. CWE-89 (SQL Injection) is a well-understood, trivially exploitable vulnerability class requiring no AI/ML expertise once the attack surface is identified. The vulnerability is constrained to workflows using Oracle Database nodes with expression-driven Limit fields sourced from external data—but within that scope, impact is severe: arbitrary SQL execution enabling full data exfiltration from the connected Oracle instance. The 85th EPSS percentile indicates elevated exploitation probability relative to the broader CVE population. The package's history of 75 CVEs signals a pattern of insufficient input validation discipline across the codebase.

How does the attack unfold?

Initial Access
Attacker sends a crafted HTTP POST request to an exposed n8n webhook endpoint embedding a SQL injection payload in the field used by the Oracle node Limit expression.
AML.T0049
Tool Exploitation
n8n interpolates the unsanitized user input directly into the Oracle SQL query's LIMIT clause, enabling arbitrary SQL execution against the connected database.
AML.T0053
Data Collection
The injected SQL (e.g., UNION SELECT) retrieves arbitrary rows from the Oracle database including sensitive records accessible to the n8n service account credential.
AML.T0037
Exfiltration
Query results containing exfiltrated database contents are returned to the attacker via the n8n workflow HTTP response or surfaced through database error messages.
AML.T0086

What systems are affected?

Package Ecosystem Vulnerable Range Patched
n8n npm < 1.123.32 1.123.32
193.4K OpenSSF 6.6 Pushed 4d ago 54% patched ~7d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.3%
chance of exploitation in 30 days
Higher than 24% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

6 steps
  1. Patch n8n to 1.123.32 (v1 branch), 2.17.4, or 2.18.1 (v2 branch) immediately — all three branches are patched.

  2. Audit all active workflows using Oracle Database nodes and identify those where the Limit field value derives from external input (webhook payloads, form submissions, or URL parameters).

  3. If patching is delayed, add explicit integer type coercion before Limit field expressions in affected workflows and reject non-numeric input.

  4. Restrict webhook endpoints with authentication (API key, HMAC signature) to prevent unauthenticated access.

  5. Apply least-privilege Oracle credentials in n8n connections — use a read-only role scoped to required tables.

  6. Enable Oracle Unified Auditing and monitor for anomalous SQL patterns including UNION clauses, stacked queries, or access to system tables (DBA_USERS, ALL_TABLES).

What does CISA's SSVC say?

Decision Track
Exploitation none
Automatable No
Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2 - Data quality and data governance
NIST AI RMF
GOVERN 1.1 - Policies and procedures for AI risk management
OWASP LLM Top 10
LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-42233?

n8n's Oracle Database node contains an unparameterized SQL injection flaw where user-controlled input routed through webhook expressions into the Limit field is directly concatenated into SQL queries without sanitization. Any organization running n8n AI agent workflows that accept external webhook data and query Oracle databases is exposed to full database compromise and arbitrary data exfiltration. With 75 CVEs on record for this package, an OpenSSF score of 6/10, and an EPSS placing this in the top 85th percentile for exploitation likelihood, this vulnerability reflects compounding security debt in a widely-deployed agent orchestration platform. Patch immediately to 1.123.32, 2.17.4, or 2.18.1; if patching is delayed, audit all Oracle node workflows to ensure no external input flows unvalidated into expression-driven Limit fields and restrict webhook endpoints to authenticated sources.

Is CVE-2026-42233 actively exploited?

No confirmed active exploitation of CVE-2026-42233 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-42233?

1. Patch n8n to 1.123.32 (v1 branch), 2.17.4, or 2.18.1 (v2 branch) immediately — all three branches are patched. 2. Audit all active workflows using Oracle Database nodes and identify those where the Limit field value derives from external input (webhook payloads, form submissions, or URL parameters). 3. If patching is delayed, add explicit integer type coercion before Limit field expressions in affected workflows and reject non-numeric input. 4. Restrict webhook endpoints with authentication (API key, HMAC signature) to prevent unauthenticated access. 5. Apply least-privilege Oracle credentials in n8n connections — use a read-only role scoped to required tables. 6. Enable Oracle Unified Auditing and monitor for anomalous SQL patterns including UNION clauses, stacked queries, or access to system tables (DBA_USERS, ALL_TABLES).

What systems are affected by CVE-2026-42233?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, data ingestion pipelines, workflow automation platforms.

What is the CVSS score for CVE-2026-42233?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesdata ingestion pipelinesworkflow automation platforms

MITRE ATLAS Techniques

AML.T0010.005 AI Agent Tool
AML.T0049 Exploit Public-Facing Application
AML.T0053 AI Agent Tool Invocation
AML.T0086 Exfiltration via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Art. 15
ISO 42001: A.6.2
NIST AI RMF: GOVERN 1.1
OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

n8n is an open source workflow automation platform. Prior to versions 1.123.32, 2.17.4, and 2.18.1, 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. This issue has been patched in versions 1.123.32, 2.17.4, and 2.18.1.

Exploitation Scenario

An attacker enumerates publicly exposed n8n instances (via Shodan or direct scanning) and identifies a webhook-triggered workflow that feeds incoming JSON payload fields into an Oracle Database node's Limit expression. Sending a crafted POST request with a payload such as `{"limit": "1 UNION SELECT username, password, null FROM dba_users--"}` causes n8n to construct and execute the injected SQL against the connected Oracle database. Query results are returned in the workflow response body, or the attacker infers data through error-based extraction using Oracle-specific functions. In an AI pipeline context, this could expose vector embeddings, RAG knowledge base contents, model training datasets, or API keys stored in Oracle tables—enabling further compromise of downstream AI systems.

Weaknesses (CWE)

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

  • [Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
  • [Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.

Timeline

Published
April 29, 2026
Last Modified
May 4, 2026
First Seen
April 30, 2026

Related Vulnerabilities