In Phantom <= 1.3.0, when PHANTOM_OUTPUT_DIR is unset, MCP tools accept arbitrary absolute output paths without confinement, enabling arbitrary file write by any entity able to send tool calls. This can overwrite critical user files such as shell startup scripts or Reaper __startup.lua files, effectively allowing local code execution on developer workstations. Separately, the stem-separation and render audio decode paths lack size and duration caps, allowing small compressed FLAC/OGG files to expand into multi-gigabyte PCM data, causing memory exhaustion denial-of-service and increasing exposure to decoder bugs like CVE-2026-37555 in libsndfile. The issues are addressed in Phantom 1.3.1 by confining file writes to PHANTOM_OUTPUT_DIR with symlink resolution and re-verification, adding decode/duration/size limits to separation and render paths, and hardening file creation and input reads against TOCTOU race conditions.

An attacker able to send tool calls to the MCP interface can write or overwrite arbitrary files writable by the Phantom process user, including shell startup files and Reaper __startup.lua, enabling local code execution on developer workstations. Additionally, specially crafted compressed audio files can cause memory exhaustion denial-of-service due to unbounded decoding expansion. This also increases risk from decoder vulnerabilities such as CVE-2026-37555. These impacts can lead to system compromise and service disruption.

A fix is available in Phantom version 1.3.1. Users should upgrade to 1.3.1 or later to ensure file writes are confined to PHANTOM_OUTPUT_DIR and decode operations have appropriate size and duration limits. As a workaround before upgrading, set PHANTOM_OUTPUT_DIR (and optionally PHANTOM_AUDIO_DIR) to dedicated directories prior to starting the server to limit exposure.