CVE-2026-56351: n8n: SQL injection in DB nodes via identifier values

HIGH
Published June 24, 2026
CISO Take

n8n before version 2.4.0 contains a SQL injection vulnerability in its MySQL, PostgreSQL, and Microsoft SQL database nodes, where authenticated users can inject arbitrary SQL by supplying crafted table or column names in workflow configurations. For organizations deploying n8n as an AI agent orchestration layer—a common pattern for connecting LLMs to production databases—this is a significant concern: any user with workflow creation permissions can execute unauthorized database commands, compromising data confidentiality and integrity across all connected backend systems. With a CVSS of 8.2 and a changed scope (S:C), successful exploitation cascades beyond n8n into the connected database infrastructure; while no public exploit exists and it is not in CISA KEV, the package carries 111 prior CVEs and an OpenSSF score of only 6.6/10, signaling persistent security debt in this codebase. Organizations should upgrade to n8n 2.4.0 immediately, audit workflow creation permissions, and review database audit logs for anomalous identifier patterns.

Sources: NVD GitHub Advisory ATLAS OpenSSF VulnCheck

What is the risk?

High severity (CVSS 8.2, S:C). Although attack complexity is rated High—implying specific conditions must be met—the low privilege requirement means any n8n user with workflow creation access represents a viable attack vector. The changed scope is the critical differentiator: a compromised n8n instance can affect connected database systems entirely outside the application boundary, multiplying blast radius. No public exploit or active exploitation has been observed, and it is absent from CISA KEV, which moderates urgency somewhat. However, n8n's 111 historical CVEs and below-average OpenSSF scorecard (6.6/10) indicate a pattern of recurring security issues. In AI agent deployments where n8n orchestrates LLM-to-database workflows, successful exploitation could exfiltrate customer PII, AI training corpora, or model configuration data residing in connected databases.

How does the attack unfold?

Initial Access
Attacker authenticates to n8n with a low-privilege account obtained via phishing, credential reuse, or insider access, acquiring workflow creation permissions.
AML.T0012
Exploitation
Attacker creates or modifies a workflow containing a MySQL, PostgreSQL, or MSSQL node, injecting malicious SQL through crafted table or column name identifiers in the node configuration UI.
AML.T0049
Execution
When the workflow executes, unescaped identifier values are passed directly to the database engine, running attacker-controlled SQL with the n8n service account's privileges against the connected database.
AML.T0053
Impact
Attacker exfiltrates sensitive data (customer PII, AI training datasets, model configurations) or manipulates database records feeding downstream AI pipelines, compromising data integrity and confidentiality at scale.
AML.T0086

What systems are affected?

Package Ecosystem Vulnerable Range Patched
n8n npm No patch
193.4K OpenSSF 6.6 Pushed 3d ago 54% patched ~7d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1
8.2 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC High
PR Low
UI None
S Changed
C High
I High
A None

What should I do?

6 steps
  1. Patch: Upgrade n8n to version 2.4.0 or later immediately—this is the only complete fix.

  2. Access control: Audit and restrict workflow creation permissions; treat workflow creation as equivalent to database write access and limit it to trusted personnel only.

  3. Database hardening: Apply least-privilege to n8n database credentials; ensure service accounts cannot execute DDL or DML beyond what legitimate workflows require, and separate credentials per environment.

  4. Detection: Review database audit logs for anomalous identifier patterns—table or column names containing SQL keywords (UNION, INSERT, DROP, SELECT), semicolons, comment sequences (-- or /*), or encoded equivalents.

  5. Network segmentation: If immediate patching is not feasible, restrict n8n's outbound network access to only necessary database endpoints and implement WAF or database firewall rules targeting SQL injection patterns in query identifiers.

  6. Inventory: Identify all n8n instances in your environment, including those embedded in AI agent infrastructure or CI/CD pipelines, and prioritize those with database node workflows.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 9 - Risk management system
ISO 42001
8.4 - AI system operation
NIST AI RMF
MANAGE 2.2 - Mechanisms to maintain AI system integrity
OWASP LLM Top 10
LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-56351?

n8n before version 2.4.0 contains a SQL injection vulnerability in its MySQL, PostgreSQL, and Microsoft SQL database nodes, where authenticated users can inject arbitrary SQL by supplying crafted table or column names in workflow configurations. For organizations deploying n8n as an AI agent orchestration layer—a common pattern for connecting LLMs to production databases—this is a significant concern: any user with workflow creation permissions can execute unauthorized database commands, compromising data confidentiality and integrity across all connected backend systems. With a CVSS of 8.2 and a changed scope (S:C), successful exploitation cascades beyond n8n into the connected database infrastructure; while no public exploit exists and it is not in CISA KEV, the package carries 111 prior CVEs and an OpenSSF score of only 6.6/10, signaling persistent security debt in this codebase. Organizations should upgrade to n8n 2.4.0 immediately, audit workflow creation permissions, and review database audit logs for anomalous identifier patterns.

Is CVE-2026-56351 actively exploited?

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

How to fix CVE-2026-56351?

1. Patch: Upgrade n8n to version 2.4.0 or later immediately—this is the only complete fix. 2. Access control: Audit and restrict workflow creation permissions; treat workflow creation as equivalent to database write access and limit it to trusted personnel only. 3. Database hardening: Apply least-privilege to n8n database credentials; ensure service accounts cannot execute DDL or DML beyond what legitimate workflows require, and separate credentials per environment. 4. Detection: Review database audit logs for anomalous identifier patterns—table or column names containing SQL keywords (UNION, INSERT, DROP, SELECT), semicolons, comment sequences (-- or /*), or encoded equivalents. 5. Network segmentation: If immediate patching is not feasible, restrict n8n's outbound network access to only necessary database endpoints and implement WAF or database firewall rules targeting SQL injection patterns in query identifiers. 6. Inventory: Identify all n8n instances in your environment, including those embedded in AI agent infrastructure or CI/CD pipelines, and prioritize those with database node workflows.

What systems are affected by CVE-2026-56351?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI automation pipelines, database-connected AI agents, RAG pipelines, LLM-to-database integrations.

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

CVE-2026-56351 has a CVSS v3.1 base score of 8.2 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksAI automation pipelinesdatabase-connected AI agentsRAG pipelinesLLM-to-database integrations

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0049 Exploit Public-Facing Application
AML.T0053 AI Agent Tool Invocation
AML.T0081 Modify AI Agent Configuration
AML.T0086 Exfiltration via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 9
ISO 42001: 8.4
NIST AI RMF: MANAGE 2.2
OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

n8n before version 2.4.0 contains a sql injection vulnerability in MySQL, PostgreSQL, and Microsoft SQL nodes that allows authenticated users to inject arbitrary SQL through unescaped identifier values in node configuration parameters. Attackers with workflow creation permissions can supply specially crafted table or column names to execute unauthorized database commands and compromise data integrity.

Exploitation Scenario

A threat actor with a standard n8n user account—obtained via phishing, credential stuffing against an exposed n8n login, or an insider with workflow creation rights—navigates to the workflow builder. They create a new workflow containing a PostgreSQL node configured against a production database that feeds an AI data pipeline. Instead of a legitimate table name, they supply a crafted identifier such as `real_table UNION SELECT username, password_hash, NULL FROM admin_users--`, exploiting the absence of identifier escaping. When the workflow executes (either manually triggered or on schedule), the injected SQL runs against the connected database with n8n's service account privileges. In an AI context, this enables exfiltration of training datasets, poisoning of records feeding a RAG retrieval index, deletion of compliance audit trails, or insertion of rogue admin accounts—all wrapped inside an innocuous-looking automation workflow that blends with legitimate n8n activity.

Weaknesses (CWE)

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.

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N

Timeline

Published
June 24, 2026
Last Modified
June 24, 2026
First Seen
June 24, 2026

Related Vulnerabilities