AI Threat Alert
The n8n Snowflake node's Execute Query operation builds SQL by directly interpolating expression values into the query string instead of using bound parameters, creating a classic CWE-89 SQL injection whenever a workflow embeds untrusted data in a raw query. This matters because n8n is an AI agent orchestration platform with 16 downstream dependents, a middling OpenSSF Scorecard of 6.6/10, and a track record of 166 other CVEs, and because n8n workflows increasingly wire external webhooks, triggers, and LLM agent outputs straight into data-warehouse operations — exactly the pattern this bug punishes. There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template, and the advisory itself notes exploitation requires a workflow author to have already embedded untrusted expression data in a raw SQL string, so this is not remotely exploitable out of the box — it's a design footgun rather than an actively weaponized flaw. Patch to n8n 1.123.67, 2.31.5, or 2.32.1 and migrate Snowflake Execute Query nodes to the new parameterized "Query Parameters" field; until then, restrict workflow creation/edit permissions, audit any existing workflows using the Snowflake `executeQuery` operation for expressions built from external input, and lock down network access to webhooks/triggers that feed those nodes.
What is the risk?
Medium severity with no CVSS vector published. Exploitability is conditional rather than direct: an attacker cannot trigger this remotely unless a workflow author has already designed a workflow that interpolates untrusted expression data into a raw Snowflake SQL string — this is closer to an insecure-by-default API surface than a network-exploitable bug. No CISA KEV entry, no EPSS score, and no public exploit code or Nuclei template exist, indicating no evidence of active or scripted exploitation. The primary risk driver is exposure: n8n's role as an AI agent/workflow automation platform means untrusted inputs (webhooks, third-party API responses, LLM-generated content) commonly flow into downstream integrations like Snowflake, so the real-world risk depends heavily on how permissively an organization has configured workflow authoring and what data-warehouse permissions the Snowflake credentials in question hold.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | < 1.123.67 | 1.123.67 |
Do you use n8n? You're affected.
How severe is it?
What should I do?
1 step-
1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later. 2) Rebuild affected Snowflake Execute Query nodes to use the new "Query Parameters" field with positional placeholders instead of string interpolation. 3) Interim workaround: restrict workflow creation/editing to fully trusted users only. 4) Audit all existing workflows that use the Snowflake
executeQueryoperation and check for any expression resolving to externally-controlled data embedded directly in the raw SQL string. 5) Restrict network access to any webhook/trigger endpoints that feed data into those Snowflake nodes. 6) Detection: review Snowflake query logs for anomalous or malformed SQL syntax originating from the n8n service account, and flag workflows where trigger/webhook payloads pass unsanitized into database node expressions.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-652q-gvq3-74qv?
The n8n Snowflake node's Execute Query operation builds SQL by directly interpolating expression values into the query string instead of using bound parameters, creating a classic CWE-89 SQL injection whenever a workflow embeds untrusted data in a raw query. This matters because n8n is an AI agent orchestration platform with 16 downstream dependents, a middling OpenSSF Scorecard of 6.6/10, and a track record of 166 other CVEs, and because n8n workflows increasingly wire external webhooks, triggers, and LLM agent outputs straight into data-warehouse operations — exactly the pattern this bug punishes. There is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template, and the advisory itself notes exploitation requires a workflow author to have already embedded untrusted expression data in a raw SQL string, so this is not remotely exploitable out of the box — it's a design footgun rather than an actively weaponized flaw. Patch to n8n 1.123.67, 2.31.5, or 2.32.1 and migrate Snowflake Execute Query nodes to the new parameterized "Query Parameters" field; until then, restrict workflow creation/edit permissions, audit any existing workflows using the Snowflake `executeQuery` operation for expressions built from external input, and lock down network access to webhooks/triggers that feed those nodes.
Is GHSA-652q-gvq3-74qv actively exploited?
No confirmed active exploitation of GHSA-652q-gvq3-74qv has been reported, but organizations should still patch proactively.
How to fix GHSA-652q-gvq3-74qv?
1) Upgrade to n8n 1.123.67, 2.31.5, 2.32.1, or later. 2) Rebuild affected Snowflake Execute Query nodes to use the new "Query Parameters" field with positional placeholders instead of string interpolation. 3) Interim workaround: restrict workflow creation/editing to fully trusted users only. 4) Audit all existing workflows that use the Snowflake `executeQuery` operation and check for any expression resolving to externally-controlled data embedded directly in the raw SQL string. 5) Restrict network access to any webhook/trigger endpoints that feed data into those Snowflake nodes. 6) Detection: review Snowflake query logs for anomalous or malformed SQL syntax originating from the n8n service account, and flag workflows where trigger/webhook payloads pass unsanitized into database node expressions.
What systems are affected by GHSA-652q-gvq3-74qv?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation pipelines, data warehouse integrations.
What is the CVSS score for GHSA-652q-gvq3-74qv?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049 Exploit Public-Facing Application AML.T0053 AI Agent Tool Invocation AML.T0086 Exfiltration via AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
## Impact The n8n Snowflake node's Execute Query operation interpolated expression values directly into the SQL string, making queries built with untrusted data susceptible to SQL injection. Exploitation requires that a workflow author has already embedded untrusted expression data directly in a raw SQL query. ## Patches The issue has been fixed in n8n versions 1.123.67, 2.31.5, and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. The fix introduces an optional "Query Parameters" field that allows values to be bound via positional placeholders rather than interpolated into the query string. ## Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict workflow creation and editing permissions to fully trusted users only. - Audit existing workflows that use the Snowflake `executeQuery` operation and ensure no expression resolving to externally-controlled data is embedded directly in a raw SQL query string. - Restrict network access to any webhook or trigger endpoints that feed data into Snowflake `executeQuery` nodes. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Exploitation Scenario
An organization has an n8n workflow where a public-facing webhook (e.g., a support-ticket form or a partner API callback) feeds a field into a Snowflake Execute Query node, and the workflow author interpolated that field directly into a raw SQL string rather than using bound parameters. An attacker submits a payload through the webhook containing SQL metacharacters designed to break out of the intended query context, injecting a UNION SELECT or stacked query that reads unrelated tables, dumps credentials or customer data, or modifies/deletes warehouse records. In an agent context, the untrusted input could instead be the output of an upstream LLM agent step that was itself manipulated via prompt injection, turning a content-manipulation attack into direct SQL injection against the connected data warehouse — escalating from an AI-specific vector into a traditional data breach.
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.
References
Timeline
Related Vulnerabilities
CVE-2026-33663 10.0 n8n: member role steals plaintext HTTP credentials
Same package: n8n CVE-2026-33660 10.0 TensorFlow: type confusion NPD in tensor conversion
Same package: n8n CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same package: n8n CVE-2026-27577 9.9 n8n: Code Injection enables RCE
Same package: n8n CVE-2026-27494 9.9 n8n: security flaw enables exploitation
Same package: n8n