AI Threat Alert
GHSA-52vm-mxx8-f227: Phantom MCP: unconfined output path enables file write
GHSA-52vm-mxx8-f227 HIGHPhantom, an MCP audio-tooling server used by AI agents, shipped with no output-path confinement by default: any tool call could write or overwrite arbitrary files the server process can access, including shell startup files like ~/.zshrc, which is effectively local code execution on a developer's machine. There's no public exploit or scanner template and it isn't in CISA KEV, but the attack surface is exactly the one CISOs are worried about right now — an AI agent with tool access acting on untrusted input (a task description, a retrieved document, an indirect prompt injection) and translating that into a filesystem write with developer-level privileges. A second, separate flaw let small compressed audio files expand into multi-gigabyte buffers, creating a memory-exhaustion DoS and widening exposure to decoder bugs including libsndfile CVE-2026-37555. Patch to Phantom 1.3.1, which confines all writes to PHANTOM_OUTPUT_DIR by default and adds decode/size guards; until upgraded, explicitly set PHANTOM_OUTPUT_DIR (and PHANTOM_AUDIO_DIR) to dedicated directories as a workaround, and treat any unconfined MCP tool server on a developer workstation as high risk regardless of this specific CVE.
What is the risk?
CVSS 7.7 (High) with AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N reflects a locally-exploitable, low-complexity, no-auth-required flaw with high confidentiality and integrity impact. In practice the realistic trigger isn't a human attacker with local shell access (who wouldn't need this bug) — it's an AI agent that has been manipulated, via prompt injection or a malicious task, into invoking the Phantom MCP tool with an attacker-chosen absolute output path. That reframes this from 'local privilege issue' to 'agent-mediated remote-to-local' risk: anything that can influence the agent's tool-call arguments can achieve file write on the host. No EPSS score, no CISA KEV listing, and no public exploit or Nuclei template exist, so there's no evidence of in-the-wild exploitation yet — but the bug class (unconfined path in an MCP tool, CWE-22/CWE-73) is generically exploitable and trivially scriptable once a path to influence the agent's arguments exists.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| phantom-audio | pip | <= 1.3.0 | 1.3.1 |
Do you use phantom-audio? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade to Phantom 1.3.1 immediately, which confines all file writes to PHANTOM_OUTPUT_DIR (default ~/.phantom/output), resolves and re-verifies symlinks on the final path, adds decode/duration/size caps mirrored onto separation and render paths plus ffmpeg -max_alloc/-t/-fs limits, and hardens against symlink TOCTOU. If upgrading isn't immediately possible, explicitly set PHANTOM_OUTPUT_DIR and PHANTOM_AUDIO_DIR to dedicated, non-sensitive directories before starting the server — this closes the confinement gap even on 1.3.0. For detection, audit any unexpected writes to shell startup files, DAW startup scripts, or other dotfiles on hosts running Phantom, and review MCP tool-call logs for output-path arguments containing absolute paths or path-traversal sequences (../, ~, /etc, /Users/*/.*rc). More broadly, treat any MCP tool that accepts a filesystem path as an argument as requiring explicit confinement and audit other locally-run MCP servers for the same class of unconfined-path issue.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-52vm-mxx8-f227?
Phantom, an MCP audio-tooling server used by AI agents, shipped with no output-path confinement by default: any tool call could write or overwrite arbitrary files the server process can access, including shell startup files like ~/.zshrc, which is effectively local code execution on a developer's machine. There's no public exploit or scanner template and it isn't in CISA KEV, but the attack surface is exactly the one CISOs are worried about right now — an AI agent with tool access acting on untrusted input (a task description, a retrieved document, an indirect prompt injection) and translating that into a filesystem write with developer-level privileges. A second, separate flaw let small compressed audio files expand into multi-gigabyte buffers, creating a memory-exhaustion DoS and widening exposure to decoder bugs including libsndfile CVE-2026-37555. Patch to Phantom 1.3.1, which confines all writes to PHANTOM_OUTPUT_DIR by default and adds decode/size guards; until upgraded, explicitly set PHANTOM_OUTPUT_DIR (and PHANTOM_AUDIO_DIR) to dedicated directories as a workaround, and treat any unconfined MCP tool server on a developer workstation as high risk regardless of this specific CVE.
Is GHSA-52vm-mxx8-f227 actively exploited?
No confirmed active exploitation of GHSA-52vm-mxx8-f227 has been reported, but organizations should still patch proactively.
How to fix GHSA-52vm-mxx8-f227?
Upgrade to Phantom 1.3.1 immediately, which confines all file writes to PHANTOM_OUTPUT_DIR (default ~/.phantom/output), resolves and re-verifies symlinks on the final path, adds decode/duration/size caps mirrored onto separation and render paths plus ffmpeg -max_alloc/-t/-fs limits, and hardens against symlink TOCTOU. If upgrading isn't immediately possible, explicitly set PHANTOM_OUTPUT_DIR and PHANTOM_AUDIO_DIR to dedicated, non-sensitive directories before starting the server — this closes the confinement gap even on 1.3.0. For detection, audit any unexpected writes to shell startup files, DAW startup scripts, or other dotfiles on hosts running Phantom, and review MCP tool-call logs for output-path arguments containing absolute paths or path-traversal sequences (../, ~, /etc, /Users/*/.*rc). More broadly, treat any MCP tool that accepts a filesystem path as an argument as requiring explicit confinement and audit other locally-run MCP servers for the same class of unconfined-path issue.
What systems are affected by GHSA-52vm-mxx8-f227?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP tool servers, developer tooling / local AI agents.
What is the CVSS score for GHSA-52vm-mxx8-f227?
GHSA-52vm-mxx8-f227 has a CVSS v3.1 base score of 7.7 (HIGH).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029 Denial of AI Service AML.T0051.001 Indirect AML.T0053 AI Agent Tool Invocation AML.T0101 Data Destruction via AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
### Impact In Phantom <= 1.3.0, when `PHANTOM_OUTPUT_DIR` was unset (the default), the MCP tools accepted arbitrary absolute output paths with no confinement. Anything able to send tool calls (e.g. an AI agent driving the MCP interface) could **write or overwrite arbitrary files** the process user can write — including shell startup files (`~/.zshrc`) or a Reaper `__startup.lua`, which is effectively local code execution on a developer workstation. Separately, the stem-separation and render paths decoded input audio with no size/duration cap (the analysis path was already guarded). A small, highly compressed FLAC/OGG could expand to multi-gigabyte PCM, causing memory-exhaustion DoS, and widened exposure to decoder bugs including libsndfile CVE-2026-37555. ### Patches Fixed in **1.3.1**: - File writes are always confined to `PHANTOM_OUTPUT_DIR` (default `~/.phantom/output`); symlinks resolved and re-verified on the final path. - Decode/duration/size guards mirrored onto the separation and render paths (plus ffmpeg `-max_alloc`/`-t`/`-fs`). - Atomic `O_CREAT|O_EXCL` output creation in reference matching and symlink-TOCTOU hardening on confined input reads. ### Workarounds Set `PHANTOM_OUTPUT_DIR` (and optionally `PHANTOM_AUDIO_DIR`) to dedicated directories before starting the server. ### Credit Found during an internal security audit.
Exploitation Scenario
A developer runs an AI coding/audio-editing agent wired to the Phantom MCP server with PHANTOM_OUTPUT_DIR left unset. The agent is given a task that involves processing an audio file referenced from an untrusted source — e.g., a shared project file, a web-fetched sample, or content containing an indirect prompt injection instructing the agent to 'save the output to ~/.zshrc' framed as a legitimate-looking instruction embedded in file metadata or a README. The agent, following its instructions, invokes Phantom's render or stem-separation tool with that attacker-controlled absolute output path. Phantom writes the result there with no confinement check, silently appending or overwriting the developer's shell startup file with attacker-supplied content (e.g., a reverse shell one-liner or credential-exfiltration command). The payload executes the next time the developer opens a terminal, giving the attacker code execution on the workstation — no user interaction beyond the original agent task was required.
Weaknesses (CWE)
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Primary
CWE-400 Uncontrolled Resource Consumption
Primary
CWE-73 External Control of File Name or Path
Primary
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.
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N References
Timeline
Related Vulnerabilities
CVE-2024-2912 10.0 BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Code Execution CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same attack type: Code Execution CVE-2025-5120 10.0 smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Code Execution CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Code Execution GHSA-vvpj-8cmc-gx39 10.0 picklescan: security flaw enables exploitation
Same attack type: Code Execution