T06 · System Persistence
Warning
- Location
SKILL.md:183- Finding
Recurring Authenticated Network Activity Through Scheduled Care Tasks
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 183–204
Vulnerability Type: Persistent scheduled task
Risk Level: MediumVulnerable 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
text ### 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
View remediation
Remediation Suggestions
- Require explicit user consent before creating any scheduled task, and display the exact command, frequency, destination, credential use, and expected lifetime.
- Make scheduling opt-in rather than part of the default care workflow.
- Add a finite expiration time and a maximum execution count to every task.
- Provide clear commands for listing, disabling, and permanently deleting the task.
- Validate
recommended_checkin.atas a timestamp within a documented safe range; do not directly convert arbitrary server-provided content into scheduler configuration. - Restrict the scheduled workflow to a fixed allowlist of Animal House API origins, paths, HTTP methods, and care actions.
- Do not automatically execute open-ended server-provided
next_steps; treat them as untrusted suggestions and require validation or user confirmation. - Store the bearer token in a protected credential store with minimal access permissions, and support token rotation and revocation.
- Record each background execution in a user-visible audit log and apply rate limits, retry limits, and network timeouts.
- Prefer user-initiated status checks where persistent operation is not essential.