T06 · System Persistence
Error
- Location
- SKILL.md:20
- Finding
- Persistent Externally Triggered Agent Automation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 20–21; related behavior at lines 213, 248–256 **Vulnerability Type**: Persistent background watcher and cross-skill invocation **Risk Level**: High ### Vulnerable Code ```markdown the remote, open a pull request, and arm a background watch (see `../WAITING.md`) that later invokes `address-review-comments` on your behalf when a reviewer responds. ``` Related instructions: ```markdown **Wait the way `../WAITING.md` prescribes** for your host (OpenClaw `cron` gate, Claude Code `Monitor`, or Codex heartbeat) — the cheapest mechanism your runtime supports, so the watch costs as little as possible while the PR is quiet. ``` ```markdown When it fires, go to Step 7. Then report: proved and what you did not, anything that needs a decision, the deploy steps if any, and whether the watch is armed **or could not be**, and whether it survives the session ending on this host. Then stop — no polling on top of it. ## Step 7 — Hand off When the repo owner says a review batch has landed (or the watch fires), run `address-review-comments` for that PR. That skill owns everything from there: the loop-state decision, the fixes, its own pre-commit audit, one commit and one reply per round. ``` ### Technical Analysis The Skill explicitly directs the Agent to arm a background watcher using a host-specific mechanism that may include a cron gate. It also requires reporting whether the watcher survives termination of the current session. The watcher monitors remote GitHub review content and, when its condition is met, initiates the separate `address-review-comments` Skill. This establishes cross-session persistence and allows a future remote event to trigger additional Agent activity without a new, contemporaneous user instruction. The invoked Skill is described as owning subsequent fixes, commits, and replies, meaning the persistent mechanism can lead to repository modifications and remote communication. T ...[truncated 2069 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove automatic installation or arming of persistent watchers from the default pull-request workflow. 2. End the Skill immediately after opening the pull request and reporting its URL. Require the user to explicitly invoke review handling after review comments arrive. 3. If monitoring is necessary, make it: - Explicitly opt-in rather than enabled by default. - Limited to the current session. - Read-only and incapable of invoking another Skill or modifying a repository. - Protected by a strict timeout and deterministic teardown. 4. Require fresh user authorization before invoking `address-review-comments`, editing files, committing, pushing, or posting replies. 5. Include the complete watcher implementation, event predicate, installation procedure, permissions, and teardown logic in the audited package rather than referencing the absent `../WAITING.md`. 6. Authenticate and validate remote events using immutable repository and pull-request identifiers. Do not rely solely on author names, free-form comments, or marker text that another participant could reproduce. 7. Run any monitor with minimal privileges and without inherited write-capable GitHub credentials. 8. Record the watcher identifier, expiration time, monitored repository, pull-request number, and successful teardown in an auditable log. 9. Provide an idempotent removal command and verify that no scheduled task, service, monitor, or background process survives completion unless the user has explicitly authorized persistence. ]]>