CVE-2026-72750: n8n SQL injection — HIGH

CISO Take

n8n's Snowflake node lets workflow authors interpolate expression values directly into a raw SQL string for its Execute Query operation, so any externally-controlled data referenced in that expression — a webhook payload, an email body, a third-party API response — flows unparameterized into the query and can inject arbitrary SQL against the connected Snowflake warehouse. The real-world risk is workflow-dependent rather than remotely exploitable out of the box: it requires a workflow author to have already wired untrusted input into a raw SQL string, a common shortcut in automation platforms increasingly used to connect AI agents to enterprise data warehouses. EPSS sits at just 0.00211 (top 88th percentile, still a low absolute probability), there's no public exploit or Nuclei scanner template, it's absent from CISA KEV, and CISA scored it TRACK — monitor, not urgent. Upgrade to n8n 1.123.67, 2.31.5, or 2.32.1, which adds an optional 'Query Parameters' field for positional-placeholder binding, and in the meantime audit existing workflows for any Snowflake Execute Query node that concatenates expression data — especially from webhook, form, or AI-agent-tool trigger nodes — into the raw SQL string instead of using bound parameters.

Sources: NVD EPSS GitHub Advisory VulnCheck ATLAS

What is the risk?

No CVSS score is published and the vulnerability is not remotely exploitable by default — exploitation requires a workflow author to have already built a Snowflake Execute Query node that concatenates externally-controlled expression data into raw SQL rather than using bound parameters. Given that precondition, impact is high (classic unauthenticated SQL injection into a data warehouse: read, write, or destroy data depending on the credentials used by the node). Likelihood is low: EPSS is 0.00211 (bottom of the practical exploitation range despite the 88th-percentile ranking), there is no public PoC, no Nuclei template, and it is not in CISA KEV. CISA's SSVC decision of TRACK confirms this is a monitor-and-patch item, not an active-exploitation emergency. Overall risk: LOW-to-MEDIUM, contingent entirely on workflow design rather than the platform itself.

How does the attack unfold?

Untrusted input reaches workflow

Externally-controlled data (webhook payload, email, API response, or AI agent tool output) is ingested by an n8n workflow and referenced in a Snowflake node expression.

AML.T0053

Unparameterized SQL construction

The Snowflake node's Execute Query operation interpolates that expression value directly into the raw SQL string instead of binding it as a parameter (CWE-89).

SQL injection execution

The attacker-crafted SQL fragment executes against Snowflake with the privileges of the node's configured credentials.

Data exposure or manipulation

Injected queries read, modify, or delete data in the connected Snowflake warehouse, potentially surfacing sensitive results back through the workflow or agent response.

Untrusted input reaches workflow

Externally-controlled data (webhook payload, email, API response, or AI agent tool output) is ingested by an n8n workflow and referenced in a Snowflake node expression.

AML.T0053

Unparameterized SQL construction

The Snowflake node's Execute Query operation interpolates that expression value directly into the raw SQL string instead of binding it as a parameter (CWE-89).

SQL injection execution

The attacker-crafted SQL fragment executes against Snowflake with the privileges of the node's configured credentials.

Data exposure or manipulation

Injected queries read, modify, or delete data in the connected Snowflake warehouse, potentially surfacing sensitive results back through the workflow or agent response.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 38% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

1) Patch n8n to 1.123.67, 2.31.5, or 2.32.1 or later, which introduces an optional 'Query Parameters' field enabling positional-placeholder binding instead of string interpolation. 2) Audit all existing workflows containing a Snowflake node's Execute Query operation and identify any that build the SQL string using expressions referencing webhook data, form input, HTTP request nodes, or AI/LLM node outputs. 3) Migrate those queries to use the new parameterized Query Parameters field rather than inline expression interpolation. 4) Where immediate patching isn't possible, apply the principle of least privilege to the Snowflake credentials used by the node (read-only role, restricted schema access) to limit blast radius. 5) For detection, review Snowflake query history/audit logs for anomalous query patterns (unexpected UNION, stacked queries, or DDL/DML from the n8n service account) originating from workflows that ingest external input.

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?

Code Execution Data Extraction Agent Plugin AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-72750?

n8n's Snowflake node lets workflow authors interpolate expression values directly into a raw SQL string for its Execute Query operation, so any externally-controlled data referenced in that expression — a webhook payload, an email body, a third-party API response — flows unparameterized into the query and can inject arbitrary SQL against the connected Snowflake warehouse. The real-world risk is workflow-dependent rather than remotely exploitable out of the box: it requires a workflow author to have already wired untrusted input into a raw SQL string, a common shortcut in automation platforms increasingly used to connect AI agents to enterprise data warehouses. EPSS sits at just 0.00211 (top 88th percentile, still a low absolute probability), there's no public exploit or Nuclei scanner template, it's absent from CISA KEV, and CISA scored it TRACK — monitor, not urgent. Upgrade to n8n 1.123.67, 2.31.5, or 2.32.1, which adds an optional 'Query Parameters' field for positional-placeholder binding, and in the meantime audit existing workflows for any Snowflake Execute Query node that concatenates expression data — especially from webhook, form, or AI-agent-tool trigger nodes — into the raw SQL string instead of using bound parameters.

Is CVE-2026-72750 actively exploited?

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

How to fix CVE-2026-72750?

1) Patch n8n to 1.123.67, 2.31.5, or 2.32.1 or later, which introduces an optional 'Query Parameters' field enabling positional-placeholder binding instead of string interpolation. 2) Audit all existing workflows containing a Snowflake node's Execute Query operation and identify any that build the SQL string using expressions referencing webhook data, form input, HTTP request nodes, or AI/LLM node outputs. 3) Migrate those queries to use the new parameterized Query Parameters field rather than inline expression interpolation. 4) Where immediate patching isn't possible, apply the principle of least privilege to the Snowflake credentials used by the node (read-only role, restricted schema access) to limit blast radius. 5) For detection, review Snowflake query history/audit logs for anomalous query patterns (unexpected UNION, stacked queries, or DDL/DML from the n8n service account) originating from workflows that ingest external input.

What systems are affected by CVE-2026-72750?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration pipelines, data warehouse integrations.

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

CVE-2026-72750 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.47%.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration pipelinesdata warehouse integrations

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

n8n before 1.123.67, 2.31.5, and 2.32.1 contains a SQL injection vulnerability in the Snowflake node's Execute Query operation, which interpolates expression values directly into the SQL string. When a workflow author embeds untrusted, externally-controlled expression data directly in a raw SQL query, that data is not parameterized, allowing SQL injection. The fix adds an optional 'Query Parameters' field to bind values via positional placeholders.

Exploitation Scenario

An organization builds an n8n workflow where an AI support agent ingests customer emails, extracts a ticket ID or account reference via an LLM node, and passes that value into a Snowflake node's Execute Query operation to pull account history for the agent to summarize. An attacker submits a crafted support email containing a value like `' UNION SELECT credit_card_number FROM billing_accounts --` in the field the LLM extracts and forwards unmodified. Because the Snowflake node interpolates that string directly into the raw SQL text instead of binding it as a parameter, the injected UNION clause executes with the Snowflake service account's privileges, returning sensitive billing data back through the agent's response pipeline — potentially surfaced directly in the AI agent's reply to the attacker.

Weaknesses (CWE)

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Primary CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

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.