n8n Snowflake Node SQL Injection via Unparameterized Expression Interpolation
First seen Jul 23, 2026 · Updated Jul 23, 2026
The n8n Snowflake node's Execute Query operation directly interpolates workflow expression values into raw SQL strings instead of using parameterized queries, creating a classic SQL injection risk. Exploitation requires a workflow author to have already wired untrusted external data (e.g., from a webhook) into the raw query, so it is a secondary/contributing weakness rather than a directly remotely exploitable flaw on its own. This is a traditional application security bug in an automation tool that is increasingly used as an agentic tool-calling backend, not an AI-specific attack technique.
Technical Analysis
The Snowflake node's executeQuery operation builds SQL by string interpolation of resolved n8n expressions rather than binding them as parameters, so any expression value derived from untrusted input (form submissions, webhook payloads, upstream API responses, or LLM-generated tool arguments) can inject arbitrary SQL syntax into the executed statement. The entry point is any workflow trigger or node output that feeds data into the Snowflake node's raw query field, meaning the vulnerability crosses a trust boundary whenever an AI agent or upstream automation step supplies query content on behalf of a user. An attacker who controls that upstream data can manipulate, exfiltrate, or destroy data in the connected Snowflake instance, effectively achieving database-level command injection through the automation pipeline. The fix adds an optional parameter-binding field (positional placeholders) so values are no longer embedded in the SQL text, closing the injection path when adopted by workflow authors.
Affected Systems
n8n
Detection Signatures
- Workflow definitions where Snowflake executeQuery node's 'query' field contains embedded {{$json...}} or expression syntax referencing external/user-controlled data
- Log entries showing Snowflake queries with unexpected SQL syntax, stacked queries, or comment sequences (--, /*, ;) originating from webhook-triggered workflows
- Workflows lacking use of the new 'Query Parameters' field after upgrading to patched n8n versions
- Audit trail showing webhook or trigger-fed data reaching raw SQL execution nodes without sanitization
Remediation Steps
- 1
Upgrade n8n
Update to n8n 1.123.67, 2.31.5, 2.32.1, or later, which introduces parameterized query binding for the Snowflake executeQuery operation.
- 2
Adopt parameterized queries
Migrate existing Snowflake executeQuery workflows to use the new Query Parameters field instead of interpolating expressions directly into SQL strings.
- 3
Audit existing workflows
Review all workflows using the Snowflake executeQuery node for expressions that resolve to externally-controlled or user-supplied data embedded in raw SQL.
- 4
Restrict workflow authoring permissions
Limit who can create or edit workflows with database-executing nodes to trusted, vetted users until upgrades are applied.
- 5
Harden trigger/webhook exposure
Restrict network access to webhook or trigger endpoints that supply data consumed by Snowflake executeQuery nodes to reduce the attack surface for injecting malicious input.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.