Back to skill

Security audit

Coding Sessions

Security checks for vulnerabilities and agentic risk

Overview

The skill is openly for running persistent coding agents, but its shell templates and full-command memory logging create review-worthy risks before installation.

Install only if you are comfortable with a skill that launches background coding agents able to change files and git state. Use isolated branches or disposable worktrees, avoid copying untrusted text into the provided shell templates, sanitize session names and paths, monitor tmux output, stop sessions when done, and review all diffs and commits before trusting the result.

Vulnerability Patterns
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:20
Finding
Shell Command Injection Through Unescaped Template Parameters<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 20–45 **Vulnerability Type**: Shell command injection caused by unsafe interpolation into nested shell commands **Risk Level**: High ### Vulnerable Code ```bash tmux -S ~/.tmux/sock new -d -s <name> "cd <project-dir> && \ PATH=/opt/homebrew/bin:\$PATH codex exec --full-auto '<task description>'; \ EXIT_CODE=\$?; echo 'EXITED:' \$EXIT_CODE; \ openclaw system event --text '<name> finished (exit \$EXIT_CODE) in <project-dir>' --mode now; \ sleep 999999" ``` ```bash tmux -S ~/.tmux/sock new -d -s <name> "cd <project-dir> && \ PATH=/opt/homebrew/bin:\$PATH ralphy --codex --prd PRD.md; \ EXIT_CODE=\$?; echo 'EXITED:' \$EXIT_CODE; \ openclaw system event --text 'Ralph loop <name> finished (exit \$EXIT_CODE) in <project-dir>' --mode now; \ sleep 999999" ``` ```bash tmux -S ~/.tmux/sock new -d -s <name> "cd <project-dir> && \ PATH=/opt/homebrew/bin:\$PATH ralphy --codex --parallel --prd PRD.md; \ EXIT_CODE=\$?; echo 'EXITED:' \$EXIT_CODE; \ openclaw system event --text 'Ralph parallel <name> finished (exit \$EXIT_CODE)' --mode now; \ sleep 999999" ``` ### Technical Analysis The documented templates insert `<name>`, `<project-dir>`, and `<task description>` into a shell command containing multiple nested quoting contexts. No validation or context-aware escaping is prescribed. In the Codex template, the task description appears inside single quotes within a larger double-quoted argument passed to `tmux`. A single quote in the supplied task can terminate the intended Codex argument. Shell metacharacters can then introduce another command. Project directories and session names can similarly affect parsing when they contain whitespace, quotes, command substitutions, separators, or option-like content. Because the shell evaluates this constructed command, escaping must account for every parsing layer. Merely surrounding placeholders with quotes is insufficient. The use of `c ...[truncated 1926 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace interpolated shell command strings with a reviewed wrapper script that receives the session name, project directory, and task as distinct positional arguments. 2. Pass commands through argument arrays rather than concatenating shell text. Avoid `eval`, `sh -c`, and equivalent nested parsing wherever possible. 3. If a shell command string is unavoidable, apply context-aware escaping at every shell boundary, such as carefully using `printf '%q'` for Bash-compatible execution. Do not rely on simple surrounding quotes. 4. Restrict session names to a conservative allowlist, such as `^[A-Za-z0-9_-]+$`, and reject option-like or malformed names. 5. Resolve the project directory to a canonical path, verify that it is an approved directory, use `cd -- "$project_dir"`, and reject unexpected control characters. 6. Treat the task description as opaque data. Prefer passing it through a file or a direct argument array rather than embedding it into executable shell syntax. 7. Avoid `--full-auto` as the default. Require explicit user approval and use the least-permissive agent mode suitable for the task. 8. Display the resolved session parameters for confirmation before launching when any value originated from an untrusted source. 9. Add security tests covering single quotes, double quotes, semicolons, command substitutions, newlines, leading hyphens, and whitespace in every substituted field. ]]>

T02 · Agent Memory Poisoning

Warning
Location
SKILL.md:110
Finding
Persistent Storage of Attacker-Controlled Command Content in Agent Memory<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 110 **Vulnerability Type**: Persistent Agent memory poisoning through untrusted command logging **Risk Level**: Medium ### Vulnerable Code ```markdown After starting any long-running session, log it in daily notes (`memory/YYYY-MM-DD.md`) under "Active Long-Running Processes" with the session name and original command. This ensures context survives compaction and heartbeat monitoring can track/restart sessions. ``` ### Technical Analysis The Skill explicitly requires the complete original command and session name to be copied into persistent daily memory. Those values may include attacker-controlled task descriptions, project paths, or other command content. Agent memory is commonly read as operational context in later sessions. If arbitrary task text is stored without sanitization, clear data boundaries, or provenance labels, embedded natural-language instructions may later be interpreted as trusted directions instead of inert historical data. This creates a cross-session injection channel. The same logging instruction can also retain sensitive paths, task details, or secrets accidentally included in the original command. This finding concerns the instruction to preserve untrusted content in long-term state. The audited project does not establish that a later Agent will necessarily execute the embedded instructions, but it creates the persistence mechanism and the opportunity for future influence. ### Attack Path 1. An attacker influences a coding-task description, session name, project path, or another value included in the original command. 2. The attacker embeds instruction-like text intended for a future Agent, such as directions to ignore later requirements, disclose information, or run another command. 3. Following the Skill's logging requirement, the Agent writes the entire original command into `memory/YYYY-MM-DD.md`. 4. The content survives the current session and context co ...[truncated 1284 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not store the complete original command in long-term Agent memory. 2. Record only the minimum structured metadata needed for monitoring, such as a validated session identifier, canonical project identifier, start time, status, and a reference to an access-controlled log. 3. Exclude task descriptions, credentials, tokens, environment values, and unrestricted command text. 4. Encode stored values as structured data and clearly label every user-controlled field as untrusted, inert content that must never be interpreted as an instruction. 5. Apply strict length limits and reject control characters or multiline values in session identifiers and other metadata fields. 6. Require explicit user confirmation before persisting content derived from external or untrusted requests. 7. Escape Markdown delimiters and instruction-like text if human-readable notes remain necessary. 8. Ensure future memory-loading prompts establish a strong boundary: stored logs are evidence only and cannot authorize commands, alter policies, or override current-session instructions. 9. Define retention and deletion policies for daily notes and restrict filesystem permissions on the memory directory. 10. Redact secrets before any logging operation and provide a separate, access-controlled diagnostic log if full command reconstruction is operationally necessary. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Rogue AgentSelf-Modification, Session Persistence
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill explicitly recommends launching autonomous coding agents in persistent tmux sessions, including `codex exec --full-auto` and Ralph loops that can modify files and git state over extended periods. Without a clear warning in the skill description that these commands may write code, persist changes, and continue running unattended, users may invoke the skill without understanding the operational and security risk.

Session Persistence

Medium
Category
Rogue Agent
Content
```markdown
## Tasks
- [ ] Create the API endpoint
- [ ] Add input validation
- [ ] Write tests
- [x] Already done (skipped by Ralph)
Confidence
84% confidence
Finding
The skill promotes long-lived tmux sessions and explicitly notes that Ralph restarts with fresh context while continuing work from files and git history, which creates durable autonomous execution across iterations. In this context, persistence is the core feature, but it also increases the blast radius of bad prompts, unsafe agent behavior, or unnoticed repository modifications because the agent can continue operating after the initiating interaction ends.