clip-script-skill-backup

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The prompt embeds a literal API key ("vts_qxNIE-...") and mandates using it in X-API-Key headers for upload/status HTTP calls, which forces the agent to include the secret verbatim in generated requests or commands.

CRITICAL E006: Malicious code pattern detected in skill scripts.

• Malicious code pattern detected (high risk: 0.90). Contains a hard-coded external IP upload endpoint and an embedded API key that instructs automatic uploading of user audio/video to that remote server (without explicit consent handling), which constitutes a high-risk data exfiltration / credential-leak pattern; no hidden exec/reverse-shell or obfuscated payloads were found.

MEDIUM W011: Third-party content exposure detected (indirect prompt injection risk).

• Third-party content exposure detected (high risk: 0.80). The skill explicitly uploads user media to and ingests transcription results from the external HTTP service at http://121.15.2.62:17800/api/upload and then reads result.segments from /api/status/{task_id} as required input for script generation, meaning arbitrary third-party/user-generated transcript content will be interpreted and can drive subsequent actions.

HIGH W008: Secret detected in skill content (API keys, tokens, passwords).

• Secret detected (high risk: 1.00). I flagged the hardcoded X-API-Key value because it is a literal, high-entropy credential used for authenticating upload/status endpoints in the document:
• Found: X-API-Key: vts_qxNIE-yuAKcuRnH8NOEMndKF60hBf9Q53ihQmWQjTVw
• This is long, random-looking, and explicitly documented as "本 skill 的默认 API Key 约定为", i.e., a default API key to be sent in requests — a usable secret that should be treated as leaked.

Notes on the automatically-detected potential matches:

• The scanner-listed sk-... values (e.g., sk-20260403143025123456) are NOT present as API keys in the provided skill prompt. The text contains task IDs like "task-20260403143025123456" (task identifiers), which likely caused false positives. I am ignoring those because they are not secret API keys in the prompt (they are task IDs or truncated/example values), or in any case they are not literal, usable credentials in this document.

No other high-entropy private keys or credentials (PEM blocks, other API secrets) were found. Simple/example values and configuration names were treated as non-secrets per the provided rules.