GHSA-jqwr-vx3p-r266: n8n: PostgresTrigger Node SQL Injection Allows Authenticated Users to Execute Arbitrary SQL on Connected PostgreSQL Instances

The Postgres Trigger node listens for database events. To do that it creates objects in PostgreSQL: a trigger function, a trigger, and a LISTEN channel. It built those statements by inserting the identifier parameters (channel name, function name, trigger name) into the SQL text, with no quoting or escaping. Identifiers cannot be bound as query parameters, so they must be escaped by the code, and this was missing.

An n8n user who can set up or edit a Postgres Trigger node can put SQL in one of those fields. The injected statement runs on the connected database with the privileges of the Postgres credential stored in n8n. The advisory says this gives full read and write access to the database.

The attacker needs an n8n account and rights to create or edit workflows with a Postgres credential they can use. The n8n server itself is not directly harmed, as the CVSS vector shows. The harm falls on the PostgreSQL database behind it. The damage depends on the credential: a superuser role could reach much further than a narrowly scoped one.

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 Postgres Trigger node (n8n-nodes-base.postgresTrigger) are in scope.

npm ls n8n

Then look for Postgres Trigger nodes in your workflows, and for the Postgres credentials they use and who can use them.

Upgrade n8n to 1.123.67, 2.31.5 or 2.32.1, or later, matching your release line.

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

• Limit instance access to fully trusted users.
• Turn off the node by adding n8n-nodes-base.postgresTrigger to the NODES_EXCLUDE environment variable.
• Give n8n's PostgreSQL credentials the least privileges they need, and do not use SUPERUSER roles.

Look in the PostgreSQL logs (with log_statement set to ddl or all) for CREATE FUNCTION, CREATE TRIGGER and LISTEN statements issued by the n8n role whose names contain quotes, semicolons, comments or extra SQL keywords. Check for triggers and functions on your tables that you did not create. Review statements run by the n8n role that go beyond the trigger setup, such as SELECT from unrelated tables, or COPY, DROP and ALTER.

In n8n, review Postgres Trigger nodes whose channel, function or trigger name fields hold odd text.

Impact

The Postgres Trigger node interpolated user-supplied identifier parameters (channel, function, and trigger names) into SQL statements without proper escaping, so an authenticated user could inject arbitrary SQL executed against the connected PostgreSQL database with the configured credential's privileges.

Successful exploitation allows full read and write access to the connected PostgreSQL database.

Patches

The issue has been fixed in n8n versions 1.123.67, 2.31.5 and 2.32.1. Users should upgrade to these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Restrict n8n instance access to fully trusted users only.
• Disable the PostgresTrigger node by adding n8n-nodes-base.postgresTrigger to the NODES_EXCLUDE environment variable.
• Ensure PostgreSQL credentials used with n8n are configured with the minimum required privileges and do not use SUPERUSER roles.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.