T06 · System Persistence
- Location
README.md:81- Finding
Persistent Daily Execution Through a User Cron Job
- Content
View full analysis
Vulnerability Details
File Location:
README.md:81-91
Vulnerability Type:T06: System Persistence
Risk Level: HighVulnerable Code Snippet:
markdown ## 定时自动运行(推荐) 通过 cron 每天自动生成日报: ```bash crontab -e添加:
text 0 9 * * * cd /path/to/skills/team-efficiency-daily-report && pnpm starttext ### Technical Analysis The documentation recommends adding the Skill to the user's crontab. The resulting scheduled task survives the original Skill invocation, persists across login sessions and system restarts, and executes the project every day under the privileges of the account that owns the crontab. Daily scheduling is related to the declared daily-report functionality, and the project does not appear to install the cron entry automatically. Nevertheless, persistence is not required for one-time report generation and should be an explicit, informed opt-in rather than the generally recommended execution mode. The risk is amplified by the following properties of the supplied artifact: - `package.json` uses mutable caret dependency ranges for `@bondli-skills/shared`, `puppeteer`, and `puppeteer-core`. - No dependency lockfile was supplied for review. - The referenced `dist/index.js` implementation was absent, preventing verification of the code that the task is intended to execute. - `package.json` does not define the `start` script used by the documented cron command. - No removal procedure, execution isolation, integrity verification, or restricted service account is documented. The scheduled command therefore establishes an unattended execution point whose future behavior may change if the project, its start command, or its resolved dependencies change. ### Attack Path 1. A user follows the README and opens their user crontab with `crontab -e`. 2. The user adds the documented daily task pointing to the project directory. 3. The project is subsequently updated, its p ...[truncated 1359 chars]- Remediation
View remediation
Remediation Suggestions
- Present scheduled execution as an optional deployment mode rather than the recommended default, and require explicit user approval before any persistent task is created.
- Keep ordinary Skill execution one-shot and avoid modifying crontab automatically.
- Document a precise removal and verification procedure, such as reviewing the output of
crontab -land deleting the corresponding entry withcrontab -e. - Run scheduled reporting under a dedicated least-privileged account with access only to the required dashboard, output directory, and configuration.
- Use an absolute path to a reviewed executable and package manager rather than relying on cron's ambient
PATH. - Supply the referenced runtime implementation and a valid
scripts.startentry so users can review and test the exact scheduled behavior before enabling persistence. - Commit and enforce a lockfile, pin security-sensitive dependencies, and perform integrity and vulnerability checks before unattended execution.
- Prevent dependency installation or automatic updates from occurring inside the scheduled task.
- Restrict permissions on configuration, output, and log files because reports may contain internal project, ownership, and delivery information.
- Add bounded logging, failure handling, and monitoring so unexpected changes or repeated failures are visible to the user.
