CVE-2026-86996 in n8n
Summary
by MITRE • 09/09/2026
n8n is an open source workflow automation platform. Prior to 2.37.7 and 2.38.2, the workflow setting named This workflow can be called by was enforced by the Execute Workflow node but not when a workflow was attached to an Agent as a tool. A user able to build an Agent could invoke a restricted workflow and read its returned data. The affected path is packages/cli/src/modules/agents/tools/workflow-tool-factory.ts, where executeWorkflow omitted SubworkflowPolicyChecker.checkForProject. This issue is fixed in versions 2.37.7 and 2.38.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in n8n prior to versions 2.37.7 and 2.38.2 represents a critical authorization bypass within the platform's workflow execution engine, specifically affecting how agents interact with underlying workflows when configured as tools. n8n is an open-source workflow automation platform that allows users to create complex automated processes by connecting various nodes. A key security feature in this architecture is the ability to restrict certain workflows so they can only be invoked under specific conditions, such as being called directly via a dedicated Execute Workflow node rather than through other integration points like agents or external APIs. This restriction mechanism relies on a policy checker that validates whether the current execution context permits access to the target workflow based on project-level permissions and security policies.
The technical flaw stems from an inconsistency in how this authorization check is applied across different invocation paths within the codebase. Specifically, when a workflow was attached to an Agent as a tool, the system failed to enforce the same restrictions that were strictly enforced during direct execution via the Execute Workflow node. The root cause lies in the file packages/cli/src/modules/agents/tools/workflow-tool-factory.ts, where the executeWorkflow function omitted a call to SubworkflowPolicyChecker.checkForProject. This omission meant that while standard workflow executions underwent rigorous policy validation, agent-invoked workflows bypassed this security gate entirely. Consequently, any user with the ability to build or configure an Agent could leverage this path to invoke workflows marked as restricted, effectively circumventing the intended access controls designed by administrators and developers.
The operational impact of this vulnerability is significant for organizations relying on n8n for sensitive automation tasks involving proprietary data or critical business logic. An attacker who can create agents within the platform gains the ability to read returned data from workflows that were explicitly configured to be inaccessible via agent tools. This could lead to unauthorized disclosure of confidential information, such as customer data, financial records, or internal system states, depending on what the restricted workflow processes and returns. Since n8n is often used in enterprise environments where role-based access control is crucial for compliance with standards like GDPR or HIPAA, this bypass undermines the integrity of those security models by allowing lower-privileged users to escalate their effective permissions through agent configuration rather than direct API exploitation.
This vulnerability aligns with CWE-269, Improper Privilege Management, as it involves a failure to enforce proper access control policies for different user roles or execution contexts. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, specifically in the context of using legitimate system features (agent tool invocation) to perform unauthorized actions that should be restricted by policy. The flaw highlights the importance of consistent security enforcement across all entry points within an application architecture, ensuring that business logic restrictions are not bypassed through alternative execution paths.
To mitigate this vulnerability and prevent similar issues in future deployments, organizations must immediately upgrade n8n to version 2.37.7 or later for stable releases, or version 2.38.2 and above for newer branches. These versions include the necessary code changes to ensure that SubworkflowPolicyChecker.checkForProject is correctly invoked regardless of whether a workflow is called directly or through an agent tool. Additionally, administrators should review existing agents and workflows to identify any potentially sensitive processes that were previously protected by these restrictions but may have been exposed due to this flaw. Implementing strict monitoring for unusual workflow execution patterns can also help detect potential exploitation attempts in environments where upgrading might be delayed temporarily. Regular security audits of custom node implementations and agent configurations are recommended to maintain robust access control hygiene within the automation platform.