AI Threat AlertCVE-2026-85166: n8n: credential theft via unvalidated workflow node
HIGHA flaw in n8n's Workflow Tool node lets any user who can edit a shared workflow — including through the REST API, Public API, or MCP — reference a credential they don't own inside an inline sub-workflow, and when a more privileged user later runs that workflow the secret resolves and can be shipped straight to an attacker-controlled endpoint. This matters most for organizations running n8n as an AI agent orchestration layer, where workflows commonly hold API keys for LLM providers, cloud services, or internal systems shared across teams; the n8n package already carries 211 other logged CVEs and an OpenSSF Scorecard of just 6.7/10, with 16 downstream dependents that could inherit exposure. There's no public exploit or Nuclei template yet and EPSS sits at just 0.00215, and it isn't in CISA KEV, so this is not an emergency — but it's a low-effort insider or lateral-movement play that any workflow editor can attempt without ever touching the credential store directly. Patch to n8n 2.35.4 (or 2.36.2 on the 2.36.x branch) as soon as possible; in the interim, audit who holds workflow-edit rights across the UI, REST API, Public API, and MCP versus who owns sensitive credentials, and review recent Workflow Tool / sub-workflow executions for credential references outside the editor's ownership. Treat any workflow edit that introduces a credential ID not owned by the editor as a detection signal worth alerting on.
What is the risk?
Low-to-moderate exploitation likelihood (EPSS 0.00215, top 88% percentile is still a low absolute score; no public exploit, no Nuclei template, not in CISA KEV) but meaningful impact given the vulnerability is a broken authorization control (CWE-863) on credential access rather than a logic bug. The realistic threat actor is an insider, a compromised low-privileged account, or a malicious/negligent workflow contributor with editor access via UI, REST API, Public API, or MCP — not an anonymous internet attacker, since exploitation requires the ability to create or update a workflow. In AI-agent-heavy n8n deployments where workflows are shared across teams and hold high-value credentials (LLM provider keys, cloud IAM tokens, SaaS API keys), a successful exploit converts a workflow-edit permission into full credential theft, which can cascade into further compromise of any system that credential unlocks.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | — | No patch |
Do you use n8n? You're affected.
How severe is it?
What should I do?
1 stepPatch immediately: upgrade to n8n 2.35.4 or later, or 2.36.2 or later on the 2.36.x branch. Until patched, restrict who can create/update workflows via the editor UI, REST API, Public API, and MCP, and treat 'shared workflow editor' as equivalent to 'can access any credential referenced by any workflow you can run.' Audit existing workflows for Workflow Tool / inline sub-workflow nodes that reference credentials not owned by the workflow's primary owner or last editor. Add detection for outbound HTTP requests from workflow executions targeting unexpected/external endpoints immediately after credential-resolving nodes execute. Review credential-sharing scopes and consider tightening credential ownership so fewer identities can trigger high-privilege sub-workflow executions.
What does CISA's SSVC say?
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:
Frequently Asked Questions
What is CVE-2026-85166?
A flaw in n8n's Workflow Tool node lets any user who can edit a shared workflow — including through the REST API, Public API, or MCP — reference a credential they don't own inside an inline sub-workflow, and when a more privileged user later runs that workflow the secret resolves and can be shipped straight to an attacker-controlled endpoint. This matters most for organizations running n8n as an AI agent orchestration layer, where workflows commonly hold API keys for LLM providers, cloud services, or internal systems shared across teams; the n8n package already carries 211 other logged CVEs and an OpenSSF Scorecard of just 6.7/10, with 16 downstream dependents that could inherit exposure. There's no public exploit or Nuclei template yet and EPSS sits at just 0.00215, and it isn't in CISA KEV, so this is not an emergency — but it's a low-effort insider or lateral-movement play that any workflow editor can attempt without ever touching the credential store directly. Patch to n8n 2.35.4 (or 2.36.2 on the 2.36.x branch) as soon as possible; in the interim, audit who holds workflow-edit rights across the UI, REST API, Public API, and MCP versus who owns sensitive credentials, and review recent Workflow Tool / sub-workflow executions for credential references outside the editor's ownership. Treat any workflow edit that introduces a credential ID not owned by the editor as a detection signal worth alerting on.
Is CVE-2026-85166 actively exploited?
No confirmed active exploitation of CVE-2026-85166 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-85166?
Patch immediately: upgrade to n8n 2.35.4 or later, or 2.36.2 or later on the 2.36.x branch. Until patched, restrict who can create/update workflows via the editor UI, REST API, Public API, and MCP, and treat 'shared workflow editor' as equivalent to 'can access any credential referenced by any workflow you can run.' Audit existing workflows for Workflow Tool / inline sub-workflow nodes that reference credentials not owned by the workflow's primary owner or last editor. Add detection for outbound HTTP requests from workflow executions targeting unexpected/external endpoints immediately after credential-resolving nodes execute. Review credential-sharing scopes and consider tightening credential ownership so fewer identities can trigger high-privilege sub-workflow executions.
What systems are affected by CVE-2026-85166?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation pipelines.
What is the CVSS score for CVE-2026-85166?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0083Credentials from AI Agent ConfigurationAML.T0086Exfiltration via AI Agent Tool InvocationAML.T0098AI Agent Tool Credential HarvestingCompliance Controls Affected
What are the technical details?
Original Advisory
n8n before 2.35.4 and 2.36.x before 2.36.2 does not validate credential references in the inline workflow JSON of nodes that execute an inline sub-workflow (e.g., the Workflow Tool node). A shared-workflow editor, or any user creating/updating a workflow via the REST API, Public API, or MCP, can persist a node referencing a credential they do not own. When the workflow is later executed under an identity that holds the credential, the inline sub-workflow resolves the secret and can send it to an attacker-controlled endpoint, resulting in credential exfiltration.
Exploitation Scenario
A contractor or low-privileged employee with edit access to a shared n8n workflow (granted via the UI, or via REST/Public API/MCP automation) adds or modifies a Workflow Tool node whose inline sub-workflow JSON references a credential ID belonging to an admin or a service account they don't have direct access to — for example, an LLM provider API key or a cloud storage credential. The change persists without any ownership check. Later, an administrator, a scheduled trigger, or another privileged user executes the parent workflow as part of normal operations; the sub-workflow resolves the referenced credential in that execution context and passes it to an HTTP Request node pointed at a webhook the attacker controls (e.g., a serverless endpoint), completing silent credential exfiltration with no interactive access to the credential store required.
Weaknesses (CWE)
CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2026-3366310.0n8n: member role steals plaintext HTTP credentials
Same package: n8nCVE-2026-3366010.0TensorFlow: type confusion NPD in tensor conversion
Same package: n8nCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same package: n8nCVE-2025-686689.9n8n: Protection Bypass circumvents security controls
Same package: n8nCVE-2026-274959.9n8n: Code Injection enables RCE
Same package: n8n