CVE-2026-86996: Missing Authorization in n8n AI Agent Workflow Tool Execution

The n8n workflow automation platform provides multi-user workspace environments designed to segregate projects and resources. To enforce boundary controls, n8n implements the Sub-Workflow Caller Policy, which restricts which workflows can invoke other workflows. This policy is primarily configured via the 'This workflow can be called by' setting, establishing access limits based on workspace, project, or specific workflow identifiers.

With the integration of AI capabilities, n8n introduced AI Agents that can dynamically invoke external functions and workflows as tools. The security architecture relies on these tool executions respecting the same access policies as standard node-based workflow invocations. However, a structural omission in the execution path allows AI Agents to bypass the standard boundary checks entirely.

This vulnerability, tracked as CVE-2026-86996, represents a missing authorization flaw (CWE-862) with a CVSS 4.0 base score of 5.3. An authenticated attacker possessing basic workspace privileges can exploit this gap to execute workflows residing in other, restricted workspaces, leading to unauthorized access to downstream systems and data exfiltration.

The vulnerability resides in the core Agent execution subsystem within the n8n codebase. Specifically, the file packages/cli/src/modules/agents/tools/workflow-tool-factory.ts is responsible for generating tool definitions and handling execution requests when an AI Agent invokes an attached workflow tool. The core function within this module, executeWorkflow, manages the runtime instantiation and execution pipeline of the target workflow.

In standard execution paths, such as when a workflow executes another workflow using the 'Execute Workflow' node, n8n calls a policy validation utility. This utility, implemented in SubworkflowPolicyChecker.checkForProject, evaluates the caller's project context against the target workflow's 'This workflow can be called by' policy setting. If the caller does not reside within the permitted projects or workspaces, execution is aborted with an authorization error.

In the AI Agent workflow tool factory, this mandatory validation logic was entirely omitted from the execution path. The executeWorkflow function initiated execution directly through the workflow engine without consulting SubworkflowPolicyChecker. As a result, the backend executes the sub-workflow under the context of the workflow engine without verifying that the caller's project owns or has explicit permission to trigger the target workflow.

Analysis of the vulnerable code path reveals that the engine invoked the target workflow without verifying caller parameters against the sub-workflow's metadata. The following conceptual representation illustrates the omission in the workflow-tool-factory.ts file prior to the patch:

// VULNERABLE CODE PATH
async function executeWorkflow(workflowId: string, inputData: any, context: ExecutionContext) {
  // Missing authorization check
  // The engine directly loads and executes the sub-workflow
  const workflow = await this.workflowRepository.findById(workflowId);
  
  return await this.workflowRunner.run(workflow, inputData);
}

To resolve this flaw, the developers integrated the policy checker into the execution pipeline of the workflow tool factory. The patched implementation enforces project and workspace alignment by explicitly validating the executing context prior to running the target workflow:

// PATCHED CODE PATH
async function executeWorkflow(workflowId: string, inputData: any, context: ExecutionContext) {
  const targetWorkflow = await this.workflowRepository.findById(workflowId);
  
  // ENFORCED AUTHORIZATION CHECK
  // Verifies that the current project context has permission to call the target sub-workflow
  await this.subworkflowPolicyChecker.checkForProject({
    targetWorkflow,
    callerProjectId: context.projectId,
    callerWorkflowId: context.workflowId,
  });
  
  return await this.workflowRunner.run(targetWorkflow, inputData);
}

By placing the checkForProject call before the execution runner, n8n guarantees that any execution attempt originating from an AI Agent tool configuration is blocked if it violates the caller policy. This design completely aligns the AI Agent tool path with the security controls governing traditional sub-workflow nodes.

Exploitation of CVE-2026-86996 does not require advanced privileges or complex networking setup. The attacker must possess an authenticated account on the target n8n instance with permissions sufficient to create or edit AI Agents. The process begins with the attacker identifying the target workflow ID of a restricted workflow, which can often be obtained via internal enumeration or application resource mapping.

Once the target workflow ID is acquired, the attacker configures a malicious AI Agent within a workspace under their control. The attacker adds the restricted workflow as an executable tool to this agent. Because the UI and API allow configuring arbitrary workflow IDs as tools, this step succeeds despite the cross-project or restrictive policy boundaries defined on the target workflow.

To trigger the exploit, the attacker sends a natural language prompt to the AI Agent instructing it to invoke the attached tool and return the output. The AI Agent initiates the execution process via the workflow-tool-factory.ts pathway. Due to the missing authorization check, the backend executes the sensitive workflow, retrieves the results, and hands them back to the agent. The agent then displays the returned database records, API tokens, or internal execution logs directly to the attacker.

The security impact of this vulnerability is characterized by unauthorized execution and subsequent information disclosure. An attacker can execute arbitrary workflows that they are not authorized to access. This can result in unauthorized modifications if the target workflow performs state-changing actions such as updating internal databases, modifying system configurations, or executing external HTTP API requests with administrative credentials.

Additionally, because the execution results are returned to the calling AI Agent, the attacker gains direct access to sensitive execution outputs. This leads to the exposure of confidential records, customer data, and system keys processed by the sub-workflow. The CVSS 4.0 score of 5.3 reflects the localized nature of the impact, as the attacker must already hold valid authenticated access to the platform.

No active exploitation in the wild has been observed, and there are currently no public proof-of-concept exploits available. This reduces the immediate risk for organizations that limit access to fully trusted internal developers. However, the ease of exploitation makes immediate remediation critical for multi-tenant and enterprise installations where user isolation is a primary security boundary.

The primary remediation strategy for CVE-2026-86996 is upgrading the n8n application to a patched release. The fix is backported and available in versions 2.37.7 and 2.38.2. Administrators should apply these updates immediately to secure their execution environments.

If upgrading cannot be scheduled immediately, several temporary mitigations can reduce the attack surface. Administrators should audit all active AI Agent configurations across all workspaces to identify and remove unauthorized workflow tools. Additionally, restricting the permission to create or modify AI Agents to administrative users prevents lower-privileged accounts from initiating the exploit path.

Organizations should also enforce network-level or application-level access controls to ensure only authorized personnel can access the n8n interface. These compensating controls limit exposure but do not replace the necessity of applying the software updates.