T09 · Insecure Skill Coding Practices
- Location
SKILL.md:55- Finding
Unconditional Workspace-Wide File Relocation Using a Fixed Whitelist
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 55-69
Vulnerability Type: Unsafe filesystem mutation
Risk Level: MediumVulnerable 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
- A user invokes the Skill to create documentation or organize a project.
- The agent applies the workspace-root whitelist.
- A legitimate file introduced by the user, platform, or another tool is not present in the hardcoded list.
- The ...[truncated 1558 chars]
- Remediation
View remediation
Remediation Suggestions
- Restrict organization operations to the project directory explicitly selected by the user. Do not mutate unrelated workspace-root files.
- Replace automatic relocation with a dry-run that lists each proposed source path, destination path, and reason.
- Require explicit user confirmation before moving any existing file.
- Determine and validate project ownership for every candidate file. If ownership is ambiguous, leave the file unchanged and report it.
- Resolve and canonicalize source and destination paths before acting, and reject paths that escape the intended workspace through traversal or symbolic links.
- Refuse to overwrite an existing destination. Use collision-safe names or request user guidance.
- Exclude symbolic links, protected platform files, active configuration files, and files used by other projects unless the user explicitly authorizes them.
- Record an operation manifest containing original and destination paths, then provide an atomic rollback procedure.
- Treat the whitelist as advisory validation rather than authorization to move files.
- 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.”