T09 · Insecure Skill Coding Practices
- Location
memory-organizer.js:28- Finding
Symlink-Based File Access Escapes the Workspace Boundary
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a plausible memory cleanup skill, but it needs review because its file safety checks can be bypassed and some commands can permanently alter or delete memory data.
Review before installing. Use it only on a trusted OpenClaw workspace, avoid running it where other users or archives could introduce symlinks, and back up MEMORY.md plus the memory directory before using compress, discard, or clean. Prefer a pinned/verified installer command instead of the unpinned npx example, and do not run clean until you are certain backup and discarded files are no longer needed.
memory-organizer.js:28Symlink-Based File Access Escapes the Workspace Boundary
README.md:30Unpinned Package Execution in Installation Instructions
The README instructs users to run npx clawhub install memory-organizer without pinning a specific version. That causes execution of whatever package version is current at install time, which creates a supply-chain risk if the package is updated maliciously, compromised, or unexpectedly changed. In the context of an agent skill installer, this is more dangerous because users are being told to execute a network-fetched package directly from documentation.
The Chinese installation section repeats the same unpinned npx clawhub install memory-organizer instruction, creating the same risk of executing an unintended or malicious package version. Because this appears in multilingual docs, the unsafe pattern is duplicated and may affect more users. The skill context does not reduce the risk; it still encourages direct execution of remote code during installation.
Without declared permissions the skill's intent is opaque and cannot be validated.
The header comments and help text frame the skill as preserving daily detail in dated memory files, but the implementation can compress files destructively and mark them discarded. This mismatch is security-relevant because operators may trust the documentation and invoke commands that irreversibly alter or remove records they expected to remain intact.
The tool allows the workspace root to be fully caller-controlled via environment variable or --workspace, so its read/write/delete operations can target arbitrary directories rather than only the intended OpenClaw memory area. While path checks constrain actions relative to the chosen base, they do not restrict what that base can be, expanding the tool's authority beyond its apparent purpose.
The compress command rewrites the original memory file in place after creating a .bak copy, which contradicts the stated promise to preserve day-by-day history in the dated files themselves. If a user runs compression and later runs cleanup, the backup can be deleted, leaving only a lossy reduced version of the historical record.
The clean command permanently deletes .bak and .discarded artifacts without confirmation, even though those files are the only recovery path after destructive compress or discard operations. This undermines the tool's stated preservation model and can cause irreversible loss of memory history.
Cleanup performs unconditional unlink operations on all .bak and .discarded files in the memory directory, with no confirmation, dry-run, or detailed warning. Because these files are safety artifacts created by earlier destructive actions, silent permanent deletion materially increases the risk of irreversible data loss.
The usage section states that the compress command will compress a dated memory file "in place," which implies direct modification of user data. The README does not include any caution about backing up files, reviewing changes, or the fact that the operation overwrites existing memory content.
No suspicious patterns detected.