CVE-2026-65016: n8n SSO instance-role provisioning

Q: Is CVE-2026-65016 actively exploited?

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

Q: How to fix CVE-2026-65016?

Patch immediately: upgrade to n8n 1.123.64, 2.29.8, or 2.30.1, all of which fix the instance-role provisioning path to reject global:owner assignment consistent with the token-exchange identity path. If immediate patching isn't possible, disable N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE to turn off instance-role provisioning entirely as a workaround. Audit your IdP's role-claim attribute release configuration to confirm the claim value cannot be set or influenced by non-privileged users, and review current n8n users for any accounts that received global:owner via SSO provisioning that shouldn't have that privilege. For detection, monitor n8n's user/role audit logs for unexpected global:owner grants correlated with SSO logins, and alert on any new owner-role account creation outside your standard admin onboarding process.

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

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

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

No CVSS score has been assigned yet.

CISO Take

n8n's Enterprise SSO instance-role provisioning maps an identity provider's role claim directly to n8n's internal roles but fails to block assignment of the global:owner role, unlike the equivalent token-exchange path that explicitly rejects it — so a user whose IdP-asserted claim resolves to owner is silently granted full administrative control over workflows, credentials, and instance configuration. This matters because n8n orchestrates AI agent workflows and typically stores the credentials for every connected LLM API, vector database, and integrated service inside those workflows, so an owner-level compromise exposes all of it in one shot; the package also carries a non-trivial footprint (16 downstream dependents, 150 other CVEs recorded against it, OpenSSF Scorecard 6.6/10). There's no CVSS score, EPSS data, CISA KEV listing, or public exploit/scanner coverage yet, and exploitation is gated behind a non-default configuration (N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE must be explicitly enabled) plus attacker control over the IdP claim value — so this is not a mass-exploitable bug, but a serious risk for any org that has enabled instance-role provisioning with loosely governed IdP attribute release. Patch to n8n 1.123.64, 2.29.8, or 2.30.1 immediately if Enterprise SSO is in use; in the interim, disable N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE or lock down the IdP claim so only trusted, admin-controlled attributes can resolve to owner, and audit current users for any SSO-provisioned global:owner grants.

Sources: NVD GitHub Advisory VulnCheck ATLAS

What is the risk?

Exploitability is conditional rather than remote/unauthenticated: the flaw only manifests when Enterprise SSO is configured AND N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE is explicitly enabled (disabled by default), AND the attacker can influence the value of the instance-role claim asserted by the IdP — a bar that typically requires a compromised or malicious IdP account, weak attribute-release governance, or an insider with claim-editing privileges. No CVSS vector, EPSS score, or CISA KEV listing is available, and there is no public exploit code or Nuclei template, so this is not yet a mass-scan target. However, impact is severe and effectively instantaneous once the precondition is met: successful exploitation grants unrestricted global:owner access — full control over all workflows, stored credentials, users, and instance configuration — with no further steps required. Organizations running n8n Enterprise with SSO instance-role provisioning enabled should treat this as high-priority despite the missing severity score, given the binary jump from any authenticated SSO user to full admin.

How does the attack unfold?

Initial Access

Attacker controls or manipulates the IdP-asserted instance-role claim value (via a compromised/self-editable IdP attribute or insider access) and authenticates to n8n through Enterprise SSO.

AML.T0012

Privilege Escalation

n8n's SSO instance-role provisioning path maps the claim directly to global:owner without the validation present in the token-exchange identity path (CWE-639).

AML.T0047

Credential & Workflow Access

As instance owner, the attacker reads and modifies all stored credentials and AI agent workflow definitions, including LLM API keys and connector secrets.

AML.T0083

Impact

Attacker exfiltrates credentials, tampers with production automations, and creates persistent backdoor accounts, achieving full compromise of the instance and any downstream systems the workflows touch.

AML.T0025

Initial Access

Attacker controls or manipulates the IdP-asserted instance-role claim value (via a compromised/self-editable IdP attribute or insider access) and authenticates to n8n through Enterprise SSO.

AML.T0012

Privilege Escalation

n8n's SSO instance-role provisioning path maps the claim directly to global:owner without the validation present in the token-exchange identity path (CWE-639).

AML.T0047

Credential & Workflow Access

As instance owner, the attacker reads and modifies all stored credentials and AI agent workflow definitions, including LLM API keys and connector secrets.

AML.T0083

Impact

Attacker exfiltrates credentials, tampers with production automations, and creates persistent backdoor accounts, achieving full compromise of the instance and any downstream systems the workflows touch.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.64	`1.123.64`
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 24% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Patch immediately: upgrade to n8n 1.123.64, 2.29.8, or 2.30.1, all of which fix the instance-role provisioning path to reject global:owner assignment consistent with the token-exchange identity path. If immediate patching isn't possible, disable N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE to turn off instance-role provisioning entirely as a workaround. Audit your IdP's role-claim attribute release configuration to confirm the claim value cannot be set or influenced by non-privileged users, and review current n8n users for any accounts that received global:owner via SSO provisioning that shouldn't have that privilege. For detection, monitor n8n's user/role audit logs for unexpected global:owner grants correlated with SSO logins, and alert on any new owner-role account creation outside your standard admin onboarding process.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

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

How is it classified?

Auth Bypass Data Leakage Agent Framework AML.T0012 - Valid Accounts AML.T0047 - AI-Enabled Product or Service AML.T0083 - Credentials from AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

NIST AI RMF

GOVERN 1.5 - Ongoing monitoring and periodic review of risk management processes and roles

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-65016?

n8n's Enterprise SSO instance-role provisioning maps an identity provider's role claim directly to n8n's internal roles but fails to block assignment of the global:owner role, unlike the equivalent token-exchange path that explicitly rejects it — so a user whose IdP-asserted claim resolves to owner is silently granted full administrative control over workflows, credentials, and instance configuration. This matters because n8n orchestrates AI agent workflows and typically stores the credentials for every connected LLM API, vector database, and integrated service inside those workflows, so an owner-level compromise exposes all of it in one shot; the package also carries a non-trivial footprint (16 downstream dependents, 150 other CVEs recorded against it, OpenSSF Scorecard 6.6/10). There's no CVSS score, EPSS data, CISA KEV listing, or public exploit/scanner coverage yet, and exploitation is gated behind a non-default configuration (N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE must be explicitly enabled) plus attacker control over the IdP claim value — so this is not a mass-exploitable bug, but a serious risk for any org that has enabled instance-role provisioning with loosely governed IdP attribute release. Patch to n8n 1.123.64, 2.29.8, or 2.30.1 immediately if Enterprise SSO is in use; in the interim, disable N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE or lock down the IdP claim so only trusted, admin-controlled attributes can resolve to owner, and audit current users for any SSO-provisioned global:owner grants.

Is CVE-2026-65016 actively exploited?

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

How to fix CVE-2026-65016?

Patch immediately: upgrade to n8n 1.123.64, 2.29.8, or 2.30.1, all of which fix the instance-role provisioning path to reject global:owner assignment consistent with the token-exchange identity path. If immediate patching isn't possible, disable N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE to turn off instance-role provisioning entirely as a workaround. Audit your IdP's role-claim attribute release configuration to confirm the claim value cannot be set or influenced by non-privileged users, and review current n8n users for any accounts that received global:owner via SSO provisioning that shouldn't have that privilege. For detection, monitor n8n's user/role audit logs for unexpected global:owner grants correlated with SSO logins, and alert on any new owner-role account creation outside your standard admin onboarding process.

What systems are affected by CVE-2026-65016?

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

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworks

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0047 AI-Enabled Product or Service

AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: GOVERN 1.5

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

n8n versions before 1.123.64, 2.29.8, and 2.30.1 contain a privilege escalation vulnerability in Enterprise SSO instance-role provisioning. The provisioning path maps an IdP-asserted role claim to an n8n global role but does not prevent assignment of the global:owner role (unlike the token-exchange identity path, which rejects it). An SSO-authenticated user whose instance-role claim resolves to global:owner is provisioned as instance owner, gaining full administrative control over workflows, credentials, users, and instance configuration. Exploitation requires that Enterprise SSO is configured, instance-role provisioning is enabled via N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE (disabled by default), and the attacker controls the instance-role claim value issued by the IdP.

Exploitation Scenario

An organization has enabled n8n Enterprise SSO with N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE turned on to auto-provision roles from their IdP, and the IdP's instance-role claim is populated from a directory attribute that a helpdesk team member or the user themselves can edit — a common IdP misconfiguration. An attacker who compromises that low-privilege account, or is a malicious insider, sets or manipulates the role-claim attribute to a value the org intended only for administrators, then authenticates to n8n via SSO. n8n's provisioning logic maps the claim straight to global:owner without the safeguard present in the token-exchange path, silently granting the attacker full instance ownership. From there, the attacker exports every stored credential (OpenAI/Anthropic API keys, database secrets), modifies production AI agent workflows to exfiltrate data on every run, and creates a secondary owner account for persistence — all without triggering any alert, since the access came through a legitimate SSO login.

Weaknesses (CWE)

CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization 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.