CVE-2026-86085

What it actually does

Missing authorization on n8n REST role-assignment APIs allows an authenticated caller who holds role:manageProject to query /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members for a project they cannot list. The role.controller.ts handlers verified only role-type management, omitting the project:list scope check, so the response can disclose project member display names and email addresses. Integrity and availability are unaffected; impact is limited confidentiality of identity data.

Why it matters to the business

Self-hosted n8n instances used for workflow automation can leak internal user names and email addresses across project boundaries, creating a privacy and directory-harvesting risk for organizations that treat n8n as an identity-adjacent collaboration surface. The issue requires an already-privileged project manager, is not listed in CISA KEV, has no known in-the-wild or ransomware use, and has modest severity, but unpatched instances still expose PII that can feed phishing or internal reconnaissance. Upgrade urgency is moderate: the flaw has been public for several weeks and patched releases exist.

How an attack unfolds

An attacker first obtains a valid n8n session with the manage-project role (stolen credentials, over-privileged account, or insider). They then call the role-assignment REST endpoints, supplying a role slug and a project identifier they are not authorized to list. Because the controller does not enforce project:list, the server returns assignment and membership payloads containing names and emails. The attacker repeats the request across guessed or enumerated project IDs to build a cross-project contact list. No unauthenticated access, code execution, or workflow tampering is required.

How to fix it

Upgrade n8n to 2.37.7 or 2.38.2 (or a later maintained release that includes the role-controller authorization fix). If immediate upgrade is not possible, restrict who holds role:manageProject, limit network access to the n8n UI and /rest API to trusted administrators, and disable or firewall the role-assignment endpoints until patched. After upgrade, review project membership and rotate credentials for any accounts whose emails may have been exposed.

How to confirm the fix worked

Confirm the running n8n version is 2.37.7, 2.38.2, or newer. With a test account that has role:manageProject but not project:list on a second project, call the role-assignment and project-member endpoints for that project and verify the API now denies the request (authorization error, not member data). Review access-control tests covering packages/cli/src/controllers/role.controller.ts to ensure project:list is enforced. Inventory remaining instances still below the fixed versions.

Typical attack path

1. Obtain an authenticated n8n session with role:manageProject (or equivalent project-management privilege).
2. Identify or guess target role slugs and project IDs the account is not allowed to list.
3. Send GET (or equivalent) requests to /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members.
4. Parse returned assignment and member objects for names and email addresses.
5. Iterate additional project IDs to expand the harvested user directory for follow-on social engineering or account targeting.

How to detect it

There is no public exploit tooling and no named threat-actor activity for this issue; detection is therefore log-based rather than signature-based. Review n8n and reverse-proxy access logs for authenticated requests to /rest/roles/*/assignments and /rest/roles/*/assignments/*/members, especially where the caller’s user id is not a member of the requested projectId. Correlate those requests with successful 200 responses returning member or email fields. Look for sequential projectId enumeration (many distinct project identifiers from one session) and for access from accounts that hold project-management roles but should not see the target project. Application logs from the role controller, session/audit logs, and WAF/API gateway logs are the primary sources; endpoint hosts will not typically drop unique files or registry artifacts.

• /rest/roles/
• /assignments/
• /assignments/
• /members
• packages/cli/src/controllers/role.controller.ts
• role:manageProject

What your security team should do

• Patch all n8n instances to 2.37.7 or 2.38.2 as a planned but prompt maintenance action.
• Inventory self-hosted n8n deployments and internet-exposed /rest APIs; remove public access where not required.
• Reduce standing role:manageProject grants to the minimum set of operators.
• Hunt historical API logs for role-assignment member queries against projects the caller should not list.
• Notify privacy/legal if member emails may have been disclosed, and treat harvested addresses as phishing-risk data.