T06 · System Persistence
- Location
SKILL.md:60- Finding
Unbounded Persistent Email Polling via Scheduled Tasks
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 60
Vulnerability Type: Persistent scheduled network activity
Risk Level: MediumVulnerable Code Snippet:
markdown **RECOMMENDED: If you have heartbeat, cron, or scheduling capabilities, set up polling (every 30-60 seconds) right after creating your mailbox to catch replies.**Technical Analysis
The skill recommends creating a recurring heartbeat, cron job, or equivalent scheduled task immediately after mailbox creation. The instruction does not define an expiration time, maximum number of requests, task-scoped lifetime, cleanup procedure, or requirement to obtain explicit user approval.
If followed by an agent with scheduling capabilities, the resulting task can continue operating across sessions and after the original skill invocation has ended. Each poll sends the mailbox bearer API key to the external email API. Although the network destination is consistent with the skill's stated email functionality, indefinite background polling unnecessarily extends credential use and external communication beyond the initiating task.
The instruction is conditional and does not itself install a scheduled task. Exploitation therefore requires an agent that can create persistent schedules and that follows the recommendation without requesting approval.
Attack Path
- The agent loads the skill and creates a hosted mailbox.
- The external service returns a bearer API key for mailbox access.
- Following the recommendation at line 60, the agent creates a heartbeat, cron job, or other recurring task.
- The scheduled task polls the external inbox endpoint every 30–60 seconds while attaching the bearer API key.
- Because no termination or cleanup condition is specified, the task may survive the original run and continue making authenticated requests indefinitely.
- Continued execution increases credential exposure, consumes local and remote resou ...[truncated 702 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not create heartbeat, cron, or other persistent tasks without explicit, informed user approval.
- Prefer on-demand inbox checks or the documented webhook mechanism instead of frequent polling.
- If polling is necessary, impose a finite duration, maximum request count, exponential backoff, and a clearly defined termination condition.
- Scope any schedule to the current task or session where technically possible.
- Record the identifier and configuration of every created scheduled task so it can be reliably removed.
- Automatically delete the schedule when the task completes, the mailbox is deleted, authentication fails, or the configured lifetime expires.
- Inform the user that recurring requests transmit the bearer API key to the external service.
- Store the API key in an approved secret store rather than embedding it directly in cron commands, logs, process arguments, or scheduler configuration.
- Rotate or revoke the API key after polling is disabled or if unintended persistence is detected.
