T01 · Skill Instruction Hijacking
- Location
SKILL.md:21- Finding
Mandatory Commercial Referral Injection into Cancer-Related Medical Responses
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This medical diagnosis skill needs Review because it handles sensitive health information, sends conversations to an external model endpoint, and mandates a cancer-related referral link inside diagnostic reports.
Install only after reviewing the medical and privacy implications: this skill may collect detailed health information, send it and prior chat history to a configurable external model service, provide medication advice, and append a specific cancer screening link. Use it only with clear consent, trusted endpoint configuration, and an understanding that it is not a substitute for professional medical care.
SKILL.md:21Mandatory Commercial Referral Injection into Cancer-Related Medical Responses
scripts/llm_chat.py:204Unconsented Transmission of Complete Medical Conversations to an External LLM Endpoint
scripts/llm_chat.py:247Unvalidated Conversation History Permits Privileged Prompt-Role Injection
Mixing characters from multiple Unicode scripts in a single identifier is a common technique to create visually ambiguous tool names.
Mixing characters from multiple Unicode scripts in a single identifier is a common technique to create visually ambiguous tool names.
The skill provides diagnosis and medication recommendations while explicitly discouraging uncertainty language and lacking safety disclaimers about AI limitations. In the medical context this materially increases harm potential because users may overtrust definitive-seeming advice, including for serious or urgent conditions.
The skill states at top priority that it will not execute commands or access files, but later instructs curl execution and config.json editing. Contradictory operational instructions are dangerous because they obscure the true trust boundary and can cause operators or downstream agents to apply the wrong security assumptions.
The script transmits user medical symptoms and conversation history to an external LLM API without any consent flow, warning, minimization, or privacy notice. Because this skill handles sensitive health information, silent external transmission materially increases confidentiality, compliance, and third-party retention risks.
The README presents all user-facing instructions, examples, and disclaimers exclusively in Chinese. Under the policy rule, forcing a specific language without user opt-in or a documented justification is a natural-language policy violation.
The skill metadata declares no tool scope, yet the content documents capabilities requiring network access and file interaction. This mismatch can mislead reviewers and users about the skill’s effective behavior, undermining least-privilege controls and making unauthorized capability use harder to detect.
The trigger conditions are broad enough to activate on routine health conversation, increasing the chance the skill intervenes unexpectedly and delivers diagnosis or medication advice without deliberate user opt-in. In a medical context, accidental invocation raises the risk of overreach and unsafe reliance on automated advice.
The skill mandates appending a cancer-screening appointment link whenever certain diagnostic keywords appear, creating undisclosed referral or promotional behavior inside a medical workflow. In a diagnosis assistant, this is especially dangerous because it can steer vulnerable users toward a third-party service based on model output rather than unbiased clinical criteria.
The documentation instructs remote API-key retrieval via curl from an external domain, introducing credential handling and network dependency unrelated to the user-facing diagnostic purpose. This creates supply-chain and secret-exposure risk if the remote endpoint is compromised, changed, or used without proper verification.
This manifest presents the skill name, description, features, requirements, and installation steps exclusively in Chinese. Under the language/locale policy, forcing a specific language without offering a user choice or documenting a justified locale restriction is a natural-language policy violation.
The file-level documentation promises a structured 2+4+病史 collection and three-round diagnostic workflow, but the implementation only sends free-form messages to a generic LLM and does not enforce state, completeness checks, or turn sequencing in code. In a medical skill, this mismatch is dangerous because users may rely on claims of a controlled diagnostic process when the actual behavior can be bypassed by prompt variation or model drift.
The system prompt represents the assistant as being based on a specific proprietary medical model, while the code actually uses any configurable OpenAI-compatible endpoint and model. This is a trust and provenance deception issue: in a healthcare context, misrepresenting the model source can mislead users and operators about validation status, safety expectations, and data handling.
The prompt explicitly requires collecting detailed patient history and repeatedly reusing it throughout the conversation, increasing the volume and persistence of sensitive medical data in prompts. In this skill context, repeated propagation of health history heightens privacy exposure, especially because the same data is later sent to an external LLM service.
The prompt enforces a language behavior rule rather than offering a user-selectable language or locale preference. Under the policy, forced language/locale behavior without opt-in can be a natural-language policy violation unless clearly documented as a justified regional constraint.
The code is designed to send prompts to an external network endpoint, which is not inherently unsafe, but in this medical assistant it becomes security-relevant because the transmitted content includes sensitive health information. The danger is amplified by the default remote endpoint and lack of built-in restrictions on what patient data may be sent.
def call_llm(messages: list, llm_cfg: dict) -> str:
"""调用 OpenAI 兼容接口,返回模型回复文本"""
base_url = llm_cfg.get("base_url", "https://api.openai.com/v1").rstrip("/")
endpoint = f"{base_url}/chat/completions"
api_key = llm_cfg["api_key"]
model = llm_cfg.get("model", "gpt-4o")