CVE-2026-77079: n8n authz bypass — HIGH

CISO Take

n8n's custom project role deletion flow validated only that a reassignment target role existed and was project-scoped, without checking whether the requesting user actually had authority over that project. Any user holding just the narrow role:manageProject global scope could delete a custom project role in use elsewhere on the instance and reassign its holders, including themselves, to the built-in project:admin role. That turns a low-privilege account into full administrative control over projects the attacker was never granted access to, with no exploit code, KEV listing, or EPSS data yet in circulation to suggest active exploitation. Given n8n's role as an AI agent orchestration platform with 16 downstream dependents and 201 other CVEs on record for the package, and a mediocre OpenSSF Scorecard of 6.6/10, this is the kind of logic flaw that's easy to miss in a security review but trivial to abuse once a low-privileged insider or compromised low-priv credential exists. Upgrade to n8n 2.34.1 or 2.33.4 immediately, and audit which accounts currently hold role:manageProject and which projects/agents they gained access to before the patch.

Sources:NVDGitHub AdvisoryVulnCheckOpenSSFATLAS

What is the risk?

This is a logic-level authorization bypass (CWE-639, insecure direct object reference on a role ID) rather than a memory-safety or injection bug, so exploitability is high for anyone already holding the role:manageProject scope — no special tooling, no AI/ML expertise, and no network-level access beyond an authenticated session are required. There is no public PoC, no Nuclei template, and the CVE is not in CISA KEV, so opportunistic mass exploitation is unlikely today; the realistic threat is a malicious or compromised low-privilege insider escalating to full project admin. Impact is severe once triggered: complete administrative takeover of any project on the instance, including workflows, credentials, and connected AI agent configurations the attacker had no legitimate access to.

How does the attack unfold?

Initial foothold

Attacker holds a legitimate n8n account scoped only to the narrow role:manageProject global permission.

AML.T0012

Exploit authorization gap

Attacker calls the custom project role deletion endpoint with a reassignment target, exploiting the missing project-level authorization check.

Privilege escalation

All holders of the deleted role, including the attacker, are automatically reassigned to the built-in project:admin role for a project the attacker had no access to.

AML.T0081

Impact

Attacker uses full project admin control to view or modify AI agent workflows and access stored credentials belonging to the compromised project.

AML.T0083

Initial foothold

Attacker holds a legitimate n8n account scoped only to the narrow role:manageProject global permission.

AML.T0012

Exploit authorization gap

Attacker calls the custom project role deletion endpoint with a reassignment target, exploiting the missing project-level authorization check.

Privilege escalation

All holders of the deleted role, including the attacker, are automatically reassigned to the built-in project:admin role for a project the attacker had no access to.

AML.T0081

Impact

Attacker uses full project admin control to view or modify AI agent workflows and access stored credentials belonging to the compromised project.

AML.T0083

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
209.2KOpenSSF 7.116 dependentsPushed today44% patched~19d to patchFull package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.5%

chance of exploitation in 30 days

Higher than 39% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Patch to n8n 2.34.1 (or 2.33.4 for the 2.33.x line) immediately. Before and after patching, audit which users/API keys hold the role:manageProject global scope and review recent project role deletions and membership changes for unexpected assignments to project:admin. Tighten who is granted role:manageProject going forward — treat it as equivalent to broad administrative trust, not a narrow permission. For detection, review n8n audit/activity logs for role-deletion-with-reassignment events performed by accounts that shouldn't have cross-project authority, and rotate credentials/API keys stored in any project where unauthorized admin access is suspected.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth BypassPrivacy ViolationAgentFrameworkAML.T0012- Valid Accounts AML.T0081- Modify AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.9-AI system life cycle and access control

OWASP LLM Top 10

LLM08-Excessive Agency

Frequently Asked Questions

What is CVE-2026-77079?

n8n's custom project role deletion flow validated only that a reassignment target role existed and was project-scoped, without checking whether the requesting user actually had authority over that project. Any user holding just the narrow role:manageProject global scope could delete a custom project role in use elsewhere on the instance and reassign its holders, including themselves, to the built-in project:admin role. That turns a low-privilege account into full administrative control over projects the attacker was never granted access to, with no exploit code, KEV listing, or EPSS data yet in circulation to suggest active exploitation. Given n8n's role as an AI agent orchestration platform with 16 downstream dependents and 201 other CVEs on record for the package, and a mediocre OpenSSF Scorecard of 6.6/10, this is the kind of logic flaw that's easy to miss in a security review but trivial to abuse once a low-privileged insider or compromised low-priv credential exists. Upgrade to n8n 2.34.1 or 2.33.4 immediately, and audit which accounts currently hold role:manageProject and which projects/agents they gained access to before the patch.

Is CVE-2026-77079 actively exploited?

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

How to fix CVE-2026-77079?

Patch to n8n 2.34.1 (or 2.33.4 for the 2.33.x line) immediately. Before and after patching, audit which users/API keys hold the role:manageProject global scope and review recent project role deletions and membership changes for unexpected assignments to project:admin. Tighten who is granted role:manageProject going forward — treat it as equivalent to broad administrative trust, not a narrow permission. For detection, review n8n audit/activity logs for role-deletion-with-reassignment events performed by accounts that shouldn't have cross-project authority, and rotate credentials/API keys stored in any project where unauthorized admin access is suspected.

What systems are affected by CVE-2026-77079?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration pipelines, multi-tenant SaaS deployments.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration pipelinesmulti-tenant SaaS deployments

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0081Modify AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.9

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

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.

Exploitation Scenario

A contractor or junior team member is granted the role:manageProject global scope so they can manage their own team's project roles in n8n. Instead, they call the custom project role deletion API against a role used in a different, more sensitive project (e.g., one running finance or customer-data AI agents), specifying that role's holders be reassigned to project:admin. The flaw's missing project-level check lets the request succeed even though the attacker has no membership in the target project. The attacker is now project:admin there, and uses that access to view stored credentials, modify AI agent workflow logic, or exfiltrate data the automations process.

Weaknesses (CWE)

CWE-639Authorization Bypass Through User-Controlled KeyPrimary CWE-639Authorization Bypass Through User-Controlled Key

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.