competition-web-runtime

HIGH W007: Insecure credential handling detected in skill instructions.

• Insecure credential handling detected (high risk: 1.00). The skill explicitly instructs the agent to "inspect" and "record exact ... headers, cookies, and body" and to preserve "exact requests and responses," which requires capturing and outputting sensitive secrets (tokens, cookies, API keys) verbatim.

CRITICAL E006: Malicious code pattern detected in skill scripts.

• Malicious code pattern detected (high risk: 1.00). This repository includes an explicit exploit write-up and ready-to-run code (Python and JavaScript) that forges admin cookies by reusing URL access tokens as HMAC keys, enabling privilege escalation and unauthorized access.

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

• Third-party content exposure detected (high risk: 0.70). The required workflow instructs the agent to “Inspect entry HTML, boot scripts, runtime config, and route registration” and to “Capture one real request flow end-to-end,” which at runtime typically involves fetching/reading outsider-authored web page content and request/response bodies (free text) into the LLM context.

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

• Secret detected (high risk: 1.00). I scanned the skill and reference files for literal, high-entropy values that could be usable credentials. The only candidate is the long, random-looking access token string shown inline in the cookie HMAC key reuse reference. It is not a generic placeholder (e.g., YOUR_API_KEY) and appears as a concrete token in a URL example, so it meets the definition of a high-entropy literal that could be reused as a secret. Other values in the docs are placeholders (e.g., "从URL提取的token", "已知的token"), example JSON like {"admin":true}, or configuration names — all of which I ignored per the rules.