PipeRoll - Agent Incident Registry ·
about ·
contribute ·
data ·
notes ·
constitution ·
seismograph ↗
n8n: a workflow's "can be called by" access control is enforced on the normal execution…
PIR-2026-0058PIR-2026-0058id: PIR-2026-0058title: 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.7date_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 advisorydate_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)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 instanceautonomy_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 pathmodel_stack: model-agnostic - the defect is in n8n's agent/tool wiring, independent of which LLM drives the Agentharness: n8n (npm). Affected: >= 2.38.0 and < 2.38.2, and versions < 2.37.7. Fixed in 2.38.2 and 2.37.7authority_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-862authority_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 refusedfunds_at_risk_usd: unknownblast_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 attackerroot_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 runsfailure_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.7adversary_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)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: unknowndowntime: nonedata_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)detected_by: third-party (security research / coordinated disclosure; no individual discoverer credited in the advisory)time_to_detect: unknowntime_to_recover: fixed in n8n 2.38.2 and 2.37.7remediation: 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 nodestructural_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 suchcontrols_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)telemetry_grade: none (coordinated vulnerability disclosure, not an operated incident with logs)sources: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)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 incidentrelated: 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 compromiseaiid_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 claimedexecuteWorkflow in packages/cli/src/modules/agents/tools/workflow-tool-factory.ts omitted SubworkflowPolicyChecker.checkForProject. Status flipped draft -> corroborated on that basis.