n8n PostgresTrigger Node SQL Injection via Unsanitized Identifiers
First seen Jul 23, 2026 · Updated Jul 23, 2026
The n8n PostgresTrigger node, commonly used by AI agent and automation workflows to connect to PostgreSQL databases, failed to properly escape user-supplied identifier fields (channel, function, trigger names) before embedding them in SQL statements. This allowed authenticated n8n users to inject arbitrary SQL, gaining full read/write access to the connected database using the workflow's configured credentials. The issue has been patched; the main risk is privilege escalation by low-trust authenticated users within multi-tenant or shared n8n deployments.
Technical Analysis
The vulnerability lies in the PostgresTrigger node's SQL construction logic, which interpolated user-controlled identifier parameters directly into SQL statements without escaping or parameterization, enabling classic SQL injection. The entry point is any authenticated n8n user with permission to configure or edit workflows containing this node, meaning the attack does not require external network access, only workflow-editing privileges within the platform. Successful exploitation grants the attacker the full privileges of the PostgreSQL credential bound to the workflow, potentially including data exfiltration, data tampering, or further lateral movement if the credential has broad database or superuser rights. This is relevant to agentic systems because n8n workflows are increasingly used as tool-execution backends for AI agents; a compromised or malicious node configuration in an agent's toolchain can silently escalate from workflow-level access to full database compromise, crossing the boundary between the orchestration layer and backend data stores.
Affected Systems
n8n
Detection Signatures
- Anomalous or malformed values in PostgresTrigger channel/function/trigger name fields (e.g., containing quotes, semicolons, SQL keywords like UNION, DROP, --)
- PostgreSQL logs showing unexpected DDL/DML statements originating from n8n service credentials
- Workflow edit/audit logs showing modification of PostgresTrigger node configuration by low-privilege users
- Use of n8n versions prior to 1.123.67, 2.31.5, or 2.32.1
Remediation Steps
- 1
Upgrade n8n
Update to n8n 1.123.67, 2.31.5, 2.32.1, or later, which contain the fix for identifier escaping in the PostgresTrigger node.
- 2
Restrict workflow editing privileges
Limit which users can create or modify workflows using database trigger nodes, especially in shared or multi-tenant n8n instances.
- 3
Apply least-privilege database credentials
Ensure PostgreSQL credentials used by n8n are scoped to minimum required permissions and never use SUPERUSER roles.
- 4
Disable node if unpatched
If upgrading is not immediately possible, add n8n-nodes-base.postgresTrigger to NODES_EXCLUDE to disable the vulnerable node.
- 5
Monitor database and workflow audit logs
Review PostgreSQL query logs and n8n audit trails for suspicious identifier values or unauthorized workflow changes.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.