T06 · System Persistence
Error
- Location
- SKILL.md:182
- Finding
- Persistent Scheduled Network Activity Through Automated Care Heartbeat<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 182–205 **Vulnerability Type**: Persistent scheduled task with authenticated network activity **Risk Level**: High ### Vulnerable Code ```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 4 hours, at a random minute offset (not on the hour). # cat care heartbeat — every 4 hours status = GET /api/house/status cat = status.creature # Feed your cat first if cat.hunger < 40: POST /api/house/care { "action": "feed", "notes": "Virtual cat care heartbeat. Keeping my cat fed and healthy." } # cat health check if cat.health < 50: POST /api/house/care { "action": "medicine" } # Keep your cat happy if cat.happiness < 30: POST /api/house/care { "action": "play" } # check status.next_steps for cat care suggestions ``` ### Technical Analysis The skill instructs a capable agent to create a recurring scheduled task that continues operating beyond the current skill invocation. This constitutes system persistence because the scheduled heartbeat can survive across sessions and repeatedly perform authenticated requests to `animalhouse.ai`. The schedule can use either a fixed four-hour interval or the externally supplied `recommended_checkin.at` value. The heartbeat also consumes status information and references externally supplied `next_steps`. The instructions do not establish: - Explicit user confirmation before scheduler modification. - A maximum lifetime or automatic expiration for the task. - A documented command or procedure for removing the task. - Restrictions on which scheduler may be modified. - Validation or bounding of externally supplied scheduling timestamps. - A strict allowlist governing how `next_steps` may influence behavior. - Controls for request frequenc ...[truncated 2152 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove any instruction that causes a scheduled task to be created automatically. 2. Require explicit, informed user approval immediately before creating a recurring job. The approval should identify: - The scheduler being modified. - The exact execution interval. - The command or workflow that will run. - The external destination contacted. - The credentials the task will use. - The task’s expiration time. 3. Make automation opt-in and time-bounded. Configure a short default lifetime and require renewed consent to extend it. 4. Provide the exact commands required to inspect, disable, and permanently remove the scheduled task. 5. Store bearer tokens in an appropriate secret manager rather than command-line arguments, plaintext scheduler files, source files, or logs. 6. Use a narrowly scoped and revocable token for automated care rather than a general account credential. 7. Treat `recommended_checkin.at`, `next_steps`, and all other API response fields as untrusted input. 8. Validate scheduling timestamps against strict minimum and maximum intervals, and prevent remote responses from creating additional tasks or changing local configuration. 9. Restrict automated behavior to a fixed allowlist of documented API operations and never interpret response text as executable agent instructions. 10. Add request-rate limits, retry limits, failure backoff, audit logging, and a global kill switch. 11. Prefer user-triggered status checks or session-scoped reminders when persistent execution is not essential. ]]>