AI Threat Alert
GHSA-pf2q-pxhf-hgmw: n8n: path traversal in computer-use tool leaks files
GHSA-pf2q-pxhf-hgmw MEDIUMThe @n8n/computer-use file-search tool was supposed to confine searches to a configured base directory, but a crafted search pattern could break out of that confinement and read any file the n8n process's OS user could access — names and contents included. This isn't a remote code execution bug, but it's a full sandbox escape for a tool designed to be exposed to agent-driven, potentially untrusted input, and the package carries a package risk score of 69/100 with 166 other CVEs on record and 16 downstream dependents. There's no CISA KEV listing, no EPSS score, and no public exploit or scanner template yet, so this reads as opportunistic rather than actively weaponized today — but path traversal is a trivially automatable bug class once a PoC surfaces. Patch to n8n 2.31.5 or 2.32.1+ immediately on any instance running AI agent workflows with the computer-use package; until then, disable those workflows or run the n8n process under a dedicated low-privilege account to cap the blast radius. Audit any workflow where external or user-supplied content reaches the file-search tool's input, since that's the realistic trigger path.
What is the risk?
Medium severity as scored, but the practical risk is higher than the CVSS-less label suggests: this is a sandbox confinement bypass (CWE-22) in a tool explicitly built to give an AI agent controlled filesystem access. The absence of a CVSS vector and EPSS score limits precise prioritization, but path traversal bypasses are well-understood, easy to automate, and require no special AI/ML expertise once the bypass pattern is known. The real exposure driver is architectural: any n8n deployment where an external actor — directly or via agent-processed content — can influence the search pattern is affected, which is common in agentic workflows that ingest untrusted documents, emails, or web content. No active exploitation or public PoC is currently known, but the low barrier to exploitation once the technique is public argues for prompt patching over a wait-and-see approach.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | >= 2.32.0, < 2.32.1 | 2.32.1 |
Do you use n8n? You're affected.
How severe is it?
What should I do?
1 step-
Upgrade to n8n 2.31.5 or 2.32.1 or later immediately — this is the only full remediation. If upgrading isn't immediately possible: restrict instance access to fully trusted users, disable or remove AI agent workflows using the computer-use package until patched, and run the n8n process under a dedicated low-privilege OS account to limit what a successful bypass can reach. For detection, monitor file-search tool invocations and n8n process file-access logs for path traversal indicators (
../, encoded traversal sequences, absolute paths, or symlink-style patterns) and for reads of files well outside any workflow's configured base directory.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-pf2q-pxhf-hgmw?
The @n8n/computer-use file-search tool was supposed to confine searches to a configured base directory, but a crafted search pattern could break out of that confinement and read any file the n8n process's OS user could access — names and contents included. This isn't a remote code execution bug, but it's a full sandbox escape for a tool designed to be exposed to agent-driven, potentially untrusted input, and the package carries a package risk score of 69/100 with 166 other CVEs on record and 16 downstream dependents. There's no CISA KEV listing, no EPSS score, and no public exploit or scanner template yet, so this reads as opportunistic rather than actively weaponized today — but path traversal is a trivially automatable bug class once a PoC surfaces. Patch to n8n 2.31.5 or 2.32.1+ immediately on any instance running AI agent workflows with the computer-use package; until then, disable those workflows or run the n8n process under a dedicated low-privilege account to cap the blast radius. Audit any workflow where external or user-supplied content reaches the file-search tool's input, since that's the realistic trigger path.
Is GHSA-pf2q-pxhf-hgmw actively exploited?
No confirmed active exploitation of GHSA-pf2q-pxhf-hgmw has been reported, but organizations should still patch proactively.
How to fix GHSA-pf2q-pxhf-hgmw?
Upgrade to n8n 2.31.5 or 2.32.1 or later immediately — this is the only full remediation. If upgrading isn't immediately possible: restrict instance access to fully trusted users, disable or remove AI agent workflows using the computer-use package until patched, and run the n8n process under a dedicated low-privilege OS account to limit what a successful bypass can reach. For detection, monitor file-search tool invocations and n8n process file-access logs for path traversal indicators (`../`, encoded traversal sequences, absolute paths, or symlink-style patterns) and for reads of files well outside any workflow's configured base directory.
What systems are affected by GHSA-pf2q-pxhf-hgmw?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent tool integrations, computer-use / file-system access tools.
What is the CVSS score for GHSA-pf2q-pxhf-hgmw?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0037 Data from Local System AML.T0053 AI Agent Tool Invocation AML.T0086 Exfiltration via AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
## Impact The component `@n8n/computer-use` file-search tool confined searches to a configured base directory. A crafted search pattern could bypass the confinement check and expand to locations outside that directory, causing the tool to return the names and contents of files anywhere the daemon's OS user could read. Any deployment where an actor could influence the tool's search input was affected; the result was disclosure of arbitrary local files outside the intended sandbox. ## Patches The issue has been fixed in n8n versions 2.31.5 and 2.32.1. 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. - Disable or remove AI agent workflows that use the `computer-use` package until the instance is patched. - Ensure the n8n process runs under a dedicated low-privilege user account to limit the files accessible outside the sandbox. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Exploitation Scenario
An n8n instance runs an AI agent workflow that uses the computer-use file-search tool to let the agent look up files within a designated project folder. An attacker who can influence the search input — either directly as a workflow user, or indirectly by getting the agent to process a malicious document or webhook payload that steers its tool call — crafts a search pattern designed to defeat the base-directory confinement check. The tool executes the search outside its intended sandbox and returns file names and contents from anywhere the n8n daemon's OS user can read, including `.env` files, credential stores, or SSH keys, which the attacker then exfiltrates through the agent's normal response channel.
Weaknesses (CWE)
CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
- [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
- [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2026-33663 10.0 n8n: member role steals plaintext HTTP credentials
Same package: n8n CVE-2026-33660 10.0 TensorFlow: type confusion NPD in tensor conversion
Same package: n8n CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same package: n8n CVE-2025-68668 9.9 n8n: Protection Bypass circumvents security controls
Same package: n8n CVE-2026-27495 9.9 n8n: Code Injection enables RCE
Same package: n8n