Trust Assessment
cron-retry received a trust score of 86/100, placing it in the Mostly Trusted category. This skill has passed most security checks with only minor considerations noted.
SkillShield's automated analysis identified 1 finding: 0 critical, 1 high, 0 medium, and 0 low severity. Key findings include Automated cron job execution based on potentially manipulable error state.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. All layers scored 70 or above, reflecting consistent security practices.
Last analyzed on February 13, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings1
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| HIGH | Automated cron job execution based on potentially manipulable error state The skill instructs the host LLM to automatically retry cron jobs (`cron tool with action: "run"`) if their `lastStatus` is "error" and `lastError` matches specific network patterns. An attacker could potentially create a cron job with a malicious payload that is designed to fail with one of the specified network error messages (e.g., by attempting to connect to a non-existent host or service). This would then cause the `cron-retry` skill to automatically re-execute the malicious job, leading to arbitrary command execution. The `cron.run` tool grants significant power, and its automated invocation based on a potentially manipulable error state represents an excessive permission and a command injection risk. 1. Restrict `cron.run` tool access: If possible, limit the `cron.run` tool's capabilities to only specific, pre-approved cron jobs or a whitelist of safe commands. 2. Sanitize/Validate Cron Job Content: Implement a mechanism to review and sanitize the content of cron jobs before they are allowed to be created or executed, especially if they can be created by untrusted sources. 3. More robust error detection: Instead of relying solely on `lastError` string matching, consider a more robust mechanism to determine if a job is truly retryable (e.g., checking specific error codes, trusted error sources, or requiring explicit retry flags on the job itself). 4. Human approval: For critical jobs, consider requiring human approval before an automated retry. | LLM | SKILL.md:60 |
Scan History
Embed Code
[](https://skillshield.io/report/9e07214043aa57d4)
Powered by SkillShield