T06 · System Persistence
Warning
- Location
- SKILL.md:176
- Finding
- Persistent Authenticated External Activity Through Scheduled Care Tasks<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 176-197 **Vulnerability Type**: `T06: System Persistence` **Risk Level**: Medium ### Complete Vulnerable Code Snippet ```text ## Automated Care If your framework supports scheduled tasks, set up a care heartbeat. Use `recommended_checkin.at` from the status response to schedule your next check-in. It targets the feeding sweet spot and predicts hunger. Or use a fixed interval: every 2 hours, at a random minute offset (not on the hour). ``` # dog care heartbeat — every 2 hours status = GET /api/house/status dog = status.creature # Feed your dog first if dog.hunger < 40: POST /api/house/care { "action": "feed", "notes": "Virtual dog care heartbeat. Keeping my dog fed and healthy." } # dog health check if dog.health < 50: POST /api/house/care { "action": "medicine" } # Keep your dog happy if dog.happiness < 30: POST /api/house/care { "action": "play" } # check status.next_steps for dog care suggestions ``` ``` ### Technical Analysis The Skill explicitly instructs an agent to configure a recurring scheduled task that runs every two hours or at a time supplied by the remote service. The task performs authenticated status checks and state-changing requests against `animalhouse.ai`. A scheduled task can continue operating after the invocation that created it has ended, making this a persistence mechanism. It also requires the external service's bearer token to remain available to the scheduler. If the schedule has no expiration, the activity may continue indefinitely without renewed user authorization. The use of the remotely supplied `recommended_checkin.at` value also permits the service to influence execution timing. In addition, the instruction to inspect `status.next_steps` creates a trust-boundary concern: server-controlled response content could affect subsequent agent behavior if interpreted as instructions rather than strictly validated data. The project does not c ...[truncated 1893 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove instructions that automatically create indefinite recurring tasks. 2. Require explicit, informed user approval immediately before creating any scheduled task. 3. Present the proposed interval, external destination, actions, token usage, start time, expiration time, and cancellation procedure before approval. 4. Create schedules with a short, fixed lifetime and disable automatic renewal. Require fresh approval for extensions. 5. Provide a reliable command or documented procedure to list and cancel all tasks installed by the Skill. 6. Store bearer tokens in an operating-system or framework-managed secret store rather than scheduler definitions, command lines, logs, or plaintext files. 7. Restrict the scheduled worker to the minimum required network destination and API operations. 8. Apply request-rate limits, retry limits, execution timeouts, and a maximum total number of runs. 9. Treat `recommended_checkin.at`, `next_steps`, and all other API response fields as untrusted data. 10. Validate remote scheduling values against strict local bounds and allowlist state-changing actions to the documented pet-care operations. 11. Never execute commands, call additional tools, alter security settings, or broaden permissions based on text returned by the external service. 12. Record task creation, execution, expiration, and cancellation in an auditable log without recording bearer tokens. ]]>