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

The Snowflake node in the n8n visual workflow automation platform provides an executeQuery operation designed to run raw SQL statements against a connected Snowflake database instance. Visual workflows in n8n facilitate data movement and manipulation by linking disparate nodes. To pass dynamic values between these nodes, n8n utilizes a double curly brace syntax ({{ ... }}) that evaluates JavaScript-like expressions at runtime.

In vulnerable versions of n8n, when the Snowflake node executes a query containing these expression blocks, the execution engine evaluates the expressions and directly interpolates the resulting string values into the SQL command text. This pattern acts as a literal search-and-replace mechanism prior to query dispatch. The compiled query is then transmitted directly to the database driver for execution.

This behavior exposes a significant attack surface if a workflow author constructs a query containing untrusted input, such as query parameters from an incoming webhook or fields from a public API. Because the user input is not neutralized or parsed structurally, an attacker can break out of the intended query context. This shifts the execution logic and permits unauthorized interactions with the target database.

The fundamental cause of this vulnerability lies in the lack of separation between the code logic (the SQL structure) and the data payload (the expression evaluation values). In secure database interactions, user-supplied inputs are treated as parameters and are bound separately by the database driver. The database driver coordinates with the engine to ensure parameters are treated exclusively as literal values, never as executable code.

In vulnerable versions of the Snowflake node, the application fails to utilize parameter binding for the executeQuery operation. Instead, the node's backend runtime extracts the raw string representing the SQL query, evaluates the internal n8n template syntax, and creates a single monolithic query string. This behavior aligns directly with CWE-89 (SQL Injection).

For the vulnerability to be exploitable, specific conditions must be met within the deployed workflow. A workflow developer must configure a Snowflake node to use the executeQuery operation and manually embed one or more upstream expressions that contain user-controlled fields. If these expressions are placed within single-quoted string literals or raw numeric positions in the SQL template without prior sanitization, the injection point becomes active.

To analyze the vulnerability, we examine the logical transition from unparameterized string concatenation to parameter-bound query execution. In vulnerable implementations, the query execution engine of the Snowflake node processed queries through a pattern resembling the following conceptual structure:

// Vulnerable execution pattern
async function executeQuery(nodeData) {
  // Expressions are resolved to plain strings beforehand
  const rawSqlString = this.getNodeParameter('sqlQuery', itemIndex);
  
  // The raw string is sent directly to the driver
  const connection = getSnowflakeConnection();
  return new Promise((resolve, reject) => {
    connection.execute({
      sqlText: rawSqlString,
      complete: (err, stmt, rows) => {
        if (err) return reject(err);
        resolve(rows);
      }
    });
  });
}

The patch addresses this structural vulnerability by introducing support for query parameters. Instead of forcing raw text interpolation, the database driver's query parameterization feature is exposed to the user interface. The updated code execution pattern utilizes positional placeholders (such as ?) and maps the user-provided expressions to an array of parameters:

// Patched execution pattern
async function executeQuery(nodeData) {
  const rawSqlString = this.getNodeParameter('sqlQuery', itemIndex);
  // Optional helper retrieves designated parameters as an array
  const queryParameters = this.getNodeParameter('queryParameters', itemIndex, []) as any[];
 
  const connection = getSnowflakeConnection();
  return new Promise((resolve, reject) => {
    const executionOptions: any = {
      sqlText: rawSqlString,
      complete: (err, stmt, rows) => {
        if (err) return reject(err);
        resolve(rows);
      }
    };
 
    // If parameters are provided, bind them securely
    if (queryParameters && queryParameters.length > 0) {
      executionOptions.binds = queryParameters;
    }
 
    connection.execute(executionOptions);
  });
}

This remediation ensures that any value supplied via the binds array is correctly handled by the Snowflake database client library. The driver wraps parameters during communication with the Snowflake API, rendering injected SQL metacharacters inert. However, security teams must note that this fix is opt-in for existing workflows; developers must manually rewrite their raw SQL strings to use the positional placeholders.

The exploitation of this vulnerability depends on the configuration of the workflow. The attack vector relies on an external entity being able to control the data fed into the interpolated expressions. The following diagram illustrates the lifecycle of an exploitation attempt from the initial HTTP request to the final database impact:

Consider an administrative lookup query structured as: SELECT * FROM accounts WHERE domain = '{{ $json.body.domain }}'. Under normal usage, a request containing {"domain": "example.com"} generates the query SELECT * FROM accounts WHERE domain = 'example.com'. This returns the expected single row.

To exploit this query, an attacker submits a payload containing a single-quote delimiter followed by structural SQL commands. Sending the string victim.com' UNION SELECT CURRENT_USER(), CURRENT_ROLE(), NULL -- alters the structural meaning of the query. The database interpreter processes the command as two separate SELECT statements merged via a UNION operator. The -- sequence comments out the trailing single quote, preventing syntax errors. This returns sensitive environment credentials and bypasses the application's access constraints.

The primary impact of this vulnerability is the complete compromise of the logical security boundary for the connected Snowflake database. The level of compromise corresponds directly to the privileges of the database credentials stored in n8n. If the connection is configured with administrative privileges (such as ACCOUNTADMIN or SYSADMIN), the attacker gains the ability to create, modify, or delete database objects, read sensitive tables, and potentially pivot to other cloud storage areas associated with the Snowflake account.

The vulnerability is classified with a CVSS v4 score of 5.3 (Medium). This reflects the specific attack requirement (AT:P), which dictates that the vulnerability is not exploitable out of the box unless a workflow developer creates a flawed design. The impact on the n8n host itself is categorized as Low (VC:L/VI:L/VA:N) because the SQL injection executes on the remote database rather than on the local server running n8n. However, the subsequent system impact is High (SC:H/SI:H) due to the direct potential for data theft and modification on the Snowflake target.

Currently, there are no records of active exploitation in the wild, nor is this vulnerability tracked in CISA's Known Exploited Vulnerabilities (KEV) catalog. It represents a typical configuration-dependent vulnerability where the tool provides powerful capabilities but requires manual, secure engineering patterns to prevent exploitation.

To fully address this vulnerability, organizations must apply a two-step remediation strategy involving a platform upgrade followed by manual workflow refactoring.

First, upgrade the n8n application to one of the following secure releases or later: 1.123.67 (for the 1.x release track), 2.31.5 (for 2.x releases), or 2.32.1 (for subsequent releases). Upgrading ensures that the Snowflake node supports the optional Query Parameters binding feature.

Second, security administrators and workflow developers must audit and refactor existing Snowflake configurations. Simply upgrading the platform does not secure workflows that continue to use direct text-replacement expressions. For every node executing a raw query, developers must replace expressions like {{ $json.variable }} with a positional ? placeholder and register the corresponding expression within the newly available 'Query Parameters' option list.

To assist with identifying vulnerable workflows on self-hosted installations, administrators can query the underlying n8n metadata store. For instances backed by PostgreSQL, running the following database query will identify active workflows containing Snowflake nodes running raw queries:

SELECT id, name, active 
FROM workflow_entity 
WHERE active = true 
  AND json::text LIKE '%"nodeType": "n8n-nodes-base.snowflake"%' 
  AND json::text LIKE '%"operation": "executeQuery"%';

Administrators should inspect each returned workflow's definition to verify whether expressions are being interpolated safely using parameters or unsafely via string manipulation.