GHSA-652q-gvq3-74qv: n8n: Snowflake Node executeQuery Operation Allows SQL Injection via Unparameterized Expression Interpolation

In the Snowflake node's executeQuery operation, an expression such as a webhook field or an upstream node's output was substituted into the query text. Nothing escaped it or bound it as a parameter. If the value came from an outside party, they could add SQL of their own. The query then ran with the rights of the Snowflake credential in the node.

The advisory is clear about the precondition: a workflow author must have embedded untrusted expression data directly in a raw SQL query. A typical case is a webhook-triggered workflow that takes a customer name from the request body and writes it into a WHERE clause. The attacker needs no n8n account in that case, only the ability to reach the webhook or trigger that feeds the node. The CVSS vector lists low privileges and a present attack requirement, and rates the effect on the downstream Snowflake system as high for confidentiality and integrity.

In practice an attacker could read tables the credential can read, or change data it can write.

The npm package n8n below 1.123.67 on the 1.x line, >= 2.0.0-rc.0, < 2.31.5, and 2.32.0. Only workflows that use the Snowflake node's executeQuery operation with expressions inside the raw SQL are exposed.

npm ls n8n

Then search your workflows for Snowflake nodes set to Execute Query that contain {{ ... }} expressions in the query field.

Upgrade n8n to 1.123.67, 2.31.5 or 2.32.1, or later, matching your release line. The fix adds an optional "Query Parameters" field. Rewrite affected queries to use positional placeholders and put the values in that field, so they are bound and not interpolated. Upgrading alone does not rewrite old workflows.

Temporary measures from the advisory, which it says do not fully remove the risk:

• Limit workflow creation and editing to fully trusted users.
• Audit Snowflake executeQuery workflows and remove expressions that resolve to externally controlled data from the raw SQL.
• Limit network access to webhook or trigger endpoints that feed those nodes.

Review the Snowflake query history for your n8n service account. Look for statements that contain unexpected extra clauses, UNION, comments, or tables the workflow never touches, and for failed queries with syntax errors that line up with requests to a webhook. Compare executed SQL with what the workflow is meant to produce.

In n8n, check execution data of Snowflake executeQuery nodes for inputs holding quotes, semicolons or SQL keywords. Also check the webhook's access logs for the same requests.

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.