CVE-2026-44792: n8n SQL injection

Q: Is CVE-2026-44792 actively exploited?

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

Q: How to fix CVE-2026-44792?

1. Upgrade to n8n 1.123.43, 2.20.7, or 2.21.1 — the only complete remediation. 2. If upgrade is not immediately possible, disable the Source Control feature in n8n instance settings. 3. Audit and tighten git repository write permissions — restrict to the absolute minimum set of trusted principals. 4. Rotate all credentials stored in n8n's credential vault as a precautionary measure, prioritizing LLM API keys and OAuth tokens. 5. Enable PostgreSQL query logging and review recent logs for anomalous SQL patterns (unexpected DDL/DML, UNION-based queries, stacked statements). 6. Review Source Control Pull history for unexpected file imports or unusual column naming patterns in Data Table JSON files. 7. Treat any n8n-connected git repository as a security boundary requiring the same controls as application code.

Q: What systems are affected by CVE-2026-44792?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI orchestration pipelines, workflow automation, multi-service AI integrations.

Q: What is the CVSS score for CVE-2026-44792?

CVE-2026-44792 has a CVSS v3.1 base score of 9.0 (CRITICAL). The EPSS exploitation probability is 0.33%.

CISO Take

A SQL injection vulnerability in n8n's Source Control feature lets an attacker with write access to the connected git repository compromise the internal PostgreSQL database the moment an administrator performs a Source Control Pull — no additional interaction required beyond that single admin action. N8n is widely deployed as an AI agent orchestration hub connecting LLMs, enterprise APIs, and credential stores, making its database a high-value lateral-movement target: a successful injection exposes all stored API keys, workflow configurations, and automation secrets including credentials to downstream AI services. The package carries 80 prior CVEs and an OpenSSF Scorecard of only 6.1/10, signaling systemic security debt; in collaborative AI workflow teams where git repository write access is routinely shared, the attack prerequisites are easier to satisfy than they appear at first glance. Upgrade to n8n 1.123.43, 2.20.7, or 2.21.1 immediately; if upgrade is blocked, disable the Source Control feature entirely and audit repository write permissions.

Sources: GitHub Advisory NVD OpenSSF ATLAS

What is the risk?

Risk is HIGH in environments running n8n as an AI orchestration layer. The multi-condition exploit chain (PostgreSQL backend + Source Control enabled + attacker repo write access + admin Pull action) limits opportunistic exploitation but does not substantially reduce risk in real-world AI workflow teams where shared git repo access and routine admin Pulls are standard operating procedure. The package's history of 80 CVEs and OpenSSF score of 6.1/10 indicate a pattern of insufficient input validation. SQL injection against a workflow orchestrator's PostgreSQL backend is critical impact — full credential store exfiltration is achievable in a single exploitation cycle, with no public exploit or KEV listing currently moderating urgency.

How does the attack unfold?

Repository Write Access

Attacker obtains or already holds write access to the git repository connected to the target n8n instance's Source Control configuration.

AML.T0012

Payload Staging

Attacker commits a malicious Data Table JSON file containing a crafted column name embedding a SQL injection payload to the repository, disguised as a legitimate workflow data file.

AML.T0099

Trigger via Admin Action

Administrator performs a Source Control Pull — a routine sync operation — causing n8n to import the malicious file and pass the unsanitized column name to an internal PostgreSQL query.

AML.T0049

Database Compromise & Exfiltration

Injected SQL executes on the PostgreSQL backend, enabling full credential store exfiltration including LLM API keys and OAuth tokens, and potentially further lateral movement into connected AI services.

AML.T0025

Repository Write Access

Attacker obtains or already holds write access to the git repository connected to the target n8n instance's Source Control configuration.

AML.T0012

Payload Staging

Attacker commits a malicious Data Table JSON file containing a crafted column name embedding a SQL injection payload to the repository, disguised as a legitimate workflow data file.

AML.T0099

Trigger via Admin Action

Administrator performs a Source Control Pull — a routine sync operation — causing n8n to import the malicious file and pass the unsanitized column name to an internal PostgreSQL query.

AML.T0049

Database Compromise & Exfiltration

Injected SQL executes on the PostgreSQL backend, enabling full credential store exfiltration including LLM API keys and OAuth tokens, and potentially further lateral movement into connected AI services.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.43	`1.123.43`
194.3K OpenSSF 6.6 Pushed yesterday 54% patched ~7d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

9.0 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 25% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI Required

S Changed

C High

I High

A High

What should I do?

7 steps

Upgrade to n8n 1.123.43, 2.20.7, or 2.21.1 — the only complete remediation.
If upgrade is not immediately possible, disable the Source Control feature in n8n instance settings.
Audit and tighten git repository write permissions — restrict to the absolute minimum set of trusted principals.
Rotate all credentials stored in n8n's credential vault as a precautionary measure, prioritizing LLM API keys and OAuth tokens.
Enable PostgreSQL query logging and review recent logs for anomalous SQL patterns (unexpected DDL/DML, UNION-based queries, stacked statements).
Review Source Control Pull history for unexpected file imports or unusual column naming patterns in Data Table JSON files.
Treat any n8n-connected git repository as a security boundary requiring the same controls as application code.

How is it classified?

Supply Chain Code Execution Data Extraction Agent Framework AML.T0010.001 - AI Software AML.T0011.000 - Unsafe AI Artifacts AML.T0049 - Exploit Public-Facing Application AML.T0081 - Modify AI Agent Configuration AML.T0099 - AI Agent Tool Data Poisoning

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity Article 9 - Risk management system

ISO 42001

A.6.2.3 - Supply chain considerations for AI systems Clause 8.4 - AI system operation

NIST AI RMF

MANAGE 2.2 - Mechanisms to address identified AI risks

OWASP LLM Top 10

LLM03 - Supply Chain

Frequently Asked Questions

What is CVE-2026-44792?

A SQL injection vulnerability in n8n's Source Control feature lets an attacker with write access to the connected git repository compromise the internal PostgreSQL database the moment an administrator performs a Source Control Pull — no additional interaction required beyond that single admin action. N8n is widely deployed as an AI agent orchestration hub connecting LLMs, enterprise APIs, and credential stores, making its database a high-value lateral-movement target: a successful injection exposes all stored API keys, workflow configurations, and automation secrets including credentials to downstream AI services. The package carries 80 prior CVEs and an OpenSSF Scorecard of only 6.1/10, signaling systemic security debt; in collaborative AI workflow teams where git repository write access is routinely shared, the attack prerequisites are easier to satisfy than they appear at first glance. Upgrade to n8n 1.123.43, 2.20.7, or 2.21.1 immediately; if upgrade is blocked, disable the Source Control feature entirely and audit repository write permissions.

Is CVE-2026-44792 actively exploited?

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

How to fix CVE-2026-44792?

1. Upgrade to n8n 1.123.43, 2.20.7, or 2.21.1 — the only complete remediation. 2. If upgrade is not immediately possible, disable the Source Control feature in n8n instance settings. 3. Audit and tighten git repository write permissions — restrict to the absolute minimum set of trusted principals. 4. Rotate all credentials stored in n8n's credential vault as a precautionary measure, prioritizing LLM API keys and OAuth tokens. 5. Enable PostgreSQL query logging and review recent logs for anomalous SQL patterns (unexpected DDL/DML, UNION-based queries, stacked statements). 6. Review Source Control Pull history for unexpected file imports or unusual column naming patterns in Data Table JSON files. 7. Treat any n8n-connected git repository as a security boundary requiring the same controls as application code.

What systems are affected by CVE-2026-44792?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI orchestration pipelines, workflow automation, multi-service AI integrations.

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

CVE-2026-44792 has a CVSS v3.1 base score of 9.0 (CRITICAL). The EPSS exploitation probability is 0.33%.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI orchestration pipelinesworkflow automationmulti-service AI integrations

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0011.000 Unsafe AI Artifacts

AML.T0049 Exploit Public-Facing Application

AML.T0081 Modify AI Agent Configuration

AML.T0099 AI Agent Tool Data Poisoning

Compliance Controls Affected

EU AI Act: Article 15, Article 9

ISO 42001: A.6.2.3, Clause 8.4

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

n8n is an open source workflow automation platform. Prior to 1.123.43, 2.22.1, and 2.20.7, an attacker with write access to the git repository connected to an n8n Source Control configuration could commit a malicious Data Table JSON file containing a crafted column name. When an administrator performed a Source Control Pull, n8n imported the file and could lead to SQL injection on the internal PostgreSQL instance. Exploitation requires the n8n instance uses PostgreSQL as its database backend, the Source Control feature is enabled and connected to a repository the attacker can write to, and an administrator triggers a Source Control Pull. This vulnerability is fixed in 1.123.43, 2.22.1, and 2.20.7.

Exploitation Scenario

A threat actor — insider, compromised developer account, or external attacker who has gained repository contributor access — crafts a Data Table JSON file containing a column name embedding a SQL injection payload (e.g., `legit_column'; INSERT INTO credentials (key,value) SELECT 'exfil_key', encode(data,'base64') FROM n8n_credential WHERE type='openAiApi'; --`). The file is committed to the n8n-connected Source Control repository under a plausible filename. When an administrator performs a routine Source Control Pull — a standard operation for syncing workflow definitions across environments — n8n ingests the malicious file and passes the unsanitized column name directly to a PostgreSQL query. The attacker achieves arbitrary SQL execution, exfiltrates the full credential store including LLM API keys, and establishes a foothold for lateral movement into every AI service and enterprise system n8n was authorized to access.

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')

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.