CVE-2026-72775: n8n SQL injection — HIGH

CISO Take

n8n's PostgresTrigger node interpolates user-supplied identifiers (channel, function, and trigger names) directly into SQL statements without proper escaping, letting an authenticated n8n user inject arbitrary SQL that executes with the full privileges of the configured PostgreSQL credential. This matters because n8n is widely used to orchestrate AI agent and automation workflows that hold live database credentials, meaning a malicious or compromised low-privilege workflow editor can pivot to full read/write access on any connected Postgres instance — including databases that feed agent context, RAG stores, or business data. The exploitation bar is meaningfully lowered by the fact it only requires authentication rather than remote access, but the urgency signals are otherwise low: EPSS sits at just 0.21%, there's no public exploit or Nuclei template, it's absent from CISA KEV, and CISA's own SSVC decision is TRACK (lowest priority, patch on normal cadence). Patch to n8n 1.123.67, 2.31.5, or 2.32.1; in the interim, restrict PostgresTrigger node configuration to trusted admins only, scope the connected credential to least-privilege database access, and audit Postgres query logs for anomalous DDL/DML from the n8n service account.

Sources: NVD GitHub Advisory EPSS vulncheck.com ATLAS

What is the risk?

Moderate risk in absolute terms, low urgency in relative terms. The vulnerability is a classic, well-understood SQL injection (CWE-89) with severe technical impact — full read/write on the connected database — but it requires the attacker to already hold an authenticated n8n account with permission to configure or edit PostgresTrigger nodes, which meaningfully narrows the realistic attacker population to malicious insiders, compromised low-privilege accounts, or attackers who've already gained a foothold via credential theft or phishing. No CVSS score is published, but the combination of very low EPSS (0.21%), no KEV listing, no public exploit code, no Nuclei template, and a CISA SSVC decision of TRACK all indicate this is not under active or imminent exploitation. Organizations running multi-tenant or shared n8n instances where workflow-editing permissions are broadly granted face the highest exposure.

How does the attack unfold?

Initial Access

An authenticated n8n user with permission to configure workflow nodes accesses or creates a PostgresTrigger node backed by a database credential.

AML.T0012

Exploitation

The attacker supplies a crafted SQL payload in the channel, function, or trigger name parameter, which n8n interpolates into the SQL statement without escaping (CWE-89).

Impact

The injected SQL executes against the connected PostgreSQL database with the configured credential's full privileges, granting the attacker arbitrary read and write access.

Downstream Effect

Data read or modified through the injection can propagate into AI agent workflows that consume the same database, corrupting agent context or exfiltrating sensitive records.

AML.T0080

Initial Access

An authenticated n8n user with permission to configure workflow nodes accesses or creates a PostgresTrigger node backed by a database credential.

AML.T0012

Exploitation

The attacker supplies a crafted SQL payload in the channel, function, or trigger name parameter, which n8n interpolates into the SQL statement without escaping (CWE-89).

Impact

The injected SQL executes against the connected PostgreSQL database with the configured credential's full privileges, granting the attacker arbitrary read and write access.

Downstream Effect

Data read or modified through the injection can propagate into AI agent workflows that consume the same database, corrupting agent context or exfiltrating sensitive records.

AML.T0080

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 38% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

1) Patch immediately to n8n 1.123.67, 2.31.5, or 2.32.1 — the fix addresses improper escaping of identifier parameters in the PostgresTrigger node. 2) Until patched, restrict who can create or edit PostgresTrigger nodes to trusted administrators only (n8n role/permission settings). 3) Apply least-privilege database credentials to any Postgres connection used by n8n — avoid superuser or broad-schema-owner credentials. 4) Enable and review PostgreSQL query/audit logging for unexpected DDL, multi-statement queries, or access to tables outside the workflow's expected scope. 5) If multi-tenant n8n is in use, treat this as a reminder to review tenant isolation and credential scoping generally.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Data Leakage Agent Plugin AML.T0053 - AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

NIST AI RMF

MANAGE 4.1 - Risks and benefits from third-party resources are regularly monitored

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-72775?

n8n's PostgresTrigger node interpolates user-supplied identifiers (channel, function, and trigger names) directly into SQL statements without proper escaping, letting an authenticated n8n user inject arbitrary SQL that executes with the full privileges of the configured PostgreSQL credential. This matters because n8n is widely used to orchestrate AI agent and automation workflows that hold live database credentials, meaning a malicious or compromised low-privilege workflow editor can pivot to full read/write access on any connected Postgres instance — including databases that feed agent context, RAG stores, or business data. The exploitation bar is meaningfully lowered by the fact it only requires authentication rather than remote access, but the urgency signals are otherwise low: EPSS sits at just 0.21%, there's no public exploit or Nuclei template, it's absent from CISA KEV, and CISA's own SSVC decision is TRACK (lowest priority, patch on normal cadence). Patch to n8n 1.123.67, 2.31.5, or 2.32.1; in the interim, restrict PostgresTrigger node configuration to trusted admins only, scope the connected credential to least-privilege database access, and audit Postgres query logs for anomalous DDL/DML from the n8n service account.

Is CVE-2026-72775 actively exploited?

No confirmed active exploitation of CVE-2026-72775 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-72775?

1) Patch immediately to n8n 1.123.67, 2.31.5, or 2.32.1 — the fix addresses improper escaping of identifier parameters in the PostgresTrigger node. 2) Until patched, restrict who can create or edit PostgresTrigger nodes to trusted administrators only (n8n role/permission settings). 3) Apply least-privilege database credentials to any Postgres connection used by n8n — avoid superuser or broad-schema-owner credentials. 4) Enable and review PostgreSQL query/audit logging for unexpected DDL, multi-statement queries, or access to tables outside the workflow's expected scope. 5) If multi-tenant n8n is in use, treat this as a reminder to review tenant isolation and credential scoping generally.

What systems are affected by CVE-2026-72775?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration / automation pipelines, database-triggered AI agent workflows.

What is the CVSS score for CVE-2026-72775?

CVE-2026-72775 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.47%.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration / automation pipelinesdatabase-triggered AI agent workflows

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

n8n before 1.123.67, 2.31.5, and 2.32.1 contains a SQL injection vulnerability in the PostgresTrigger node, which interpolates user-supplied identifier parameters (channel, function, and trigger names) into SQL statements without proper escaping. An authenticated user can inject arbitrary SQL executed against the connected PostgreSQL database with the configured credential's privileges, allowing full read and write access.

Exploitation Scenario

An organization runs a shared n8n instance where multiple internal teams have workflow-editing access to build automations, including AI agent pipelines that watch a Postgres table for new customer records and trigger an LLM-based enrichment workflow. A disgruntled or compromised low-privilege employee account edits a PostgresTrigger node and supplies a crafted string in the 'channel' or 'trigger name' field containing SQL injection payloads (e.g., stacked queries or UNION-based extraction). Because n8n fails to escape these identifiers, the injected SQL executes against the underlying database using the credential configured for that node — which in this case has broad read/write access to the production schema. The attacker uses this to exfiltrate customer PII from unrelated tables or to modify records that a downstream AI agent workflow later reads, silently corrupting the data the agent acts on.

Weaknesses (CWE)

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Primary CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
[Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Source: MITRE CWE corpus.