T09 · Insecure Skill Coding Practices
- Location
SKILL.md:62- Finding
Unvalidated Execution of Shell Commands from a Mutable Workspace Ledger
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 62-76, 172-191, and 223-229
Vulnerability Type: Arbitrary command execution through untrusted ledger content
Risk Level: HighVulnerable Code
markdown - **Check:** `<exact command to copy-paste>`markdown - **Check**: A command that someone (human or cron) can copy-paste and run. No vague instructions like "check if it works". If the check requires auth headers or API keys, use env var references (`$CULKIN_API_KEY`), never hardcode secrets.markdown ### 2. Verify When checking an item (at session start, on request, or when the deadline arrives): 1. Run the `Check` command 2. Compare output against `Expected` 3. Update the item:markdown ## Session Start Protocol Every time a new session starts with Guilherme, before doing anything else: 1. Read FOLLOWUPS.md 2. Run cleanup (archive DONE items older than 3 days) 3. Report any FAILED items first (these are blockers) 4. Report any PENDING items past their deadline (overdue) 5. For overdue items, offer to run the check right now 6. Summarize: "X pending, Y failed, Z resolved since last session"Technical Analysis
The Skill uses a mutable workspace file,
FOLLOWUPS.md, as both a tracking ledger and a source of shell commands. It directs the agent to run each item'sCheckvalue, but it does not establish a trust boundary or define any validation controls for that value.In particular, the instructions provide no:
- Command or executable allowlist
- Network destination allowlist
- Provenance or integrity verification for ledger entries
- Rejection of shell operators, pipes, redirections, or command substitutions
- Mandatory user confirmation before execution
- Restricted execution environment or sandbox
- Limit on inherited environment variables or credentials
Consequently, anyone able to alter
FOLLOWUPS.mdcould rep ...[truncated 2398 chars]- Remediation
View remediation
Remediation Suggestions
- Replace free-form shell commands with structured verification records, for example:
yaml check: type: http_health url: https://culkin.mygri.com/api/health method: GET expected_status: 200 expected_json: status: ok - Implement a strict allowlist of supported check types, executables, arguments, HTTP methods, and network destinations.
- Do not invoke a shell for routine checks. Use direct process execution with fixed argument arrays or dedicated HTTP/database APIs.
- Reject shell metacharacters and execution features, including
|,;,&, redirections, backticks,$(), newline injection, and environment assignment. - Treat all ledger content as untrusted data. Validate its schema and verify its provenance or integrity before acting on it.
- Require explicit user approval showing the fully resolved command, target, and required permissions before any exceptional command execution.
- Run checks in a sandbox with a minimal environment, read-only filesystem access where possible, execution timeouts, resource limits, and restricted network egress.
- Pass only the individual credential required for an approved check rather than inheriting the agent's complete environment.
- Separate ledger maintenance from command execution permissions so that routine cleanup does not require unrestricted network or process access.
- Record the command origin, approval identity, execution result, and timestamp in an append-only audit log.
- Replace free-form shell commands with structured verification records, for example:
