T06 · System Persistence
Warning
- Location
- SKILL.md:34
- Finding
- Recurring OpenClaw Cron Job Creates Cross-Session Persistence<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:34-36`, `SKILL.md:101-103`, and `SKILL.md:123-128` **Vulnerability Type**: Persistent scheduled agent execution **Risk Level**: Medium ### Complete Code Snippet ```markdown This skill requires git to be initialized in the workspace. The agent needs write access to instruction files and memory files (declared in the metadata above). Diff reports are posted to the conversation channel — no external channel credentials are needed unless the user configures an external destination. All scheduled tasks (diff reports, heartbeat checks) use OpenClaw's built-in `cron` tool. They run as isolated agent sessions within the OpenClaw sandbox. No OS-level schedulers (crontab, systemd, launchd) are created or modified. ``` ```markdown ### Instruction Diff Reports Weekly (or on-demand via "diff report"): the agent diffs all instruction files against their state 7 days ago and posts a summary to the conversation. What changed, who changed it, why. The user reviews, confirms, or reverts. Schedule the diff report at a fixed local time that works for the user (e.g., Sunday morning). There's nothing special about the exact time — pick one, set a cron using OpenClaw's built-in cron tool, be consistent. ``` ```markdown ## Daily Provenance Checks During heartbeat cycles: 1. Check last-reviewed dates in provenance headers of all instruction files 2. Apply graduated urgency: mention at 30 days, warn at 60, escalate at 90 3. Check for agent-written goals/tasks older than 14 days without user interaction — flag for re-authorization 4. Check for topic files untouched for 30 or more days — flag for archival or confirmation 5. Generate weekly diff report if due ``` ### Technical Analysis The Skill instructs the agent to register a recurring job through OpenClaw's built-in `cron` tool. Although it explicitly avoids operating-system schedulers and states that jobs execute ...[truncated 3154 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not create a cron job by default. Make on-demand reports the default behavior. 2. Before registration, require explicit user confirmation that displays: - The exact schedule and time zone. - The files and directories that each run may access. - The destination receiving generated reports. - Whether the job has an expiration date. - The exact command or interface needed to disable and delete it. 3. Prefer an existing user-configured heartbeat over installing a separate recurring job. 4. Apply automatic expiration, such as a limited number of runs or a defined end date, unless the user expressly requests indefinite scheduling. 5. Restrict scheduled sessions to the minimum required file set instead of granting access to all instruction and memory files. 6. Generate metadata-only summaries where possible. Redact secrets, personal data, contact details, and sensitive diff content before posting. 7. Prohibit external report destinations by default and require separate confirmation before enabling one. 8. Record the job identifier, creator, creation time, schedule, destination, and expiration in an auditable local configuration. 9. Provide a status command that lists active jobs and periodically remind the user that persistent jobs remain enabled. 10. Prevent scheduled sessions from modifying mixed-authority files unless a specific change is separately authorized. ]]>