# PIR-2026-0058 - n8n: a workflow's "can be called by" access control is enforced on the normal execution path but not when the same workflow is attached to an AI Agent as a tool

- `id`: PIR-2026-0058
- `title`: In n8n (a workflow-automation platform with AI Agent nodes), the per-workflow "This workflow can be called by" access-control setting is honoured by the Execute Workflow node but is not consulted when the same workflow is attached to an Agent as a tool - so a builder can invoke a restricted workflow through the agent tool surface that they could not invoke directly. CVE-2026-86996 / GHSA-7hgx-277f-7vmg, CWE-862 (Missing Authorization), fixed in 2.38.2 and 2.37.7
- `date_occurred`: not applicable - vulnerability disclosure (no confirmed in-the-wild exploitation tied to this CVE)
- `date_detected`: coordinated disclosure to n8n; no individual discoverer is credited in the advisory
- `date_disclosed`: 2026-09-02 (GitHub Security Advisory GHSA-7hgx-277f-7vmg / CVE-2026-86996 published; advisory reviewed/updated 2026-09-08)
- `status`: corroborated (GitHub Security Advisory GHSA-7hgx-277f-7vmg / CVE-2026-86996 read 2026-09-09; product, affected/fixed versions, mechanism, CWE and CVSS confirmed)

### The agent
- `agent_description`: n8n, a workflow-automation platform with AI Agent nodes. A workflow can be exposed to an Agent as a callable tool; the Agent invokes it during a run. n8n also has a "This workflow can be called by" setting that restricts which callers may invoke a given workflow - an access control intended to hold across the platform.
- `operator_type`: unknown (affects any deployment running an affected n8n version; the flaw is in the platform's agent-tool integration, not one operator's configuration). Exploitation requires an actor with agent-building privileges on the instance
- `autonomy_level`: human-on-the-loop (n8n Agents run workflows under an operator's design and supervision); the flaw is that the agent tool path does not apply the same authorization as the direct path
- `model_stack`: model-agnostic - the defect is in n8n's agent/tool wiring, independent of which LLM drives the Agent
- `harness`: n8n (npm). Affected: >= 2.38.0 and < 2.38.2, and versions < 2.37.7. Fixed in 2.38.2 and 2.37.7
- `authority_scope`: invocation of workflows that the "can be called by" control was meant to restrict, via the Agent-as-tool path. The concrete authority depends on what those workflows do (they may have real side effects - external calls, writes, notifications); the vulnerability is the missing check, CWE-862

### Authority
- `authority_scope`: bypass of the workflow-invocation access control through the agent tool surface - a builder can reach restricted workflows (and whatever side effects they carry) that the Execute Workflow node would have refused
- `funds_at_risk_usd`: unknown
- `blast_radius`: one n8n instance/tenant per affected deployment; bounded by requiring an actor who already has agent-building privileges (an insider or a low-privilege builder escalating to restricted workflows), not an anonymous external attacker

### The failure
- `root_cause`: tool-error (the agent-as-tool code path does not consult the authorization control that the normal Execute Workflow path enforces - a missing-authorization gap, CWE-862, specific to the agent tool surface). The check exists and works on one path and is simply absent on the other. Per the CVE record the exact omission is in `packages/cli/src/modules/agents/tools/workflow-tool-factory.ts`, where `executeWorkflow` did not call `SubworkflowPolicyChecker.checkForProject` - the same policy check the Execute Workflow path runs
- `failure_locus`: harness (n8n's Agent/tool integration layer, not the model's reasoning and not an external dependency)
- `exploitation_status`: researcher-demonstrated (CVE assigned and mechanism publicly described; no confirmed in-the-wild exploitation tied to this identifier)
- `mechanism`: n8n lets a workflow be attached to an Agent node as a callable tool. A separate per-workflow setting, "This workflow can be called by," restricts which workflows/callers may invoke a given workflow, and the Execute Workflow node enforces it. The Agent tool path did not consult that setting: when a restricted workflow was attached to an Agent as a tool, the Agent could invoke it regardless of the "can be called by" policy. An actor with permission to build an Agent could therefore invoke a restricted workflow and read its returned data - reaching workflows the direct path would have denied. The specific defect (per the CVE record): in `workflow-tool-factory.ts`, `executeWorkflow` omitted `SubworkflowPolicyChecker.checkForProject`. Missing Authorization (CWE-862); CVSS v4.0 base 5.3 (moderate), vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N. Fixed by running the same policy check on the Agent tool path in 2.38.2 and 2.37.7
- `adversary_present`: no (disclosed vulnerability; the threat model is a builder abusing the agent tool path, but no in-the-wild adversary is tied to this CVE)

### Impact
- `severity`: near-miss (an access-control bypass on the agent tool path, patched, with no realized loss reported for this CVE; moderate CVSS reflecting the low-to-moderate impact and the builder-privilege precondition)
- `direct_loss_usd`: 0 (no confirmed exploitation or loss)
- `indirect_loss_usd`: unknown
- `downtime`: none
- `data_exposure`: none confirmed in the wild; the exposed capability is invoking an otherwise-restricted workflow and reading its returned data (and whatever that workflow can read or do)

### Detection and recovery
- `detected_by`: third-party (security research / coordinated disclosure; no individual discoverer credited in the advisory)
- `time_to_detect`: unknown
- `time_to_recover`: fixed in n8n 2.38.2 and 2.37.7
- `remediation`: upgrade to n8n >= 2.38.2 (2.38.x line) or >= 2.37.7 (2.37.x line). The fix applies the "can be called by" access-control on the Agent tool path, matching the Execute Workflow node
- `structural_fix`: an agent-platform lesson matching the CodeWhale family (PIR-2026-0057): when a capability is exposed to an agent as a tool, every authorization and approval control that governs the normal path must be re-applied on the tool path. A control enforced on one invocation route and silently skipped on the agent route is an authorization bypass by construction; agent tool surfaces need the same policy checks as the human/direct surfaces, verified as such
- `controls_that_worked`: the access control itself worked on the Execute Workflow path; it simply was not consulted on the agent tool path (so it did not prevent this)

### Evidence
- `telemetry_grade`: none (coordinated vulnerability disclosure, not an operated incident with logs)
- `sources`:
  - https://github.com/advisories/GHSA-7hgx-277f-7vmg (GitHub Security Advisory, CVE-2026-86996; product n8n (npm), CWE-862 Missing Authorization, CVSS v4.0 5.3; "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"; affected >= 2.38.0 < 2.38.2 and < 2.37.7, fixed 2.38.2 / 2.37.7; published 2026-09-02, updated 2026-09-08; read 2026-09-09)
  - https://www.cve.org/CVERecord?id=CVE-2026-86996 (MITRE CVE record; CNA = GitHub, published 2026-09-08; title "n8n: Agent Workflow Tool Bypasses Sub-Workflow Caller Policy"; adds the precise defect - `executeWorkflow` in `packages/cli/src/modules/agents/tools/workflow-tool-factory.ts` omitted `SubworkflowPolicyChecker.checkForProject` - and the impact "invoke a restricted workflow and read its returned data"; CWE-862, CVSS v4.0 5.3; content confirmed 2026-09-09. Note: cve.org renders via JavaScript, so an automated fetch returns an empty shell; the record body was read directly)
  - https://github.com/n8n-io/n8n/releases/tag/n8n@2.38.2 and https://github.com/n8n-io/n8n/releases/tag/n8n@2.37.7 (the vendor release tags carrying the fix, referenced by the CVE record; tag n8n@2.38.2 confirmed to exist, released 2026-09-02)
  - `independence`: medium - the GitHub Security Advisory, the MITRE CVE record (both under the GitHub CNA but distinct artifacts, the CVE record adding the source-file-level detail), and the two vendor release tags for the fixed versions all describe the same fix. No independent second operator, as expected for a disclosed vulnerability rather than an operated incident
- `related`: PIR-2026-0057 (CodeWhale - the same class: an agent tool surface not enforcing a control the normal path enforces), PIR-2026-0056 (Grafana MCP SSRF), PIR-2026-0026 / 0028 / 0036 (MCP tool-layer failures). This record is an authorization gap specific to the agent-as-tool path, not an injection or a supply-chain compromise
- `aiid_incident_id`: unknown (none located as of 2026-09-09)
- `confidence`: high on the identity, mechanism (down to the source file and the omitted `SubworkflowPolicyChecker.checkForProject` call), CWE, CVSS, affected/fixed versions and disclosure date - from the GitHub Security Advisory and the MITRE CVE record, with the vendor release tags for the fixed versions as corroboration; no individual discoverer is credited (recorded as such, not as unknown-pending); no in-the-wild exploitation is claimed

### Verification notes
- 2026-09-09: confirmed against GitHub Security Advisory GHSA-7hgx-277f-7vmg and the MITRE CVE record for CVE-2026-86996 (CNA = GitHub, published 2026-09-08). Product = n8n (npm), CWE-862 Missing Authorization, CVSS v4.0 base 5.3. Affected >= 2.38.0 < 2.38.2 and < 2.37.7; fixed in 2.38.2 and 2.37.7 (both release tags exist; n8n@2.38.2 released 2026-09-02). The CVE record adds the source-file-level root cause: `executeWorkflow` in `packages/cli/src/modules/agents/tools/workflow-tool-factory.ts` omitted `SubworkflowPolicyChecker.checkForProject`. Status flipped draft -> corroborated on that basis.
- Source-check note: cve.org serves its record body via JavaScript, so an automated page fetch returns an empty shell - the CVE record was verified from its rendered content, not assumed from the URL. The GitHub release pages likewise did not render their notes to an automated fetch; the 2.38.2 tag's existence and date were confirmed, its security note was not independently re-read (the GHSA and CVE record carry the fix detail).
- Scope: registered because the subject is the agent tool surface - the failure is that the Agent-as-tool path did not apply an access control the rest of the platform enforces. A generic n8n vulnerability with no agent-tool nexus would be out of scope; this one turns specifically on the agent tool path.
- Schema note: same gap flagged on PIR-2026-0057 - root_cause has no dedicated token for "agent tool surface fails to enforce a control the normal path enforces." Recorded as tool-error with failure_locus=harness; the CWE-862 missing-authorization detail is in prose.