CVE-2026-86085: n8n missing scope check leaks

Q: Is CVE-2026-86085 actively exploited?

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

Q: How to fix CVE-2026-86085?

Upgrade to n8n 2.37.7 (2.37.x line) or 2.38.2 (2.38.x line) or later, which add the missing project:list scope check in role.controller.ts. If immediate upgrade isn't possible, restrict who is granted role:manageProject to trusted admins only, since it's the sole precondition for exploitation. Detect abuse by auditing /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members access logs for requests targeting project slugs outside a user's assigned projects. After patching, review historical API logs for anomalous cross-project role-assignment calls that may indicate prior enumeration.

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

This vulnerability affects the following AI/ML architecture patterns: agent frameworks.

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

No CVSS score has been assigned yet.

CISO Take

A missing authorization check in n8n's role-assignment API lets any user who can manage project roles enumerate member names and email addresses for projects they aren't otherwise permitted to view, because the /rest/roles/:slug/assignments endpoints validate role-type permissions but never confirm the caller holds project:list scope. For organizations running n8n as the orchestration layer behind AI agent workflows, this is a low-complexity authenticated-user information disclosure — no CVSS score or EPSS data has been published yet and it isn't in CISA's KEV catalog, but the bar to exploit is trivial for anyone who already holds a manageProject-capable account, and no public PoC or Nuclei template is currently available. The real risk is reconnaissance value: harvested names and emails of workflow owners and project members can seed targeted phishing against people who control automation credentials and API keys embedded in n8n workflows. Patch to n8n 2.37.7 or 2.38.2 immediately, and until then treat the role:manageProject permission as sensitive since it now doubles as a project-membership enumeration primitive. Review role-assignment API access logs for calls against project slugs outside a user's normal scope as a detection signal.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Low-to-medium severity broken access control (CWE-862) with no published CVSS/EPSS score, not in CISA KEV, and no known public exploit or scanner coverage. Exploitability is trivial for any authenticated account holding role:manageProject — no additional skill or tooling needed beyond crafting a REST call with a target project slug. Impact is bounded to disclosure of project member names/emails (not workflow data, credentials, or execution), but in AI-agent orchestration contexts this PII can bootstrap social-engineering attacks against the humans who control automation credentials, connections, and API keys inside n8n.

How does the attack unfold?

Precondition access

Attacker holds a low-privilege authenticated n8n account with the role:manageProject permission.

AML.T0012

Authorization bypass

Attacker calls the /rest/roles/:slug/assignments or members sub-endpoint naming a project slug they cannot list, exploiting the missing project:list scope check in role.controller.ts.

AML.T0049

PII collection

The endpoint returns member names and email addresses for the targeted project despite the caller lacking list access.

AML.T0087

Downstream abuse

Attacker leverages the harvested identities for targeted phishing or social engineering against workflow owners who control broader automation credentials.

AML.T0052

Precondition access

Attacker holds a low-privilege authenticated n8n account with the role:manageProject permission.

AML.T0012

Authorization bypass

Attacker calls the /rest/roles/:slug/assignments or members sub-endpoint naming a project slug they cannot list, exploiting the missing project:list scope check in role.controller.ts.

AML.T0049

PII collection

The endpoint returns member names and email addresses for the targeted project despite the caller lacking list access.

AML.T0087

Downstream abuse

Attacker leverages the harvested identities for targeted phishing or social engineering against workflow owners who control broader automation credentials.

AML.T0052

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.3%

chance of exploitation in 30 days

Higher than 17% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

Upgrade to n8n 2.37.7 (2.37.x line) or 2.38.2 (2.38.x line) or later, which add the missing project:list scope check in role.controller.ts. If immediate upgrade isn't possible, restrict who is granted role:manageProject to trusted admins only, since it's the sole precondition for exploitation. Detect abuse by auditing /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members access logs for requests targeting project slugs outside a user's assigned projects. After patching, review historical API logs for anomalous cross-project role-assignment calls that may indicate prior enumeration.

How is it classified?

Auth Bypass Privacy Violation Agent AML.T0049 - Exploit Public-Facing Application AML.T0087 - Gather Victim Identity Information

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - Information security for AI system components

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-86085?

A missing authorization check in n8n's role-assignment API lets any user who can manage project roles enumerate member names and email addresses for projects they aren't otherwise permitted to view, because the /rest/roles/:slug/assignments endpoints validate role-type permissions but never confirm the caller holds project:list scope. For organizations running n8n as the orchestration layer behind AI agent workflows, this is a low-complexity authenticated-user information disclosure — no CVSS score or EPSS data has been published yet and it isn't in CISA's KEV catalog, but the bar to exploit is trivial for anyone who already holds a manageProject-capable account, and no public PoC or Nuclei template is currently available. The real risk is reconnaissance value: harvested names and emails of workflow owners and project members can seed targeted phishing against people who control automation credentials and API keys embedded in n8n workflows. Patch to n8n 2.37.7 or 2.38.2 immediately, and until then treat the role:manageProject permission as sensitive since it now doubles as a project-membership enumeration primitive. Review role-assignment API access logs for calls against project slugs outside a user's normal scope as a detection signal.

Is CVE-2026-86085 actively exploited?

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

How to fix CVE-2026-86085?

Upgrade to n8n 2.37.7 (2.37.x line) or 2.38.2 (2.38.x line) or later, which add the missing project:list scope check in role.controller.ts. If immediate upgrade isn't possible, restrict who is granted role:manageProject to trusted admins only, since it's the sole precondition for exploitation. Detect abuse by auditing /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members access logs for requests targeting project slugs outside a user's assigned projects. After patching, review historical API logs for anomalous cross-project role-assignment calls that may indicate prior enumeration.

What systems are affected by CVE-2026-86085?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworks

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0087 Gather Victim Identity Information

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM02:2025

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 /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members endpoints checked only whether the caller could manage the role type. A caller with role:manageProject could name a project the caller could not list and obtain member names and email addresses. The affected controller is packages/cli/src/controllers/role.controller.ts, which omitted the project:list scope check. This issue is fixed in versions 2.37.7 and 2.38.2.

Exploitation Scenario

A contractor or lower-trust employee is granted role:manageProject in one n8n project so they can manage sub-roles for their own team's automation workflows. Instead of staying in scope, they call GET /rest/roles/:slug/assignments/:projectId/members, substituting the projectId of a different, sensitive project — e.g., one running production AI-agent workflows integrated with customer data — that they have no listing permission for. Because the controller only checks role-management permission and never verifies project:list scope, the API returns the full member list with names and emails. The attacker now has a verified roster of who has access to that high-value automation project, which they use to craft convincing spear-phishing emails targeting those individuals to obtain their n8n credentials or embedded API keys.

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.