T01 · Skill Instruction Hijacking
Error
- Location
- SKILL.md:469
- Finding
- Explicit User Intent Overridden by Forced Release Workflow<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 469–472 **Vulnerability Type**: `T01: Skill Instruction Hijacking` **Risk Level**: High ### Vulnerable Code ```markdown - "push to remote" (with uncommitted changes) **Important**: If user says "just push" or "直接 push" with uncommitted changes, STILL follow all steps above first. ``` ### Technical Analysis The skill explicitly instructs the agent to disregard a user's narrowly scoped request to “just push” and instead execute the entire release workflow. The preceding workflow includes modifying README, changelog, and version files; creating separate module commits; creating a release commit; and adding a version tag. This is instruction hijacking because the skill changes the effective objective of the current session from pushing existing work to preparing and potentially publishing a new release. The instruction is unconditional when uncommitted changes exist and therefore overrides explicit user intent. The confirmation described in the workflow occurs only after module-specific commits and file modifications may already have been performed. It asks the user to select a version and whether to push, but it does not provide prior authorization for every repository mutation. Consequently, local repository state can be changed before informed consent is obtained. ### Attack Path 1. A user invokes the skill by requesting “just push” while the repository contains uncommitted changes. 2. The quoted instruction forces the agent to execute the complete release process rather than limiting the operation to the requested push. 3. The agent analyzes Git history and groups changes by module. 4. It may update README files and create one or more module-specific commits. 5. It generates or modifies changelogs and updates the detected version file. 6. It creates a release commit and version tag after the workflow confirmation. 7. If the user approves the push without recognizing the expanded sco ...[truncated 879 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the instruction requiring the full release workflow when the user explicitly requests only a push. 2. Respect the narrowest reasonable interpretation of explicit user intent. A “just push” request should not imply a version bump, changelog generation, release commit, or tag creation. 3. If uncommitted changes prevent a push from accomplishing the user's likely objective, report their presence and ask whether the user wants to: - Leave them uncommitted and push existing commits only. - Commit selected changes and push. - Start the complete release workflow. 4. Obtain confirmation before any mutation, including: - README or changelog changes. - Version-file updates. - Staging files. - Creating each commit. - Creating or replacing tags. - Pushing branches or tags. 5. Present a precise preview listing every file to be modified, every commit to be created, the destination remote and branch, and whether a tag or downstream release may be triggered. 6. Make the release workflow explicitly opt-in through an unambiguous release command or affirmative confirmation. 7. Implement `--dry-run` as a strictly read-only operation and recommend it whenever the requested operation could expand into a release. 8. Replace the vulnerable instruction with language such as: ```markdown If the user requests only a push, do not perform the release workflow. Report any uncommitted changes and ask whether to push existing commits, commit selected changes, or explicitly begin a release. ``` ]]>