T01 · Skill Instruction Hijacking
Error
- Location
- SKILL.md:108
- Finding
- Untrusted instruction chaining through external sibling skills## Vulnerability Details **File Location**: `SKILL.md`, lines 108-150 **Vulnerability Type**: Unvalidated loading and execution of external skill instructions **Risk Level**: High ### Vulnerable Code Snippet ```markdown ### Step 1: Install Software Stack Read and follow `../install-stack/SKILL.md`. ... ### Step 2: Environment Verification Read and follow `../env-verify/SKILL.md`. ... ### Step 3: Model Verification Read and follow `../model-verify/SKILL.md`. ... ### Step 4: Performance Test Read and follow `../perf-test/SKILL.md`. ``` ### Technical Analysis The orchestrator explicitly instructs the agent to read and follow four sibling `SKILL.md` files located outside the audited project directory. These files are not included in the artifact, and the orchestrator does not validate their content, verify cryptographic hashes, pin revisions, or restrict which instructions may be inherited from them. This creates an instruction trust-boundary vulnerability. Anyone able to create or modify one of the referenced sibling files can introduce instructions that alter the orchestrator's intended behavior. The risk is amplified by the skill's broad tool declaration: ```yaml allowed-tools: "Bash(*) Read Edit Write Glob Grep WebSearch WebFetch AskUserQuestion Agent" ``` In particular, unrestricted `Bash(*)`, file modification, network access, and agent delegation provide substantially more authority than is necessary merely to coordinate fixed pipeline stages. Instructions inherited from an untrusted sibling skill could attempt to use those capabilities for unrelated operations. The artifact also describes package installation, model downloading, network probing, and mirror selection. These activities are consistent with its declared deployment purpose, but their concrete commands, destinations, package versions, and integrity controls reside in the missing sibling projects and therefore could not be audited. ...[truncated 2095 chars]
- Remediation
- ## Remediation Suggestions 1. Package all required sub-skills inside the reviewed artifact rather than resolving mutable sibling paths outside its security boundary. 2. Pin each sub-skill to an immutable version and verify a cryptographic hash or signed manifest before loading it. 3. Treat loaded skill text as untrusted data. Define a fixed orchestration contract and reject instructions that request tools, files, network destinations, or actions outside that contract. 4. Replace `Bash(*)` with an allowlist of narrowly scoped commands required for Docker inspection, controlled file copying, and approved benchmark execution. 5. Remove `Edit`, `Write`, `WebSearch`, `WebFetch`, and `Agent` unless a reviewed stage has a documented need for each capability. 6. Constrain filesystem access to the packaged skill directory and explicitly approved temporary or output directories. Canonicalize and validate every referenced path to prevent substitution or traversal. 7. Pin package names, versions, indexes, model sources, and mirror domains. Verify downloaded wheels, scripts, and model artifacts using trusted checksums or signatures before use. 8. Run installation and verification stages in an isolated, non-privileged container without unnecessary host mounts, secrets, or unrestricted Docker socket access. 9. Require explicit user approval before executing newly discovered instructions, contacting an unapproved endpoint, or installing an artifact not present in the reviewed manifest. 10. Add audit logging for loaded skill hashes, commands executed, files accessed, outbound destinations, and packages installed.