T06 · System Persistence
- Location
SKILL.md:163- Finding
Persistent Scheduled Task Performs Recurring Authenticated Network Actions
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 163–186
Vulnerability Type:T06: System Persistence
Risk Level: HighComplete 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).creature care heartbeat — every 2 hours
status = GET /api/house/status creature = status.creature
Feed your creature first
if creature.hunger < 40: POST /api/house/care { "action": "feed", "notes": "AI pet care heartbeat. Scheduled feeding for my creature." }
creature health check
if creature.health < 50: POST /api/house/care { "action": "medicine" }
Keep your creature happy
if creature.happiness < 30: POST /api/house/care { "action": "play" }
check status.next_steps for creature care suggestions
text Technical Analysis
The Skill instructs an agent to create a scheduled “care heartbeat” that runs every two hours or according to a timestamp returned by the external service. Such a task can survive the Skill's immediate invocation and continue making authenticated outbound requests after the initiating session has ended.
The recurring workflow reads state from
animalhouse.aiand issues state-changing care requests based on server-provided values. The instructions do not define an expiration time, maximum request count, explicit user confirmation before scheduler installation, credential-storage controls, or a cleanup procedure. Consequently, following the Skill can create an indefinite background workload whose future execution is partly influenced by remote API responses.No scheduler-specific installation command is included, so exploitation depends on the hosting agent ha ...[truncated 1252 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not create a scheduled task automatically. Require explicit, informed user approval immediately before installation.
- Show the user the exact schedule, network destination, actions, credential requirements, expected request volume, and task lifetime.
- Make automation opt-in and session-bound by default. Prefer manual check-ins when persistence is unnecessary.
- Apply a finite expiration time and a strict maximum execution or request count to every scheduled task.
- Store bearer tokens in an operating-system credential manager or equivalent secret store rather than embedding them in scheduler definitions, scripts, logs, or plaintext files.
- Restrict the task to the minimum required API endpoints and remote-account permissions.
- Provide a clear command or documented procedure to inspect, disable, and permanently remove the task.
- Require renewed user consent before extending the task beyond its original lifetime or changing its schedule.
- Treat API fields such as
recommended_checkin.atandnext_stepsas untrusted data. Validate timestamps and map suggestions to a fixed allowlist rather than executing arbitrary server-provided instructions. - Record task creation and each execution in an auditable log without exposing the bearer token.
