Security audit
Security checks for vulnerabilities and agentic risk
The skill does what it claims, but it gives agents direct recipes for persistent cron changes without enough review or safety controls.
Install only if you want an agent to help manage real cron jobs. Before allowing it to run changes, ask to see the exact crontab entry or removal diff, back up the current crontab, test commands manually, and be especially careful with deletion, service restart, and privileged log-path examples.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
echo "=== User crontab ==="
crontab -l 2>/dev/null || echo "(empty)"
echo ""
echo "=== System cron ==="
ls /etc/cron.d/ 2>/dev/null
The skill explicitly instructs the agent to add, edit, and remove cron jobs, which creates persistent system changes that continue executing after the session ends. Without clear user-confirmation, persistence warnings, or safeguards around what commands may be scheduled, an agent could unintentionally install long-lived tasks or remove legitimate scheduled jobs.
This command appends a new cron entry and installs it immediately, creating persistent execution on the host. Because the placeholder allows arbitrary commands and the skill does not require confirmation or validation, it could be used to establish unintended or harmful persistence.
# Add to user crontab
(crontab -l 2>/dev/null; echo "SCHEDULE COMMAND") | crontab -
# Common schedules:
crontab -e opens the user's cron configuration for modification, enabling persistent changes that may be hard to audit in an automated-agent context. If an agent invokes this path or guides users into it without review controls, it can facilitate stealthy or accidental persistence.
# Edit crontab interactively
crontab -e
# Or remove a specific line
crontab -l | grep -v "PATTERN_TO_REMOVE" | crontab -
Piping crontab -l through grep -v and reinstalling it removes matching entries, which modifies persistent scheduled execution and can accidentally delete unrelated jobs if the pattern is too broad. In an agent setting, loose pattern matching makes this particularly error-prone and potentially disruptive.
crontab -e
crontab -l | grep -v "PATTERN_TO_REMOVE" | crontab -
### Check cron logs
The examples include scheduled actions such as deleting files in /tmp, restarting services, and writing into system log locations, all of which can be destructive or disruptive if used incorrectly. Presenting these patterns without cautions or validation guidance increases the chance that an agent will apply them unsafely or too broadly.
This example adds environment variables and a scheduled backup command into crontab, again creating persistent execution. It also encourages writing to /var/log, which may require elevated privileges and can fail or behave unexpectedly if used in the wrong context.
# Cron runs with minimal environment. Set what you need:
(crontab -l 2>/dev/null; echo "PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash
0 2 * * * /home/user/backup.sh >> /var/log/backup.log 2>&1") | crontab -
The example directly shows how to install a nightly backup cron job, which is a form of persistence because it causes future unattended execution. In a skill intended for automation, this is contextually expected, but it is still security-relevant because unattended jobs can be abused or misconfigured.
## Examples
**User:** "Run my backup script every night at 2am"
→ `(crontab -l 2>/dev/null; echo "0 2 * * * /home/user/backup.sh >> /var/log/backup.log 2>&1") | crontab -`
**User:** "Check disk space every hour and alert me if it's over 80%"
→ Create a check script + cron job
No suspicious patterns detected.