T06 · System Persistence
- Location
SKILL.md:156- Finding
Persistent Nightly Re-indexing Through User Crontab
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 156-162
Vulnerability Type: Scheduled-task persistence
Risk Level: HighComplete Code Snippet:
bash pm2 start ecosystem.config.cjs pm2 save # Initial code index (takes a few minutes depending on codebase size) curl -X POST http://localhost:5204/api/index?summarize=true # Set up nightly re-index (crontab -l 2>/dev/null; echo "0 4 * * * curl -s -X POST http://localhost:5204/api/index?summarize=true > /dev/null") | crontab -Technical Analysis
The setup command modifies the current user's crontab and installs a task that invokes the indexing endpoint every day at 04:00. The task survives the Skill setup session and continues operating until explicitly removed.
Although periodic re-indexing supports the advertised search functionality and is disclosed as a feature, it is not necessary for on-demand semantic search. The instruction therefore exceeds the minimum persistence required for the core functionality. It also lacks an explicit opt-in prompt, an uninstall command, an idempotency check, and a unique marker for safe management.
Running the setup repeatedly can append duplicate cron entries. In addition, the cron job trusts whichever process is listening on port 5204 in the future. If that local service is replaced, modified, or compromised, the persistent task will continue sending requests to it automatically. The use of
pm2 savealso preserves the PM2 process list for restoration where PM2 startup integration has already been configured, although this artifact does not itself executepm2 startup.Attack Path
- A user follows the documented setup instructions.
- The pipeline reads the existing user crontab, appends the supplied entry, and writes the resulting configuration back with
crontab -. - The scheduled entry remains active across terminal sessions and system restarts where cron is enabled.
- At 04:00 each ...[truncated 855 chars]
- Remediation
View remediation
Remediation Suggestions
- Make scheduled indexing explicitly opt-in and keep the default setup limited to on-demand indexing.
- Present the exact schedule, expected resource usage, indexed path scope, and persistence effects before installation.
- Add a uniquely marked and idempotent cron entry rather than blindly appending it.
- Check for an existing entry before making changes to prevent duplicate jobs.
- Supply a documented uninstall command that removes only the entry created by this Skill.
- Consider using an application-level scheduler that is disabled by default and managed through the service configuration.
- Add timeouts, locking, and overlap prevention so a new indexing run cannot start while an earlier run remains active.
- Verify that the service is bound only to loopback and authenticate state-changing endpoints where practical.
- Do not use
pm2 saveunless persistent process restoration is separately requested and explained to the user.
