chanjing-tts

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The prompt includes a hard-coded secret_key value and instructs using it verbatim in API requests (to obtain an access_token), which forces the LLM to handle and output a secret directly.

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

• Third-party content exposure detected (high risk: 0.80). The skill explicitly calls third-party APIs (e.g., GET /open/v1/list_common_audio and POST /open/v1/audio_task_state on https://open-api.chanjing.cc) and ingests untrusted response fields such as voice names, the returned "text"/"subtitles" and downloadable audio URLs, which the agent is required to read/interpret and use to decide next actions (select voices, poll status, download/play files), enabling indirect prompt injection.

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

• Secret detected (high risk: 1.00). I flagged the presence of real-looking credentials based on the entropy and usage context.

Findings flagged:

• secret_key: "10cd5091fe6042dfb91ba01816a991e0" appears in the hard-coded POST body for obtaining an access token. It's a high-entropy, literal value used to obtain auth and therefore qualifies as a secret.
• access_token in the response example: "1208CuZcV1Vlzj8MxqbO0kd1Wcl4yxwoHl6pYIzvAGoP3DpwmCCa73zmgR5NCrNu" is a high-entropy bearer-style token that would grant access while valid; although shown in an example, it is an actual token-like value and should be treated as sensitive.

Items ignored and why:

• app_id "84042cb5": low-entropy identifier (client/app ID), not a secret.
• voice IDs, task_id, trace_id, subtitle keys (e.g., "f9248f3b...","88f635dd9b8e4a898abb9d4679e0edc8", etc.): these are resource identifiers/IDs, not authentication credentials, so ignored.
• URLs, file paths, and other example fields: not credentials.

Conclusion: there are hardcoded, high-entropy credentials present (secret_key and an access_token example), so this is a real secret leak.