CVE-2026-77079 in n8n
Summary
by MITRE • 08/20/2026
n8n before 2.34.1 and 2.33.4 contains an authorization bypass in the custom project role deletion (reassignment) path. When deleting a custom project role with a reassignment target, the code validated only that the target role existed and was project-scoped, performing no project-level authorization check. A user holding only the narrow role:manageProject global scope could delete any custom project role in use on the instance and reassign its holders (including themselves) to the built-in project:admin role, gaining full administrative control of projects they had no legitimate access to.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in n8n versions prior to 2.34.1 and 2.33.4 represents a critical authorization bypass within the application's custom project role management subsystem. This flaw specifically affects the workflow for deleting or reassigning custom project roles, which are user-defined permission sets designed to provide granular access control beyond the default built-in roles. The core technical deficiency lies in the server-side validation logic executed during the deletion process when a target role is specified for reassignment of existing users. Instead of verifying that the initiating requestor possesses sufficient privileges within the specific project context where the custom role resides, the code performs only a superficial check to ensure the target replacement role exists and is scoped correctly at the project level. This omission allows an attacker with significantly lower global permissions to escalate their access by manipulating this endpoint.
From a technical perspective, the vulnerability stems from a failure in implementing proper object-level authorization checks. When a user initiates the deletion of a custom project role and specifies that its members should be reassigned to another role, such as the built-in project:admin role, the application validates the existence and scope of the target role but completely neglects to validate whether the requester has permission to modify roles within the source project. This logic gap means that any authenticated user with the narrow global scope role:manageProject can execute this operation on any custom project role across all projects in the instance, regardless of their actual membership or permissions within those specific projects. The lack of a check against the project ID associated with the target custom role is the primary enabler of this privilege escalation path.
The operational impact of this vulnerability is severe, as it effectively allows an attacker to gain full administrative control over any project in the n8n instance without prior authorization. By deleting their own restrictive or non-existent roles and reassigning themselves to the built-in project:admin role, attackers can bypass all intended access controls. This grants them unrestricted ability to view workflows, execute nodes with elevated privileges, manage credentials, and modify settings within projects they were never meant to access. In environments where n8n is used for sensitive automation tasks involving proprietary data or critical infrastructure, this could lead to significant data breaches, unauthorized system modifications, or complete compromise of the workflow orchestration platform.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically highlighting a failure in enforcing role-based access control policies at the object level. Furthermore, it maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as an attacker leverages legitimate but insufficient credentials to escalate privileges and gain unauthorized administrative access. The attack vector is typically remote if n8n is exposed to untrusted networks, making prompt remediation essential for public-facing deployments or those accessible via VPNs with broad user bases.
Mitigation strategies must prioritize immediate upgrading of the n8n instance to version 2.34.1 or later, where this authorization check has been corrected to verify project-level permissions before allowing role deletion and reassignment operations. For organizations unable to upgrade immediately due to operational constraints, implementing a Web Application Firewall rule that restricts access to the specific API endpoints involved in custom project role management can provide temporary protection. Additionally, auditing user roles globally is recommended; administrators should ensure that no users are assigned the global role:manageProject scope unless absolutely necessary for their job functions, thereby reducing the attack surface available to potential adversaries seeking to exploit this logic flaw.