CVE-2026-86085 in n8n
Summary
by MITRE • 09/09/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in n8n prior to versions 2.37.7 and 2.38.2 represents a critical authorization flaw within the platform's role management subsystem, specifically affecting endpoints responsible for assigning members to roles within projects. The affected code resides in packages/cli/src/controllers/role.controller.ts, which handles requests directed at /rest/roles/:slug/assignments and /rest/roles/:slug/assignments/:projectId/members. These endpoints are designed to manage the assignment of users to specific role types associated with particular projects or organizational contexts. Under normal operational parameters, access control mechanisms should verify that a user possesses not only the permission to manage the role type but also sufficient privileges over the target project itself. However, in these vulnerable versions, the implementation failed to enforce this granular check, creating a significant gap in security logic.
The core technical flaw lies in the omission of a scope verification for the project:list capability during the assignment process. When an authenticated user with the role:manageProject permission attempted to assign members to a specific project's role, the system only validated whether the caller had authority over the general role type definition. It did not verify whether the caller was authorized to view or interact with the target project itself. This oversight allowed an attacker possessing the manageProject privilege on one resource to arbitrarily select any other project identifier in their request payload, regardless of whether they had visibility into that second project. By exploiting this logic error, a malicious actor could successfully assign themselves or others as members to projects they were not supposed to access, thereby bypassing standard isolation boundaries between different organizational units or client environments within the n8n instance.
The operational impact of this vulnerability is primarily centered on unauthorized information disclosure and potential privilege escalation through lateral movement. By assigning themselves to a project they could not list, attackers gained indirect access to sensitive data associated with that project's members. Specifically, the assignment operation exposed member names and email addresses for projects outside the attacker's authorized scope. This constitutes an Insecure Direct Object Reference (IDOR) scenario where the application fails to properly validate object ownership before performing actions on it. The exposure of personally identifiable information such as email addresses violates data privacy principles and can facilitate further social engineering attacks or targeted phishing campaigns against employees within those unauthorized projects. Furthermore, gaining membership in a restricted project may provide additional context for subsequent exploitation attempts if other vulnerabilities exist within the application logic related to workflow execution or credential storage associated with that project.
From an industry standard perspective, this vulnerability aligns closely with CWE-284, which describes Improper Access Control where insufficient access restrictions are applied during authorization checks. It also maps to MITRE ATT&CK technique T1078, specifically the Valid Accounts subcategory, as it allows a user to leverage existing credentials and permissions to gain unauthorized access to resources they should not be able to see or interact with. The failure to check for project:list scope is a classic example of missing function-level access control, where the application assumes that managing a role type implies broader administrative rights over all associated entities without explicit verification. This lack of defense-in-depth at the API level underscores the importance of implementing strict object-level authorization checks before processing any state-changing requests involving external identifiers.
To mitigate this vulnerability and prevent similar issues in future development cycles, it is imperative to enforce comprehensive access control policies that validate both role-based permissions and resource-specific scopes for every endpoint operation. Developers must ensure that whenever a request involves a specific project identifier, the system explicitly checks if the authenticated user has the necessary list or view privileges for that particular project before allowing any assignments or modifications. This can be achieved by integrating middleware or service-layer logic that queries the authorization database to confirm scope membership prior to executing business logic. Additionally, implementing automated security testing tools focused on identifying IDOR vulnerabilities and conducting regular penetration tests against role management endpoints will help detect such gaps early in the software development lifecycle. Organizations running affected versions of n8n should immediately upgrade to version 2.37.7 or 2.38.2 where this logic has been corrected, ensuring that all assignment operations are properly gated by both role and project visibility permissions.