CVE-2026-77070: n8n: NoSQL injection in MongoDB node wipes/exfils data

HIGH
Published August 20, 2026
CISO Take

n8n's MongoDB node builds its Find, Delete, and Aggregate queries by parsing the resolved Query parameter as raw JSON without stripping MongoDB operators, so any externally-controlled value that flows into that parameter can smuggle in operators like $ne or $where and turn a scoped single-document lookup into an operation against the entire collection. This matters because n8n is widely used to orchestrate AI agent workflows, where webhook payloads, form submissions, or LLM tool outputs are routinely piped into database nodes as "just data" — exactly the trust boundary this bug breaks. There is no CISA KEV listing, no public exploit or Nuclei template, and no published CVSS/EPSS score, but the vulnerability class (CWE-943) is trivial to weaponize once an attacker identifies which workflow input reaches the Mongo node, and n8n's track record (201 other CVEs, 6.6/10 OpenSSF Scorecard) suggests this class of issue isn't systematically hardened against. Patch to n8n 1.123.69, 2.33.4, or 2.34.1 immediately; until then, audit every workflow's MongoDB Find/Delete/Aggregate nodes for Query parameters sourced from webhooks, form triggers, or agent-generated tool calls, and enforce a fixed query template or explicit operator allowlist rather than passing resolved JSON straight through to MongoDB.

Sources:NVDGitHub AdvisoryATLASOpenSSF

What is the risk?

High severity as labeled, driven by impact rather than confirmed exploitation: no KEV listing, no public PoC/exploit, and no CVSS/EPSS data available to quantify likelihood. Exploitability hinges entirely on workflow design — it requires a workflow where externally-influenced data (webhook body, form field, upstream node output, or an AI agent's tool output) is passed unmodified into a MongoDB node's Query parameter. That is a common but not universal pattern in n8n deployments, so real-world exposure varies by tenant. Where it exists, impact is severe: unauthenticated-relative full-collection read (data exfiltration) or full-collection delete (irrecoverable data loss) against whatever MongoDB database the n8n instance is credentialed to reach, which in AI-agent contexts can include vector store metadata, conversation logs, or business records the agent was scoped to touch.

How does the attack unfold?

Entry point
Attacker submits externally-controlled input (webhook payload, form field, or agent tool argument) that an n8n workflow resolves into a MongoDB node's Query parameter.
AML.T0049
Injection
The resolved expression is parsed as raw JSON without stripping MongoDB operators, letting the attacker embed operators such as $ne or $where instead of a plain value.
Exploitation
The injected operator causes the Find, Delete, or Aggregate operation to match every document in the collection instead of the intended single record.
AML.T0086
Impact
The attacker achieves full-collection data disclosure or full-collection deletion on the MongoDB database the n8n instance is credentialed to access.
AML.T0101

What systems are affected?

PackageEcosystemVulnerable RangePatched
n8nnpm—No patch
209.2KOpenSSF 7.116 dependentsPushed yesterday44% patched~19d to patchFull package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.5%
chance of exploitation in 30 days
Higher than 44% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

1 step
  1. Upgrade to n8n 1.123.69, 2.33.4, or 2.34.1 or later, where the MongoDB node sanitizes or rejects MongoDB operators in the parsed Query parameter. If immediate patching isn't possible: audit all workflows for MongoDB Find/Delete/Aggregate nodes and identify which ones build the Query parameter from expression-resolved external input (webhook data, form data, HTTP Request node output, or AI agent tool arguments); replace freeform query expressions with fixed/templated queries or add explicit validation that rejects keys starting with '$'; apply least-privilege MongoDB credentials scoped per-workflow rather than a shared admin-level connection; and enable MongoDB audit logging to detect anomalous full-collection reads or deletes correlated with n8n's service account. Detection: alert on MongoDB query patterns from the n8n connection that touch a disproportionate document count relative to the workflow's expected single-document lookups, and review CVE.org/GHSA-953p-jm2c-8h5j for any updated exploitation indicators.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impactpartial

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

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.3-AI system data security
NIST AI RMF
MANAGE-4.1-Risks from third-party AI components
OWASP LLM Top 10
LLM02-Sensitive Information DisclosureLLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-77070?

n8n's MongoDB node builds its Find, Delete, and Aggregate queries by parsing the resolved Query parameter as raw JSON without stripping MongoDB operators, so any externally-controlled value that flows into that parameter can smuggle in operators like $ne or $where and turn a scoped single-document lookup into an operation against the entire collection. This matters because n8n is widely used to orchestrate AI agent workflows, where webhook payloads, form submissions, or LLM tool outputs are routinely piped into database nodes as "just data" — exactly the trust boundary this bug breaks. There is no CISA KEV listing, no public exploit or Nuclei template, and no published CVSS/EPSS score, but the vulnerability class (CWE-943) is trivial to weaponize once an attacker identifies which workflow input reaches the Mongo node, and n8n's track record (201 other CVEs, 6.6/10 OpenSSF Scorecard) suggests this class of issue isn't systematically hardened against. Patch to n8n 1.123.69, 2.33.4, or 2.34.1 immediately; until then, audit every workflow's MongoDB Find/Delete/Aggregate nodes for Query parameters sourced from webhooks, form triggers, or agent-generated tool calls, and enforce a fixed query template or explicit operator allowlist rather than passing resolved JSON straight through to MongoDB.

Is CVE-2026-77070 actively exploited?

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

How to fix CVE-2026-77070?

Upgrade to n8n 1.123.69, 2.33.4, or 2.34.1 or later, where the MongoDB node sanitizes or rejects MongoDB operators in the parsed Query parameter. If immediate patching isn't possible: audit all workflows for MongoDB Find/Delete/Aggregate nodes and identify which ones build the Query parameter from expression-resolved external input (webhook data, form data, HTTP Request node output, or AI agent tool arguments); replace freeform query expressions with fixed/templated queries or add explicit validation that rejects keys starting with '$'; apply least-privilege MongoDB credentials scoped per-workflow rather than a shared admin-level connection; and enable MongoDB audit logging to detect anomalous full-collection reads or deletes correlated with n8n's service account. Detection: alert on MongoDB query patterns from the n8n connection that touch a disproportionate document count relative to the workflow's expected single-document lookups, and review CVE.org/GHSA-953p-jm2c-8h5j for any updated exploitation indicators.

What systems are affected by CVE-2026-77070?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, vector databases, plugin/tool integrations.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesvector databasesplugin/tool integrations

MITRE ATLAS Techniques

AML.T0053AI Agent Tool Invocation
AML.T0086Exfiltration via AI Agent Tool Invocation
AML.T0101Data Destruction via AI Agent Tool Invocation

Compliance Controls Affected

ISO 42001: A.6.2.3
NIST AI RMF: MANAGE-4.1
OWASP LLM Top 10: LLM02, LLM06

What are the technical details?

Original Advisory

n8n before 1.123.69, 2.33.4, and 2.34.1 contains a NoSQL injection vulnerability in the MongoDB node's Find, Delete, and Aggregate operations, which parse the Query parameter as JSON after expression resolution without sanitizing MongoDB operators. An attacker who can influence the resolved query (e.g., via externally-controlled data) can inject operators such as $ne or $where, turning an intended single-document lookup into full-collection disclosure, full-collection deletion, or other operations on the database server.

Exploitation Scenario

An organization runs an n8n workflow that acts as an AI agent's order-lookup tool: a webhook receives a customer-supplied order ID, resolves it into a MongoDB node's Query parameter (e.g., {"orderId": "{{ $json.orderId }}"}), and returns the matching document to the agent for a support response. An attacker submits a crafted payload instead of a plain order ID — for example {"$ne": null} — which n8n resolves and parses as JSON without stripping the operator, so the query becomes a match against every document in the collection instead of one. The Find operation now returns the entire orders collection to the agent (and potentially back to the attacker via the chat response), or if the same pattern reaches a Delete node, the attacker wipes the entire collection in one request. Because the flaw lives in query construction rather than authentication, no credentials beyond the ability to trigger the workflow (e.g., a public webhook or an agent-exposed tool) are required.

Weaknesses (CWE)

CWE-943 — Improper Neutralization of Special Elements in Data Query Logic: The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query.

Source: MITRE CWE corpus.

Timeline

Published
August 20, 2026
Last Modified
August 21, 2026
First Seen
August 20, 2026

Related Vulnerabilities