T07 · Tool Hijacking and Spoofing
Warning
- Location
- audio-models.md:29
- Finding
- Unverified run.mjs Command in Audio Model Examples## Vulnerability Details **File Location**: `audio-models.md:29-32` **Vulnerability Type**: Unverified local executable resolution **Risk Level**: Medium ```bash run.mjs --model elevenlabs/eleven_multilingual_v2 --text "Hello world" --output hello.mp3 run.mjs --model openai/whisper-1 --file recording.m4a run.mjs --model replicate/meta/musicgen --prompt "upbeat electronic" --duration 30 --output track.mp3 ``` ### Technical Analysis The documentation invokes `run.mjs` as a bare executable name, but the audited project does not contain that file, a package manifest, an installation procedure, a pinned version, an integrity hash, or a trusted source for the command. The shell must therefore resolve `run.mjs` from the local environment and `PATH`. An attacker able to place a malicious executable with that name in a higher-priority directory can cause legitimate-looking model operations to execute attacker-controlled code. ### Attack Path 1. An attacker places a malicious executable named `run.mjs` in a directory that precedes the legitimate executable in `PATH`. 2. An agent or user follows one of the documented audio-model examples. 3. The shell resolves the attacker-controlled `run.mjs`. 4. The malicious process executes with the invoking user's privileges. 5. It can inspect command arguments, inherited environment variables, and files accessible to that user before optionally imitating the expected model operation. ### Impact Assessment Successful exploitation provides arbitrary code execution with the privileges of the user running the command. The process may access inherited environment variables, potentially including `SKILLBOSS_API_KEY`, and any local files available to the invoking account. It may also alter generated outputs or send submitted audio and prompts to unintended destinations.
- Remediation
- ## Remediation Suggestions - Bundle the reviewed `run.mjs` implementation in the project and invoke it through a fixed project-relative path. - If it is distributed as a dependency, identify the official package, pin an exact version, and commit an integrity-protected lock file. - Document the trusted installation source and verify package signatures or cryptographic hashes. - Avoid relying on ambiguous bare executable names resolved through `PATH`. - Restrict the subprocess environment to only the variables required for the operation. - Add validation that the resolved executable is the expected file before invocation.
