CVE-2026-72775 is a SQL injection flaw in the n8n Postgres Trigger node. Channel, function and trigger names were placed into SQL statements without proper escaping, so an authenticated user could run SQL with the credential's privileges. The record scores it 8.8, High. Upgrade to 1.123.67, 2.31.5 or 2.32.1.
What's affected
The advisory lists affected versions as anything before 1.123.67 on the 1.x line, before 2.31.5 on the 2.31 line, and before 2.32.1 on the 2.32 line. The patched releases are 1.123.67, 2.31.5 and 2.32.1.
The attacker needs an account that can build workflows with this node. The advisory says successful exploitation gives full read and write access to the connected PostgreSQL database, within the limits of the credential the node uses. A credential with broad rights makes the damage broad.
The weakness class is CWE-89, SQL injection. Here the unsafe values are identifiers such as names, which cannot be passed as ordinary query parameters and so must be quoted with care.
How to check if you're exposed
Find the version of every n8n instance you run, including containers and any copy bundled in another product.
n8n --version
docker exec <container-name> n8n --version
npm ls n8n
If the version is below the patched release for your line, you are in the affected range. Remember that n8n often runs as a base image tag in Docker or Kubernetes, so check image tags in your manifests as well as running hosts. A dependency scan of the repository that holds your deployment files will surface pinned n8n packages. The free in-browser scan at gold.safeguard.sh/scan accepts a manifest and lists known CVEs for what it finds.
Then check how your Postgres credentials are set up. List the database roles that n8n uses and what each can do. The advisory notes that the credentials should have the minimum privileges needed and should not be superuser roles.
SELECT rolname, rolsuper FROM pg_roles WHERE rolname = 'your_n8n_role';
Replace the role name with your own. If rolsuper is true, fix that whether or not you use the Postgres Trigger node.
What to do now
- Upgrade n8n to 1.123.67, 2.31.5 or 2.32.1 or later.
- If you cannot upgrade now, add n8n-nodes-base.postgresTrigger to the NODES_EXCLUDE environment variable.
- Limit instance access to fully trusted users.
- Reduce each n8n Postgres credential to the minimum privileges required, and remove any superuser role.
- Check database logs for unusual statements from the n8n role, such as schema changes or reads of unrelated tables.
- Rotate the Postgres credential if you see signs of misuse.
Why it matters
Identifiers are a known weak spot. Parameter binding protects values, but a channel, function or trigger name is part of the statement itself. Code that builds the statement by joining strings has to quote those names correctly, and when it does not, a name can carry extra SQL.
The sources differ on rating. The record says 8.8 High under CVSS 3.1. The GitHub advisory labels it Moderate at 5.8 under CVSS 4.0, and VulnCheck lists medium at 5.8. The gap reflects different views of how much an authenticated user can really do. Your own answer depends on the database role. A narrow role limits the damage to what that role can reach, and a broad one does not. No source says it has been exploited in the wild, and it is not on the CISA KEV list.
Quick check
Which values were injectable?
The channel, function and trigger name parameters of the Postgres Trigger node.
How does a least privilege role help?
The injected SQL runs with the node credential's privileges, so a narrow role limits what it can read or change.
Sources
Last reviewed: 18 October 2026.
