Summary
A privilege escalation flaw in n8n's Enterprise SSO instance-role provisioning allows certain SSO-authenticated users to be mapped directly to the powerful global:owner role.
If an attacker can influence the IdP-issued instance-role claim while SSO role provisioning is enabled, they may be provisioned as an instance owner and gain full administrative control over the n8n instance.
A privilege escalation flaw in n8n's Enterprise SSO instance-role provisioning allows certain SSO-authenticated users to be mapped directly to the powerful global:owner role.
If an attacker can influence the IdP-issued instance-role claim while SSO role provisioning is enabled, they may be provisioned as an instance owner and gain full administrative control over the n8n instance.
Affected context
This vulnerability occurs in n8n deployments that:
- Use Enterprise SSO for authentication, and
- Have instance-role provisioning enabled via
N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE, and - Rely on IdP-supplied role claims to assign n8n global roles.
In this context, the SSO provisioning logic does not explicitly block assignment of the global:owner role, allowing a role claim that resolves to global:owner to be accepted and provisioned. The issue does not affect paths that already implement explicit owner-role rejection (such as the token-exchange identity path).
This vulnerability occurs in n8n deployments that:
- Use Enterprise SSO for authentication, and
- Have instance-role provisioning enabled via
N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLE, and - Rely on IdP-supplied role claims to assign n8n global roles.
In this context, the SSO provisioning logic does not explicitly block assignment of the global:owner role, allowing a role claim that resolves to global:owner to be accepted and provisioned. The issue does not affect paths that already implement explicit owner-role rejection (such as the token-exchange identity path).
Exploit preconditions
- Attack surface: n8n Enterprise SSO login endpoint where instance-role claims are consumed.
- Required access: Ability to authenticate via the configured IdP to the target n8n instance.
- IdP control: The attacker must be able to control or meaningfully influence the instance-role claim value issued by the IdP (e.g., through misconfigured group/attribute mappings, self-assignable roles, or compromised IdP administration).
- Feature flags/config: Enterprise SSO must be enabled and
N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLEturned on for instance-role provisioning. - Why exploitation is possible: The provisioning logic maps IdP role claims directly to n8n global roles and does not enforce a restriction on the
global:ownerrole, allowing an attacker-controlled claim to escalate privileges to instance owner.
- Attack surface: n8n Enterprise SSO login endpoint where instance-role claims are consumed.
- Required access: Ability to authenticate via the configured IdP to the target n8n instance.
- IdP control: The attacker must be able to control or meaningfully influence the instance-role claim value issued by the IdP (e.g., through misconfigured group/attribute mappings, self-assignable roles, or compromised IdP administration).
- Feature flags/config: Enterprise SSO must be enabled and
N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLEturned on for instance-role provisioning. - Why exploitation is possible: The provisioning logic maps IdP role claims directly to n8n global roles and does not enforce a restriction on the
global:ownerrole, allowing an attacker-controlled claim to escalate privileges to instance owner.
Why this happens
The underlying issue is an authorization design flaw aligning with CWE-639: Authorization Bypass Through User-Controlled Key.
The SSO provisioning path treats an IdP-supplied role claim as a trusted selector for high-privilege n8n global roles without sufficient server-side constraints. Unlike the token-exchange identity path, which explicitly rejects owner-role assignment, the instance-role provisioning logic fails to enforce a denylist or policy that prevents direct mapping to global:owner. This creates a situation where a user, by manipulating or benefiting from misconfigured IdP role attributes, can have their account provisioned with an administrative role that should only be assigned through tightly controlled administrative workflows.
The underlying issue is an authorization design flaw aligning with CWE-639: Authorization Bypass Through User-Controlled Key.
The SSO provisioning path treats an IdP-supplied role claim as a trusted selector for high-privilege n8n global roles without sufficient server-side constraints. Unlike the token-exchange identity path, which explicitly rejects owner-role assignment, the instance-role provisioning logic fails to enforce a denylist or policy that prevents direct mapping to global:owner. This creates a situation where a user, by manipulating or benefiting from misconfigured IdP role attributes, can have their account provisioned with an administrative role that should only be assigned through tightly controlled administrative workflows.
Potential impact
- An SSO-authenticated user may be escalated to
global:ownerfor the instance. - Attackers could gain full administrative control over workflows, their execution, and scheduling.
- Existing and new credentials stored in n8n can be viewed, modified, or exfiltrated.
- User management can be altered, including creating, disabling, or changing roles of other users.
- Instance-wide configuration, integrations, and security settings can be modified, weakening defenses or enabling persistence.
- An SSO-authenticated user may be escalated to
global:ownerfor the instance. - Attackers could gain full administrative control over workflows, their execution, and scheduling.
- Existing and new credentials stored in n8n can be viewed, modified, or exfiltrated.
- User management can be altered, including creating, disabling, or changing roles of other users.
- Instance-wide configuration, integrations, and security settings can be modified, weakening defenses or enabling persistence.
General mitigation guidance
Effective mitigation focuses on tightening the trust boundary around IdP-issued role claims and enforcing stricter role-mapping policies:
- Introduce explicit server-side restrictions that prevent SSO or any automated provisioning path from assigning the
global:ownerrole. - Separate high-privilege role assignment from automated IdP-driven mappings; require manual, auditable administrative action for instance-owner promotion.
- Implement an allowlist of roles eligible for SSO-based provisioning, excluding any owner or equivalent high-privilege roles.
- Harden IdP configurations so that role or group attributes used for n8n mappings cannot be arbitrarily modified by end users and are only managed by trusted administrators.
- Apply least-privilege principles to role design and avoid overloading roles with permissions beyond what is operationally necessary.
Effective mitigation focuses on tightening the trust boundary around IdP-issued role claims and enforcing stricter role-mapping policies:
- Introduce explicit server-side restrictions that prevent SSO or any automated provisioning path from assigning the
global:ownerrole. - Separate high-privilege role assignment from automated IdP-driven mappings; require manual, auditable administrative action for instance-owner promotion.
- Implement an allowlist of roles eligible for SSO-based provisioning, excluding any owner or equivalent high-privilege roles.
- Harden IdP configurations so that role or group attributes used for n8n mappings cannot be arbitrarily modified by end users and are only managed by trusted administrators.
- Apply least-privilege principles to role design and avoid overloading roles with permissions beyond what is operationally necessary.
How teams detect issues like this
Organizations can detect and monitor for this class of issue using:
- Configuration reviews: Periodically review n8n SSO configuration, focusing on whether
N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLEis enabled and how role mappings are defined. - IdP policy audits: Inspect IdP group/attribute mappings that feed into n8n role claims, ensuring only controlled groups map to elevated roles.
- Logging and alerting: Enable and review authentication and provisioning logs to detect unexpected owner-role assignments or changes in user role distribution.
- Static and policy checks: Use configuration-as-code, security policy enforcement, or automated review tools to flag high-privilege roles being assigned via automated SSO provisioning paths.
Organizations can detect and monitor for this class of issue using:
- Configuration reviews: Periodically review n8n SSO configuration, focusing on whether
N8N_SSO_SCOPES_PROVISION_INSTANCE_ROLEis enabled and how role mappings are defined. - IdP policy audits: Inspect IdP group/attribute mappings that feed into n8n role claims, ensuring only controlled groups map to elevated roles.
- Logging and alerting: Enable and review authentication and provisioning logs to detect unexpected owner-role assignments or changes in user role distribution.
- Static and policy checks: Use configuration-as-code, security policy enforcement, or automated review tools to flag high-privilege roles being assigned via automated SSO provisioning paths.
