T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:55
- Finding
- Unconditional Workspace-Wide File Relocation Using a Fixed Whitelist## Vulnerability Details **File Location**: `SKILL.md`, lines 55-69 **Vulnerability Type**: Unsafe filesystem mutation **Risk Level**: Medium ### Vulnerable Code ```markdown ## Workspace Root Whitelist Only these may exist in `workspace/` root: **System files:** `AGENTS.md` `SOUL.md` `MEMORY.md` `CREDENTIALS.md` `HEARTBEAT.md` `SESSION-STATE.md` `IDENTITY.md` `USER.md` `CODING-PERSONA.md` `TOOLS.md` `.env` `package.json` `package-lock.json` **System dirs:** `memory/` `projects/` `scripts/` `backups/` `captures/` `config-backups/` `tmp/` `skills/` `node_modules/` `.agents/` `.clawhub/` `.openclaw/` `.pi/` Any file not on this list → move to its project's `tmp/` immediately. ``` ### Technical Analysis The Skill instructs the agent to move every workspace-root file that is absent from a fixed whitelist. The operation is unconditional and does not require user confirmation, establish file ownership, determine whether a file belongs to the active project, or verify that the destination is safe. A static whitelist can become incomplete whenever the platform, another Skill, or the user introduces a legitimate root-level file. The instruction also provides no safe handling for symbolic links, destination-name conflicts, open files, protected files, or rollback after a partial operation. Moreover, the phrase “its project's `tmp/`” does not define a trustworthy method for associating an arbitrary root file with a project. This behavior violates least-change principles for workspace organization. Although it does not grant new operating-system privileges, it directs the agent to use its existing filesystem permissions against files outside the selected project's scope. ### Attack Path 1. A user invokes the Skill to create documentation or organize a project. 2. The agent applies the workspace-root whitelist. 3. A legitimate file introduced by the user, platform, or another tool is not present in the hardcoded list. 4. The ...[truncated 1558 chars]
- Remediation
- ## Remediation Suggestions 1. Restrict organization operations to the project directory explicitly selected by the user. Do not mutate unrelated workspace-root files. 2. Replace automatic relocation with a dry-run that lists each proposed source path, destination path, and reason. 3. Require explicit user confirmation before moving any existing file. 4. Determine and validate project ownership for every candidate file. If ownership is ambiguous, leave the file unchanged and report it. 5. Resolve and canonicalize source and destination paths before acting, and reject paths that escape the intended workspace through traversal or symbolic links. 6. Refuse to overwrite an existing destination. Use collision-safe names or request user guidance. 7. Exclude symbolic links, protected platform files, active configuration files, and files used by other projects unless the user explicitly authorizes them. 8. Record an operation manifest containing original and destination paths, then provide an atomic rollback procedure. 9. Treat the whitelist as advisory validation rather than authorization to move files. 10. Change the final instruction to language such as: “Report unexpected root files and ask the user whether each should be moved; never relocate them automatically.”