CVE-2026-86996: n8n Agent tool bypasses

Q: Is CVE-2026-86996 actively exploited?

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

Q: How to fix CVE-2026-86996?

Upgrade to n8n 2.37.7 or 2.38.2 or later immediately — this is the only complete fix. Until patched: audit all workflows with "This workflow can be called by" restrictions and identify which return sensitive data; temporarily restrict who can create/edit Agent nodes to trusted users only; review existing Agent configurations for tool attachments referencing restricted workflows and remove any that shouldn't be reachable. Post-patch, verify via `packages/cli/src/modules/agents/tools/workflow-tool-factory.ts` behavior that SubworkflowPolicyChecker.checkForProject is enforced, and monitor n8n execution logs for Agent-invoked calls to workflows outside a user's expected project scope.

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

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation pipelines.

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

No CVSS score has been assigned yet.

CISO Take

n8n's "This workflow can be called by" permission is meant to restrict which callers can invoke a sensitive workflow, but versions prior to 2.37.7/2.38.2 only enforced that check in the Execute Workflow node — not when the same workflow was attached as a tool to an AI Agent. Any user able to build an Agent inside your n8n instance could attach a restricted workflow as a tool and read whatever data it returned, silently bypassing an access control that teams likely rely on to segment sensitive automations (credentials-handling workflows, HR/finance data pulls, etc.) from lower-trust users. There's no CVSS score, no KEV listing, and no public exploit or scanner template, and n8n carries a modest OpenSSF Scorecard (6.7/10) with 225 other CVEs in its history — this is a routine authorization gap, not an actively exploited zero-day, but it's trivial to exploit for anyone with workflow-editing rights once they know the trick. Patch to 2.37.7 or 2.38.2 immediately; until then, audit which workflows have restrictive caller settings and verify no low-privilege users have Agent-building permissions that could reach them, and review Agent tool configurations for any workflow attachments that shouldn't be there.

Sources: NVD GitHub Advisory

What is the risk?

Low-to-moderate severity: this is a logic/authorization gap (CWE-862 Missing Authorization) requiring an authenticated n8n user with permission to build or edit an Agent node — it is not remotely exploitable by an anonymous attacker. Exploitability is trivial once known (no special tooling, no adversarial ML expertise), but exposure is bounded by how broadly Agent-building rights are granted within an n8n instance. No CVSS, no KEV, no EPSS data, and no public PoC or Nuclei template exist, so this looks like a low-current-exploitation-likelihood issue that nonetheless has real internal blast radius in multi-tenant or multi-team n8n deployments where workflow-level access segmentation is relied upon.

How does the attack unfold?

Initial Access

Attacker holds a legitimate, low-privilege n8n account with permission to build AI Agent workflows.

AML.T0012

Tool Attachment

Attacker attaches a workflow marked with a caller restriction as a tool on a new Agent node.

AML.T0053

Authorization Bypass

Agent invokes the attached workflow via workflow-tool-factory.ts, which omits the SubworkflowPolicyChecker.checkForProject call that would normally block unauthorized callers.

AML.T0086

Impact

Restricted workflow executes and returns its data to the attacker through the Agent's response, disclosing information the attacker was not authorized to access.

Initial Access

Attacker holds a legitimate, low-privilege n8n account with permission to build AI Agent workflows.

AML.T0012

Tool Attachment

Attacker attaches a workflow marked with a caller restriction as a tool on a new Agent node.

AML.T0053

Authorization Bypass

Agent invokes the attached workflow via workflow-tool-factory.ts, which omits the SubworkflowPolicyChecker.checkForProject call that would normally block unauthorized callers.

AML.T0086

Impact

Restricted workflow executes and returns its data to the attacker through the Agent's response, disclosing information the attacker was not authorized to access.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.38.0, < 2.38.2	`2.38.2`
204.1K OpenSSF 6.6 16 dependents Pushed 7d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.2%

chance of exploitation in 30 days

Higher than 7% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade to n8n 2.37.7 or 2.38.2 or later immediately — this is the only complete fix. Until patched: audit all workflows with "This workflow can be called by" restrictions and identify which return sensitive data; temporarily restrict who can create/edit Agent nodes to trusted users only; review existing Agent configurations for tool attachments referencing restricted workflows and remove any that shouldn't be reachable. Post-patch, verify via packages/cli/src/modules/agents/tools/workflow-tool-factory.ts behavior that SubworkflowPolicyChecker.checkForProject is enforced, and monitor n8n execution logs for Agent-invoked calls to workflows outside a user's expected project scope.

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?

Auth Bypass Data Leakage Agent Plugin AML.T0012 - Valid Accounts AML.T0053 - AI Agent Tool Invocation AML.T0086 - Exfiltration via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.4 - AI system access control

NIST AI RMF

GOVERN 1.5 - Access and authorization policies

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-86996?

n8n's "This workflow can be called by" permission is meant to restrict which callers can invoke a sensitive workflow, but versions prior to 2.37.7/2.38.2 only enforced that check in the Execute Workflow node — not when the same workflow was attached as a tool to an AI Agent. Any user able to build an Agent inside your n8n instance could attach a restricted workflow as a tool and read whatever data it returned, silently bypassing an access control that teams likely rely on to segment sensitive automations (credentials-handling workflows, HR/finance data pulls, etc.) from lower-trust users. There's no CVSS score, no KEV listing, and no public exploit or scanner template, and n8n carries a modest OpenSSF Scorecard (6.7/10) with 225 other CVEs in its history — this is a routine authorization gap, not an actively exploited zero-day, but it's trivial to exploit for anyone with workflow-editing rights once they know the trick. Patch to 2.37.7 or 2.38.2 immediately; until then, audit which workflows have restrictive caller settings and verify no low-privilege users have Agent-building permissions that could reach them, and review Agent tool configurations for any workflow attachments that shouldn't be there.

Is CVE-2026-86996 actively exploited?

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

How to fix CVE-2026-86996?

Upgrade to n8n 2.37.7 or 2.38.2 or later immediately — this is the only complete fix. Until patched: audit all workflows with "This workflow can be called by" restrictions and identify which return sensitive data; temporarily restrict who can create/edit Agent nodes to trusted users only; review existing Agent configurations for tool attachments referencing restricted workflows and remove any that shouldn't be reachable. Post-patch, verify via `packages/cli/src/modules/agents/tools/workflow-tool-factory.ts` behavior that SubworkflowPolicyChecker.checkForProject is enforced, and monitor n8n execution logs for Agent-invoked calls to workflows outside a user's expected project scope.

What systems are affected by CVE-2026-86996?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation pipelines.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0053 AI Agent Tool Invocation

AML.T0086 Exfiltration via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.4

NIST AI RMF: GOVERN 1.5

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

n8n is an open source workflow automation platform. Prior to 2.37.7 and 2.38.2, the workflow setting named This workflow can be called by was enforced by the Execute Workflow node but not when a workflow was attached to an Agent as a tool. A user able to build an Agent could invoke a restricted workflow and read its returned data. The affected path is packages/cli/src/modules/agents/tools/workflow-tool-factory.ts, where executeWorkflow omitted SubworkflowPolicyChecker.checkForProject. This issue is fixed in versions 2.37.7 and 2.38.2.

Exploitation Scenario

An internal user with permission to build AI Agents in n8n (but not direct access to a restricted workflow that pulls sensitive HR or financial data) creates a new Agent and attaches the restricted workflow as one of its tools. Because the Agent-tool invocation path never calls SubworkflowPolicyChecker.checkForProject, the caller restriction is silently skipped. The user prompts the Agent to invoke that tool, and the Agent dutifully executes the restricted workflow and returns its output in the chat response — giving the attacker read access to data they were explicitly barred from accessing via the normal Execute Workflow node.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary CWE-862 Missing Authorization Primary CWE-862 Missing Authorization

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[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.