Summary
n8n's Token Exchange module incorrectly issues JWTs with all Public API scopes, regardless of the acting user's actual role.
On instances with Token Exchange and the Public API enabled, a low-privileged user who presents a trusted external JWT can invoke administrator-only operations and, in some configurations, achieve remote code execution.
n8n's Token Exchange module incorrectly issues JWTs with all Public API scopes, regardless of the acting user's actual role.
On instances with Token Exchange and the Public API enabled, a low-privileged user who presents a trusted external JWT can invoke administrator-only operations and, in some configurations, achieve remote code execution.
Affected context
This vulnerability occurs in n8n deployments that enable both the Token Exchange feature and the Public API, and trust an external JWT issuer for authentication.
It is most relevant where low-privileged users can obtain valid external JWTs and where advanced features such as role escalation, user management via the Public API, and unverified Community Package installation are available.
The risk increases in multi-tenant or shared environments where users have limited roles but broad access to API authentication flows.
This vulnerability occurs in n8n deployments that enable both the Token Exchange feature and the Public API, and trust an external JWT issuer for authentication.
It is most relevant where low-privileged users can obtain valid external JWTs and where advanced features such as role escalation, user management via the Public API, and unverified Community Package installation are available.
The risk increases in multi-tenant or shared environments where users have limited roles but broad access to API authentication flows.
Exploit preconditions
- Attack surface: n8n Public API and Token Exchange endpoints exposed to users
- Required access: Ability for a low-privileged user to obtain a valid external JWT from a configured, trusted issuer
- Trigger point: Calling the Token Exchange module to convert the external JWT into an n8n access token, then using that token against the Public API
- Why exploitation is possible: The Token Exchange logic assigns all Public API key scopes to issued JWTs without enforcing role-based restrictions, effectively granting administrative-level API permissions to any holder of a trusted external token
- Attack surface: n8n Public API and Token Exchange endpoints exposed to users
- Required access: Ability for a low-privileged user to obtain a valid external JWT from a configured, trusted issuer
- Trigger point: Calling the Token Exchange module to convert the external JWT into an n8n access token, then using that token against the Public API
- Why exploitation is possible: The Token Exchange logic assigns all Public API key scopes to issued JWTs without enforcing role-based restrictions, effectively granting administrative-level API permissions to any holder of a trusted external token
Why this happens
The underlying issue is a privilege management error where authorization scopes are not correctly tied to the authenticated user's actual role.
Instead of deriving Public API scopes from role mappings or explicit policy rules, the Token Exchange flow grants all Public API key scopes to every issued JWT.
This maps to CWE-269: Improper Privilege Management, as the system fails to constrain assigned privileges according to the least-privilege principle and misconfigures permission boundaries between low-privileged and administrative users.
The underlying issue is a privilege management error where authorization scopes are not correctly tied to the authenticated user's actual role.
Instead of deriving Public API scopes from role mappings or explicit policy rules, the Token Exchange flow grants all Public API key scopes to every issued JWT.
This maps to CWE-269: Improper Privilege Management, as the system fails to constrain assigned privileges according to the least-privilege principle and misconfigures permission boundaries between low-privileged and administrative users.
Potential impact
- A low-privileged user may escalate privileges to administrator-only roles (when Advanced Permissions are licensed).
- Attackers could create, modify, or delete user accounts via the Public API.
- Unauthorized removal of legitimate users can disrupt workflows and availability.
- When unverified Community Package installation is enabled, attackers can install malicious packages and potentially achieve remote code execution within the n8n environment.
- Compromise of automation workflows, data integrations, and connected systems through elevated control of n8n.
- A low-privileged user may escalate privileges to administrator-only roles (when Advanced Permissions are licensed).
- Attackers could create, modify, or delete user accounts via the Public API.
- Unauthorized removal of legitimate users can disrupt workflows and availability.
- When unverified Community Package installation is enabled, attackers can install malicious packages and potentially achieve remote code execution within the n8n environment.
- Compromise of automation workflows, data integrations, and connected systems through elevated control of n8n.
General mitigation guidance
Mitigation centers on enforcing strict, role-aware authorization for all token issuance and API access flows.
Common defensive patterns include:
- Ensuring token exchange mechanisms derive scopes from the authenticated user's role and explicit permission policies rather than from generic API keys.
- Applying the principle of least privilege to all access tokens, limiting scopes to only what is required for the user's intended operations.
- Segregating administrator-only operations behind separate authorization controls and, where possible, interactive confirmation mechanisms.
- Restricting or hardening community extension installation by requiring verification, signing, or administrative approval for packages that can execute code.
- Regularly reviewing privilege mappings and access policies to detect overly broad assignments or misconfigurations in identity and access management integrations.
Mitigation centers on enforcing strict, role-aware authorization for all token issuance and API access flows.
Common defensive patterns include:
- Ensuring token exchange mechanisms derive scopes from the authenticated user's role and explicit permission policies rather than from generic API keys.
- Applying the principle of least privilege to all access tokens, limiting scopes to only what is required for the user's intended operations.
- Segregating administrator-only operations behind separate authorization controls and, where possible, interactive confirmation mechanisms.
- Restricting or hardening community extension installation by requiring verification, signing, or administrative approval for packages that can execute code.
- Regularly reviewing privilege mappings and access policies to detect overly broad assignments or misconfigurations in identity and access management integrations.
How teams detect issues like this
Detection often relies on a combination of access control reviews and behavioral monitoring:
- Inspect token issuance logic to verify that scopes are computed from roles, groups, or claims rather than being statically or maximally assigned.
- Use static analysis and configuration reviews to flag APIs or modules that grant full administrative scopes without explicit role checks.
- Monitor Public API audit logs for anomalous activity by low-privileged accounts, such as role changes, user creation, or deletion events.
- Implement policy-based access controls and automated checks in CI/CD or configuration management pipelines to prevent deployment of insecure privilege mappings.
- Employ automated security testing tools that simulate low-privilege users and validate that administrative actions cannot be performed with their tokens.
Detection often relies on a combination of access control reviews and behavioral monitoring:
- Inspect token issuance logic to verify that scopes are computed from roles, groups, or claims rather than being statically or maximally assigned.
- Use static analysis and configuration reviews to flag APIs or modules that grant full administrative scopes without explicit role checks.
- Monitor Public API audit logs for anomalous activity by low-privileged accounts, such as role changes, user creation, or deletion events.
- Implement policy-based access controls and automated checks in CI/CD or configuration management pipelines to prevent deployment of insecure privilege mappings.
- Employ automated security testing tools that simulate low-privilege users and validate that administrative actions cannot be performed with their tokens.
