CVE-2026-42237: n8n: SQL injection in Snowflake/MySQL nodes bypasses fix

GHSA-hp3c-vfpm-q4f7 UNKNOWN
Published April 29, 2026
CISO Take

n8n's workflow automation platform contains an incomplete SQL injection fix — the original patch for GHSA-f3f2-mcxc-pwjx left both the Snowflake node and legacy MySQL v1 node vulnerable, allowing user-controlled table names, column names, and update keys to be interpolated directly into SQL queries without identifier escaping. Any organization using n8n as an AI agent orchestration layer faces direct database compromise risk if an attacker can influence workflow node configurations — a realistic scenario given n8n's common internet-exposed deployment posture and API-accessible workflow management. With this package carrying 75 historical CVEs, an OpenSSF score of only 6/10, and a risk score of 69/100, the systemic security posture of n8n warrants board-level attention for organizations using it to connect AI pipelines to production databases. Patch immediately to n8n 1.123.32, 2.17.4, or 2.18.1, and audit all existing workflows for user-controlled input flowing into Snowflake or MySQL v1 node configuration fields.

Sources: NVD GitHub Advisory EPSS OpenSSF ATLAS

What is the risk?

Despite a low raw EPSS score of 0.00029, this CVE sits at the 92nd percentile for exploitation likelihood, indicating it is more likely to be exploited than 92% of known vulnerabilities — a signal driven by the well-understood nature of SQL injection and n8n's popularity in AI automation stacks. The incomplete prior fix (GHSA-f3f2-mcxc-pwjx) indicates these nodes were either overlooked during code review or require structural changes that were deferred. Blast radius is bounded by n8n deployment scope but can be severe: any database connected via an affected node is at risk of full data exfiltration, modification, or destruction. No public exploit or CISA KEV entry exists yet, but the trivial exploitation complexity means this window is short once a PoC surfaces.

How does the attack unfold?

Initial Access
Attacker obtains access to the n8n workflow editor via stolen credentials, an exposed API endpoint, or a compromised service account with workflow modification rights.
AML.T0049
Tool Configuration Injection
Attacker creates or modifies a workflow, inserting SQL injection payloads into user-controlled fields (table name, column name, update key) of a Snowflake or MySQL v1 node — no escaping occurs during query construction.
AML.T0053
SQL Execution
When the workflow triggers, the injected SQL executes with the database credentials configured in the n8n node, granting the attacker arbitrary read/write/delete access to the connected database.
Data Exfiltration or Sabotage
Attacker extracts sensitive data (training sets, RAG corpora, user records) or modifies/destroys tables, potentially poisoning AI pipelines that depend on the compromised database as a data source.
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 16% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

6 steps
  1. Patch immediately: upgrade n8n to 1.123.32 (1.x branch), 2.17.4, or 2.18.1.

  2. Audit all workflows using Snowflake nodes or MySQL v1 nodes — identify any workflow that accepts user-controlled input for table names, column names, or update keys.

  3. Replace MySQL v1 nodes with the current MySQL v2 node, which uses parameterized queries.

  4. Restrict n8n API and UI access to authorized operators only — do not expose workflow editing to untrusted users.

  5. Enable database audit logging on all Snowflake and MySQL instances connected to n8n to detect anomalous query patterns.

  6. If immediate patching is not possible, disable Snowflake and MySQL v1 nodes at the n8n instance level as a temporary workaround.

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
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
8.4 - AI System Impact Assessment A.6.2.6 - AI System Security
NIST AI RMF
MANAGE 2.2 - Mechanisms to sustain the value of AI with human involvement
OWASP LLM Top 10
LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-42237?

n8n's workflow automation platform contains an incomplete SQL injection fix — the original patch for GHSA-f3f2-mcxc-pwjx left both the Snowflake node and legacy MySQL v1 node vulnerable, allowing user-controlled table names, column names, and update keys to be interpolated directly into SQL queries without identifier escaping. Any organization using n8n as an AI agent orchestration layer faces direct database compromise risk if an attacker can influence workflow node configurations — a realistic scenario given n8n's common internet-exposed deployment posture and API-accessible workflow management. With this package carrying 75 historical CVEs, an OpenSSF score of only 6/10, and a risk score of 69/100, the systemic security posture of n8n warrants board-level attention for organizations using it to connect AI pipelines to production databases. Patch immediately to n8n 1.123.32, 2.17.4, or 2.18.1, and audit all existing workflows for user-controlled input flowing into Snowflake or MySQL v1 node configuration fields.

Is CVE-2026-42237 actively exploited?

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

How to fix CVE-2026-42237?

1. Patch immediately: upgrade n8n to 1.123.32 (1.x branch), 2.17.4, or 2.18.1. 2. Audit all workflows using Snowflake nodes or MySQL v1 nodes — identify any workflow that accepts user-controlled input for table names, column names, or update keys. 3. Replace MySQL v1 nodes with the current MySQL v2 node, which uses parameterized queries. 4. Restrict n8n API and UI access to authorized operators only — do not expose workflow editing to untrusted users. 5. Enable database audit logging on all Snowflake and MySQL instances connected to n8n to detect anomalous query patterns. 6. If immediate patching is not possible, disable Snowflake and MySQL v1 nodes at the n8n instance level as a temporary workaround.

What systems are affected by CVE-2026-42237?

This vulnerability affects the following AI/ML architecture patterns: Agent frameworks, Database-connected AI pipelines, RAG ingestion pipelines, Workflow automation with AI capabilities, AI-driven ETL pipelines.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

Agent frameworksDatabase-connected AI pipelinesRAG ingestion pipelinesWorkflow automation with AI capabilitiesAI-driven ETL pipelines

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: Article 15
ISO 42001: 8.4, A.6.2.6
NIST AI RMF: MANAGE 2.2
OWASP LLM Top 10: LLM07

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, the fix for 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. This issue has been patched in versions 1.123.32, 2.17.4, and 2.18.1.

Exploitation Scenario

An adversary with access to an n8n instance — obtained via credential theft, SSRF, or an exposed API endpoint — creates or modifies a workflow using the Snowflake node. In the table name field, they inject a payload such as `users; SELECT * FROM api_keys INTO OUTFILE '/tmp/exfil.csv'; --`, bypassing identifier validation entirely since n8n performs no escaping before interpolation. The workflow executes against the connected Snowflake warehouse, returning sensitive data or corrupting tables used as the backing store for an AI RAG pipeline. In a more targeted scenario, an attacker poisons a training data table accessed by a scheduled enrichment workflow, introducing adversarial records to degrade downstream model behavior.

Weaknesses (CWE)

CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

  • [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
  • [Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Source: MITRE CWE corpus.

Timeline

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

Related Vulnerabilities