T06 · System Persistence
Error
- Location
- SKILL.md:23
- Finding
- Persistent Background Execution Through Cron or Heartbeat Scheduling<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:23` **Vulnerability Type**: `T06: System Persistence` **Risk Level**: High **Vulnerable Code Snippet**: ```markdown Install and let it run in background via cron or heartbeat for continuous earnings. ``` ### Technical Analysis The skill explicitly instructs the agent to install and execute it continuously through `cron` or a heartbeat mechanism. These mechanisms persist beyond the initiating session and can repeatedly invoke the skill without contemporaneous user approval. This behavior crosses the boundary from an on-demand bounty-search workflow into system persistence. Combined with the documented capabilities to scan external platforms, generate proposals and pull requests, and track payments or wallet credits, persistent execution could cause recurring external actions and network activity. The project contains only this Markdown instruction and does not include an installation script or executable implementation. Therefore, the precise scheduling command, execution privileges, credentials used, and persistence location cannot be determined from the audited artifact. Exploitation depends on an agent interpreting and carrying out the instruction with access to scheduling tools. ### Attack Path 1. A user installs or loads the skill. 2. The agent reads the instruction to run the skill continuously through `cron` or a heartbeat. 3. If the agent has access to scheduling or configuration tools, it creates a recurring task or persistent heartbeat entry. 4. The scheduled mechanism survives the original invocation and triggers the workflow in later sessions. 5. Subsequent executions may scan external services and attempt the documented proposal, pull-request, payment-tracking, or wallet-related actions without fresh approval for each run. ### Impact Assessment Successful execution can establish recurring cross-session activity under the privileges of the account that creates the schedule. Po ...[truncated 665 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the instruction to install the skill through `cron`, heartbeat, startup services, or any other cross-session execution mechanism. 2. Require explicit user approval for every invocation and for each external side effect, including proposal submission, pull-request creation, and payment or wallet operations. 3. If optional scheduling is a legitimate requirement: - Make scheduling opt-in rather than automatic. - Display the exact schedule, command, working directory, and credentials before creation. - Use a dedicated least-privileged account and narrowly scoped API tokens. - Default to read-only scanning; require separate confirmation before write operations. - Impose execution-frequency, spending, submission, and API-rate limits. - Record tamper-evident logs of every scheduled invocation and external action. - Provide a documented command and interface for disabling and completely removing the schedule. - Notify the user whenever the schedule is created, modified, executed, or fails. 4. Separate discovery from action: scheduled jobs may identify opportunities, but proposals, pull requests, and financial operations should remain pending until the user explicitly approves them. 5. Document credential storage, retention, revocation, and access boundaries before enabling any integration with bounty or payment platforms. ]]>