Summary
n8n's AI Agents feature includes a node-execution tool that does not enforce proper authorization checks, allowing lower-privileged users to perform actions outside their intended role.
Under certain project configurations, a Project Viewer can escalate privileges by interacting with an agent that has node tools enabled, leading to unauthorized node execution and access to credential secrets.
n8n's AI Agents feature includes a node-execution tool that does not enforce proper authorization checks, allowing lower-privileged users to perform actions outside their intended role.
Under certain project configurations, a Project Viewer can escalate privileges by interacting with an agent that has node tools enabled, leading to unauthorized node execution and access to credential secrets.
Affected context
This vulnerability arises in n8n instances where the AI Agents feature is enabled and agents are configured with node-execution tools.
It is relevant in multi-user projects that differentiate between higher-privileged roles (such as editors or administrators) and lower-privileged roles (such as Project Viewers).
The issue manifests when the node-execution mechanism invoked by AI Agents does not re-check the effective permissions of the requesting user at execution time, allowing a viewer-level user to indirectly trigger operations reserved for more privileged roles, including access to credential-backed nodes.
This vulnerability arises in n8n instances where the AI Agents feature is enabled and agents are configured with node-execution tools.
It is relevant in multi-user projects that differentiate between higher-privileged roles (such as editors or administrators) and lower-privileged roles (such as Project Viewers).
The issue manifests when the node-execution mechanism invoked by AI Agents does not re-check the effective permissions of the requesting user at execution time, allowing a viewer-level user to indirectly trigger operations reserved for more privileged roles, including access to credential-backed nodes.
Exploit preconditions
- Attack surface: Web interface or integrated chat interface for n8n AI Agents.
- Required access: Valid Project Viewer role (or similar low-privilege account) in an affected n8n project.
- Trigger point: Chatting with an AI Agent that has node-execution tools enabled and instructing it to run workflows or nodes that rely on stored credentials or privileged operations.
- Why exploitation is possible: The node tool trusts the agent's configuration and the project context, but does not independently verify that the current user is authorized for the requested node actions or credential access, effectively bypassing role-based access control.
- Attack surface: Web interface or integrated chat interface for n8n AI Agents.
- Required access: Valid Project Viewer role (or similar low-privilege account) in an affected n8n project.
- Trigger point: Chatting with an AI Agent that has node-execution tools enabled and instructing it to run workflows or nodes that rely on stored credentials or privileged operations.
- Why exploitation is possible: The node tool trusts the agent's configuration and the project context, but does not independently verify that the current user is authorized for the requested node actions or credential access, effectively bypassing role-based access control.
Why this happens
The underlying bug is a missing or incomplete authorization check in the AI Agents node-execution path.
Instead of enforcing role-based access control at the moment a node is executed, the implementation allows the agent's tooling to act with project-level privileges without validating the requesting user's permissions.
This maps to CWE-863: Incorrect Authorization, where access is controlled by context or configuration rather than by consistent, user-specific permission checks.
At a pattern level, the system treats the AI Agent as a trusted orchestration layer and fails to propagate user identity and role constraints down to the node-execution subsystem, resulting in privilege escalation.
The underlying bug is a missing or incomplete authorization check in the AI Agents node-execution path.
Instead of enforcing role-based access control at the moment a node is executed, the implementation allows the agent's tooling to act with project-level privileges without validating the requesting user's permissions.
This maps to CWE-863: Incorrect Authorization, where access is controlled by context or configuration rather than by consistent, user-specific permission checks.
At a pattern level, the system treats the AI Agent as a trusted orchestration layer and fails to propagate user identity and role constraints down to the node-execution subsystem, resulting in privilege escalation.
Potential impact
- A Project Viewer may execute nodes that they should not be able to run.
- An attacker with viewer access could retrieve or misuse credential secrets associated with workflows.
- Privileged operations, such as integrations with external services or data exfiltration, can be triggered by an unauthorized user.
- Workflow integrity may be compromised through unauthorized modifications or triggering of sensitive automation.
- A Project Viewer may execute nodes that they should not be able to run.
- An attacker with viewer access could retrieve or misuse credential secrets associated with workflows.
- Privileged operations, such as integrations with external services or data exfiltration, can be triggered by an unauthorized user.
- Workflow integrity may be compromised through unauthorized modifications or triggering of sensitive automation.
General mitigation guidance
Effective mitigation focuses on enforcing strict authorization at every execution boundary and minimizing implicit trust in orchestration features like AI Agents.
Common defensive patterns include:
- Ensuring node execution and credential access always perform explicit permission checks tied to the requesting user's identity and role.
- Treating agent tools as untrusted mediators that must propagate and respect user-level authorization rather than project-level capability.
- Applying least-privilege principles to workflow tools, limiting which nodes and credentials are exposable via AI Agents.
- Segregating sensitive credentials and workflows into contexts that cannot be indirectly accessed through conversational or automated interfaces.
- Designing defaults such that newly created agents and tools have constrained access and must be explicitly granted broader privileges.
Effective mitigation focuses on enforcing strict authorization at every execution boundary and minimizing implicit trust in orchestration features like AI Agents.
Common defensive patterns include:
- Ensuring node execution and credential access always perform explicit permission checks tied to the requesting user's identity and role.
- Treating agent tools as untrusted mediators that must propagate and respect user-level authorization rather than project-level capability.
- Applying least-privilege principles to workflow tools, limiting which nodes and credentials are exposable via AI Agents.
- Segregating sensitive credentials and workflows into contexts that cannot be indirectly accessed through conversational or automated interfaces.
- Designing defaults such that newly created agents and tools have constrained access and must be explicitly granted broader privileges.
How teams detect issues like this
Organizations can detect similar authorization issues by:
- Reviewing AI Agent and node-execution pathways to confirm that user identity and role information are consistently enforced at runtime.
- Using static analysis or manual code review to identify functions that perform sensitive operations (credential access, node execution) without explicit permission checks.
- Implementing security tests that simulate low-privilege accounts interacting with agents and attempting to trigger privileged nodes or read secrets.
- Enforcing architectural policies that require centralized authorization services and prohibit bypassing them via new features or integration layers.
- Leveraging automated security review tools to flag endpoints or features that expose orchestration capabilities without clear RBAC enforcement.
Organizations can detect similar authorization issues by:
- Reviewing AI Agent and node-execution pathways to confirm that user identity and role information are consistently enforced at runtime.
- Using static analysis or manual code review to identify functions that perform sensitive operations (credential access, node execution) without explicit permission checks.
- Implementing security tests that simulate low-privilege accounts interacting with agents and attempting to trigger privileged nodes or read secrets.
- Enforcing architectural policies that require centralized authorization services and prohibit bypassing them via new features or integration layers.
- Leveraging automated security review tools to flag endpoints or features that expose orchestration capabilities without clear RBAC enforcement.
