GHSA-JQWR-VX3P-R266: SQL Injection in n8n PostgresTrigger Node

n8n relies on node integrations to perform a wide variety of actions, with the PostgresTrigger node facilitating continuous integration with PostgreSQL environments. This node acts as an event subscriber, monitoring target tables for activity such as row insertions, modifications, or deletions, and passing those events downstream to activate active workflows. To handle these events asynchronously, n8n must programmatically configure event listeners inside the target database schema. This operation requires executing Data Definition Language (DDL) and administrative operations dynamically.

The vulnerability resides in the way these administrative queries are assembled. Under normal operations, the application creates custom stored procedures, trigger bindings, and asynchronous publication channels on the fly. Because user input is accepted to specify identifiers such as the helper function name, trigger name, or notification channel, the application exposes an attack surface to anyone authorized to construct or modify workflows.

If an attacker can manipulate these properties, they can bypass the intended query parameters and insert raw SQL commands. Because these queries run with the privileges of the connected PostgreSQL server account, a SQL injection flaw in this component can result in a significant compromise of the downstream database server.

The underlying issue stems from a structural constraint in standard SQL databases and query drivers. Standard parameterized queries, which replace placeholders like $1 or ? with verified literal values, only support Data Manipulation Language (DML) fields, such as strings, integers, or dates inside a WHERE or VALUES clause. Database drivers cannot accept structural SQL identifiers, such as database names, table names, function names, trigger bindings, or logical operators, as parameters.

To construct DDL queries dynamically, applications must instead build the query string programmatically. When doing so, developers must sanitize, escape, or explicitly quote all user-controlled database identifiers before concatenating them into the final SQL command template. In vulnerable versions of n8n, this safety layer was absent.

Specifically, when configuring or running the PostgresTrigger node, n8n dynamically generated statements to declare trigger functions and bind them to tables. The engine performed direct string interpolation on identifier fields like the PostgreSQL channel name, trigger function name, and trigger identifier. Because the backend trusted these inputs without applying identifier quoting mechanics, arbitrary SQL payloads were inserted directly into the query execution pipeline.

Below is a conceptual representation of the vulnerable code pattern contrasted with the secure implementation designed for the patch.

In the vulnerable codebase, string interpolation was performed directly inside DDL templates, ignoring the structural nature of the variables:

// Vulnerable Implementation Pattern
async function setupPostgresTrigger(client, config) {
  const functionName = config.functionName; // Unsanitised user input
  const triggerName = config.triggerName;   // Unsanitised user input
  const tableName = config.tableName;       // Schema identifier
 
  // Directly interpolating user input into structural commands
  const createFunctionQuery = `
    CREATE OR REPLACE FUNCTION ${functionName}()
    RETURNS trigger AS $$
    BEGIN
      PERFORM pg_notify('n8n_db_event', TG_TABLE_NAME);
      RETURN NEW;
    END;
    $$ LANGUAGE plpgsql;
  `;
 
  const createTriggerQuery = `
    CREATE TRIGGER ${triggerName}
    AFTER INSERT OR UPDATE ON ${tableName}
    FOR EACH ROW EXECUTE FUNCTION ${functionName}();
  `;
 
  await client.query(createFunctionQuery);
  await client.query(createTriggerQuery);
}

In the patched versions, the application ensures that all user-provided structural identifiers are passed through a defensive escaping function. In PostgreSQL environments, identifiers must either be wrapped in double-quotes and have internal double-quotes doubled, or be processed using specific library utilities like pg-format (such as the %I format specifier):

// Patched Implementation Pattern
import pgFormat from 'pg-format';
 
async function setupPostgresTriggerPatched(client, config) {
  // Utilising pgFormat.ident to properly escape SQL identifiers
  const escapedFunctionName = pgFormat.ident(config.functionName);
  const escapedTriggerName = pgFormat.ident(config.triggerName);
  const escapedTableName = pgFormat.ident(config.tableName);
 
  // The identifiers are safely enclosed in double-quotes, neutralising injection
  const createFunctionQuery = pgFormat(`
    CREATE OR REPLACE FUNCTION %I()
    RETURNS trigger AS $$
    BEGIN
      PERFORM pg_notify('n8n_db_event', TG_TABLE_NAME);
      RETURN NEW;
    END;
    $$ LANGUAGE plpgsql;
  `, config.functionName);
 
  const createTriggerQuery = pgFormat(`
    CREATE TRIGGER %I
    AFTER INSERT OR UPDATE ON %I
    FOR EACH ROW EXECUTE FUNCTION %I();
  `, config.triggerName, config.tableName, config.functionName);
 
  await client.query(createFunctionQuery);
  await client.query(createTriggerQuery);
}

This structural shift from direct string interpolation to strict identifier formatting ensures that any injected structural symbols are interpreted strictly as literal components of the identifier name, thereby neutralizing the SQL syntax breakout.

Exploitation of this vulnerability requires network access to the n8n application interface and a set of active, low-privilege credentials capable of creating or editing workflows. The attacker must also target a workflow that contains (or is configured to contain) a valid PostgreSQL connection.

The following diagram illustrates the lifecycle of an exploitation attempt:

To execute an attack, the adversary inputs a crafted string into the Function Name property of the PostgresTrigger node configuration. For instance, by supplying a payload containing a semicolon followed by a secondary command, the engine divides the execution block:

payload_func(); DROP TABLE application_users; --

When the workflow is saved, activated, or tested, n8n sends the command to the PostgreSQL server. The database parser interprets the input as follows:

1. It processes the initial CREATE OR REPLACE FUNCTION payload_func()... command.

2. It detects the semicolon, closing the initial declaration context.

3. It treats the next sequence, DROP TABLE application_users, as a separate, subsequent statement, executing it immediately.

4. It treats the double hyphens (--) as a comment, ignoring any leftover structural syntax from the original template.

The direct impact of successful exploitation is defined by the capabilities and permissions of the database user configured inside n8n. If the node runs with basic read and write permissions, the attacker can manipulate, delete, or exfiltrate all tables within the accessible schemas. This can compromise credential stores, transactional data, or operational parameters.

If the configured database account possesses elevated administrative privileges or is a SUPERUSER, the risk surface expands significantly. Under these conditions, an attacker can pivot from SQL execution to system-level commands on the underlying host operating system. This is frequently achieved using PostgreSQL-specific functionalities like COPY ... TO PROGRAM or administrative extensions:

-- Command execution template via COPY TO PROGRAM
COPY (SELECT 1) TO PROGRAM 'id > /tmp/out';

The CVSS v4.0 assessment registers a base score of 5.8. Although the initial impact to n8n itself is low since the host container or server environment is separate, the subsequent impact to the database infrastructure is classified as high across confidentiality, integrity, and availability.

The primary and recommended action is to update the n8n deployment to a patched release. Ensure your platform is aligned with one of the following official versions:

• Version 1.123.67 or later (for 1.x installations)

• Version 2.31.5 or later (for 2.x stable installations)

• Version 2.32.1 or later (for 2.x latest installations)

If immediate upgrading is not possible, the PostgresTrigger node can be deactivated globally to eliminate the vulnerability's attack surface. To do this, configure the NODES_EXCLUDE environment variable in the host system configuration:

export NODES_EXCLUDE="n8n-nodes-base.postgresTrigger"

Furthermore, apply the principle of least privilege to all database connections configured in n8n. Ensure that the database users assigned to these credentials do not have SUPERUSER privileges, and explicitly restrict their abilities to create, modify, or execute procedures outside of the minimum functional scope required for the integration.