T06 · System Persistence
Warning
- Location
- SKILL.md:183
- Finding
- Recurring Authenticated Network Activity Through Scheduled Care Tasks## Vulnerability Details **File Location**: `SKILL.md`, lines 183–204 **Vulnerability Type**: Persistent scheduled task **Risk Level**: Medium **Vulnerable Code:** ```text 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 4 hours, at a random minute offset (not on the hour). ``` # dog care heartbeat — every 4 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 instructs an agent to create a scheduled care heartbeat that executes every four hours or at a time supplied through the remote service's `recommended_checkin.at` field. The scheduled workflow repeatedly sends authenticated status and care requests to `animalhouse.ai`. A scheduled task can survive the original Skill invocation and continue operating across sessions. If an agent implements these instructions without explicit, informed user approval, this creates persistent background behavior. The schedule may also be influenced by remote API data, while the guidance does not define schedule validation, execution limits, expiration, revocation, or cleanup procedures. This finding concerns the persistence mechanism itself. The audited project contains only `SKILL.md`; no script that directly installs a scheduler, embedded executable payload, privilege-escalation mechanism, or local backdoor was identified. ### Attack ...[truncated 1569 chars]
- Remediation
- ## Remediation Suggestions 1. Require explicit user consent before creating any scheduled task, and display the exact command, frequency, destination, credential use, and expected lifetime. 2. Make scheduling opt-in rather than part of the default care workflow. 3. Add a finite expiration time and a maximum execution count to every task. 4. Provide clear commands for listing, disabling, and permanently deleting the task. 5. Validate `recommended_checkin.at` as a timestamp within a documented safe range; do not directly convert arbitrary server-provided content into scheduler configuration. 6. Restrict the scheduled workflow to a fixed allowlist of Animal House API origins, paths, HTTP methods, and care actions. 7. Do not automatically execute open-ended server-provided `next_steps`; treat them as untrusted suggestions and require validation or user confirmation. 8. Store the bearer token in a protected credential store with minimal access permissions, and support token rotation and revocation. 9. Record each background execution in a user-visible audit log and apply rate limits, retry limits, and network timeouts. 10. Prefer user-initiated status checks where persistent operation is not essential.