n8n SQL Injection: When Low-Code Meets High-Risk

We all love n8n. It’s the 'Swiss Army Knife' of the modern web, letting developers and ops teams stitch together disparate APIs into beautiful, flowing pipelines of data. It executes code, moves files, and—crucially—talks to your databases. But here is the thing about Swiss Army Knives: if you hold them wrong, you cut your fingers off.

In this case, the knife slipped in the most classic way possible: SQL Injection. The vulnerability (GHSA-f3f2-mcxc-pwjx) resides deep within the core nodes that n8n uses to communicate with Microsoft SQL Server, MySQL, and PostgreSQL. It turns out that n8n was trusting user inputs a little too much when constructing dynamic queries.

Imagine a scenario where a low-level analyst has permission to create workflows to generate reports. Usually, they are confined to SELECT statements on harmless tables. With this bug, that analyst could craft a table name or a filter condition that convinces the database server to drop the users table, exfiltrate password hashes, or—in the case of MS SQL—potentially pop a shell if xp_cmdshell is enabled. It is a stark reminder that 'low-code' often means 'low-visibility' on security flaws.

The root cause here is a tale as old as time: string concatenation. Developers often assume that if they wrap an identifier in quotes or brackets, it's safe. It is not.

The MS SQL Mistake

In Microsoft SQL Server, it is common practice to wrap table and column names in square brackets (e.g., [MyTable]) to handle spaces or reserved keywords. The n8n developers implemented this, but they forgot one crucial detail: you have to escape the closing bracket.

If the application takes your input MyTable and wraps it as [MyTable], what happens if you input MyTable] ; DROP TABLE secrets; --?

The application naïvely constructs: [MyTable] ; DROP TABLE secrets; --]. The database sees a valid identifier [MyTable], followed by a semicolon terminating the statement, followed by your malicious payload. The trailing ] becomes a syntax error or is commented out, but by then, the damage is done.

The MySQL & PostgreSQL Mistake

For the open-source databases, the flaw was slightly different but equally embarrassing. The LIMIT and WHERE clauses were being constructed by directly appending user-supplied strings to the query.

In many n8n nodes, you can set a 'Limit' for the number of rows returned. If you set that limit to 10; DROP TABLE users, and the code just does ... LIMIT + input, you have just successfully executed a stacked query injection (depending on the driver configuration).

Let's look at the diffs. The vulnerability existed in GenericFunctions.ts and specific node implementation files. The fix involved moving from naive string manipulation to robust validation and escaping.

The Vulnerable MS SQL Logic:

Before the patch, the code essentially did this for column mapping:

// Vulnerable: Naive wrapping
return columns.split(',').map((column) => `[${column.trim()}]`).join(', ');

It blindly trusts that column does not contain a closing bracket ].

The Fix (Commit f73fae6):

The patch introduces a validator or stricter escaping. For the WHERE clauses in MySQL/Postgres, they implemented an allowlist for operators. Instead of letting the user type any operator (like = 1; DROP...), the code now checks if the operator is in a safe list:

// The Fix: Whitelisting operators
const allowedOperators = [
  'equal', '=', '!=', 'LIKE', '>', '<', '>=', '<=', 
  'IS NULL', 'IS NOT NULL'
];
 
if (!allowedOperators.includes(operator)) {
  throw new Error('Invalid operator');
}

This simple check neutralizes the attack vector for the WHERE clause by ensuring that the "operator" is actually a mathematical or logical symbol, not an arbitrary SQL string. For identifiers, they likely moved to using the database driver's native escaping methods or rigorously escaping the delimiter characters.

How would an attacker weaponize this? Let's assume you have access to an n8n instance, or you can trigger a webhook that feeds data into a vulnerable node.

Scenario 1: MS SQL Injection via Table Name

You are creating a workflow that inserts data into a dynamic table. The table name is pulled from a JSON input.

• Input: AuditLog] WITH (NOLOCK); WAITFOR DELAY '0:0:05'; --
• Generated SQL: INSERT INTO [AuditLog] WITH (NOLOCK); WAITFOR DELAY '0:0:05'; --] ...

If the application pauses for 5 seconds, you have confirmed injection. From here, you can escalate to data extraction or xp_cmdshell if you are lucky (or unlucky, if you are the admin).

Scenario 2: PostgreSQL LIMIT Injection

Postgres allows stacked queries if the underlying driver supports it (which is common in Node.js environments using pg).

• Target: A workflow querying a customer list.
• Malicious Input (Limit): 1; UPDATE users SET password_hash = '...' WHERE admin = true; --
• Generated SQL: SELECT * FROM customers LIMIT 1; UPDATE users SET password_hash = '...' WHERE admin = true; --

The first query runs (returns 1 row), and the second query runs immediately after, resetting the admin password.

> [!CAUTION] > Re-exploitation Potential: Even after patching, always verify that your database drivers are configured to disable multiple statements (stacked queries) unless absolutely necessary. This is a defense-in-depth measure that n8n's code fix essentially emulates by validating input, but the database config is the final backstop.

Why is this a big deal? n8n is an integration tool. It is designed to have access to everything: your CRM, your payment processor, your internal databases, and your Slack.

If an attacker compromises the n8n database connection:

1. Lateral Movement: They can pivot from the database to other connected services.
2. Data Exfiltration: SELECT * FROM users is just the start. They could dump your entire customer database.
3. Data Destruction: DROP TABLE or DELETE FROM commands are trivial to execute.
4. RCE: In some configurations (Postgres COPY TO PROGRAM, MS SQL xp_cmdshell, MySQL INTO OUTFILE), SQL injection leads directly to Remote Code Execution on the database server itself.

Since n8n is often deployed internally behind a firewall but accessible via webhooks, this vulnerability could turn a minor SSRF or a compromised low-level account into a full infrastructure compromise.

The remediation is straightforward but urgent.

1. Update n8n Upgrade to version 2.4.0 or later immediately. The patch creates a hard whitelist for query operators and sanitizes identifiers correctly.

2. Least Privilege (The Real Fix) Why does your n8n instance need DROP TABLE permissions? It probably doesn't.

Review the database users credentials stored in n8n credentials:

• Revoke DROP, ALTER, and GRANT permissions.
• Restrict access to only the specific schemas/tables the workflow actually needs.
• Disable stacked queries in your database driver configuration if possible.

3. Audit Workflows Check your existing workflows for any nodes that accept user input for Table Names or raw SQL parameters. Even with the patch, passing raw user input into a "Execute Query" node (if used explicitly) remains a risky design pattern.