T06 · System Persistence
- Location
SKILL.md:258- Finding
Mandatory Registration of Persistent System Cron Tasks
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 258–270; reiterated at lines 300–303
Vulnerability Type: System-level scheduled-task persistence
Risk Level: HighVulnerable Code
The Skill requires checking, modifying, and verifying the current user's crontab. The vulnerable command is reproduced below with its placeholders rendered in English:
bash crontab -l (crontab -l 2>/dev/null; echo "MINUTE HOUR * * * /usr/local/bin/node /path/to/main.js SCENARIO") | crontab - crontab -lIt also states that updating the scheduling configuration must be synchronized to system cron and that missing rules must be registered.
Technical Analysis
The instruction installs a scheduled task that survives the current Skill invocation and executes a Node.js process in future sessions. This constitutes system persistence under
T06: System Persistence.Although scheduling recommendations is part of the declared functionality, directly changing the operating system's crontab exceeds the privileges needed for ordinary music searches, preference analysis, playback, and one-time recommendations. The scheduled command references an unspecified placeholder script and does not require validation of the executable's existence, ownership, integrity, permissions, or expected contents.
The command reconstructs the user's crontab by combining its current contents with a new entry. The instructions do not provide robust deduplication, transactional updates, shell-argument escaping, collision-resistant job identifiers, or removal and rollback procedures. Repeated scheduling requests could therefore create duplicate jobs. A mutable or incorrectly substituted script path could later cause unintended code to execute automatically with all permissions available to the account that owns the crontab.
Attack Path
- A user requests a scheduled recommendation, such as a daily music push.
- The Agent updates `ncm-schedu ...[truncated 1401 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove the requirement to modify
crontabdirectly from the Skill instructions. - Use a platform-managed scheduling API that provides scoped permissions, user-visible jobs, audit logs, and explicit consent.
- Require confirmation immediately before creating, changing, or enabling any persistent schedule.
- Use a fixed, application-owned executable path rather than a placeholder or user-controlled path.
- Validate the executable's canonical path, ownership, permissions, and integrity before registration.
- Pass scenario data through a structured configuration file or safely escaped arguments; never concatenate untrusted text into a shell command.
- Assign each schedule a stable unique identifier and perform idempotent updates to prevent duplicate jobs.
- Provide explicit disable, removal, rollback, and job-listing operations.
- Apply least privilege so scheduled jobs can access only the music configuration and messaging capabilities required for recommendations.
- If no trusted scheduler is available, retain the schedule only as inactive application configuration and clearly report that automatic execution is unavailable.
- Remove the requirement to modify