CVE-2026-86996: n8n: Agent Workflow Tool Bypasses Sub-Workflow Caller Policy

In n8n, the "This workflow can be called by" setting limits which workflows may invoke a sub-workflow. The Execute Workflow node enforced it. The Agent tool path did not check it. If a workflow owner restricted callers, any user who could create an Agent could still add that workflow as a tool, run it, and read the returned data.

The attacker needs an authenticated n8n account with permission to build Agents, and network access to the instance. They do not need access to the restricted workflow itself. What they get is whatever the workflow returns. That could be records from a database, results from an API call made with credentials the workflow holds, or other internal data. The CVSS 4.0 vector rates confidentiality and integrity impact as low, because the attacker can run the workflow but only gets what its output exposes. If the workflow has side effects, running it can also change data.

The flaw is a missing authorization check (CWE-862). It matters most on shared instances where owners rely on caller policy to fence off sensitive sub-workflows.

n8n before 2.37.7, and versions from 2.38.0 up to but not including 2.38.2. Instances with several users who can build Agents, and sub-workflows restricted by caller policy, are the exposed case.

npm ls n8n

For Docker, check the image tag. The version also shows in the n8n UI under Help, then About.

Upgrade to 2.37.7 if you run the 2.37 line, or 2.38.2 if you run 2.38. Later versions also include the fix.

npm install [email protected]

The patch applies the sub-workflow caller policy on the Agent tool path. If you cannot upgrade yet, the advisory suggests these temporary steps, which do not fully remove the risk:

• Restrict instance access to fully trusted users.
• Audit workflows attached as Agent tools and review their caller policy.
• Remove sensitive workflows from Agent tool configurations until patched.

Review the Agent nodes across your instance for workflows attached as tools that are set to a restricted "This workflow can be called by" policy and that the Agent's owner does not own. Check the execution history of sensitive sub-workflows for runs triggered by an Agent execution instead of an Execute Workflow node, especially from accounts that are not on the allowed list.

Impact

A workflow's "_This workflow can be called by_" setting was enforced by the Execute Workflow node but was not consulted when the same workflow was attached to an Agent as a tool. A user who could build an Agent could therefore call a workflow that its owner had restricted, and read back what it returned. The patch applies the sub-workflow caller policy on the Agent tool path.

Patches

The issue has been fixed in n8n versions 2.37.7 and 2.38.2. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

• Restrict n8n instance access to fully trusted users only.
• Audit workflows attached as Agent tools and review their caller policy settings.
• Remove sensitive workflows from Agent tool configurations until the instance is patched.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.