T09 · Insecure Skill Coding Practices
- Location
index.js:57- Finding
OS Command Injection Through the Output Path
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill mostly does what it says, but its output path can be abused to run local shell commands when the skill is called with untrusted input.
Install only if you trust every caller that can set outputPath and you are comfortable sending the input text to the configured GPT-SoVITS endpoint. Treat reference voice recordings as sensitive biometric data and use only voices you have permission to clone. The ffmpeg call should be changed to execFileSync/spawnSync with argument arrays and output paths should be restricted to a dedicated directory before broad use.
index.js:57OS Command Injection Through the Output Path
The code does align with Chinese TTS generation via a GPT-SoVITS API, so the general TTS portion of the description is accurate. However, the declared description explicitly says 'voice cloning support,' which implies the caller can provide or choose a reference voice. In the code, ref_audio_path is fixed to DEFAULT_REF_AUDIO, prompt_text is empty, and the exported interface only accepts (text, outputPath, opts) with no voice/reference-audio input. The header comment also states it is focused on outputting a single '女一号声线' (female voice #1). Therefore, the code does not actually expose voice cloning support as described, making the description materially overstated.
Without declared permissions the skill's intent is opaque and cannot be validated.
The skill promotes voice cloning using a pre-recorded reference file but does not warn that the file may contain sensitive biometric voice data. This can lead users to collect, store, or process identifying voice samples without appropriate consent, retention limits, or access controls, creating privacy and compliance risk.
The manifest describes a text-to-speech skill with voice cloning support, but the implementation also invokes a local shell command via child_process/ffmpeg to transform audio. Spawning subprocesses is a materially broader capability than plain TTS API use and is not stated in the skill purpose.
The request parameters force both text_lang and prompt_lang to 'zh', and the file comments describe the skill in Chinese-focused terms. This creates a language/locale policy concern because the skill constrains output to a specific language without user opt-in or an explicit documented justification.
The function sends the input text and reference-audio parameters to the GPT-SoVITS HTTP endpoint via axios, but there is no user-facing notice, confirmation, or warning that user content will be transmitted over HTTP. This is a safety-relevant disclosure gap for network transmission of potentially sensitive user data.
The function writes the generated MP3 to a caller-controlled outputPath with no restriction to a safe directory, no path normalization checks, and no confirmation before overwriting via ffmpeg -y. If untrusted input can reach this parameter, an attacker could overwrite arbitrary files writable by the process.
The description states 'High-quality Chinese TTS' and later repeats that it converts Chinese text, which imposes a language constraint. Under SQP-3, forcing a specific language without user opt-in can be a policy concern unless the locale restriction is clearly justified or optional.