T09 · Insecure Skill Coding Practices
- Location
SKILL.md:17- Finding
Unbounded Destructive Deletion of the Vector Memory Database
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 17-22
Vulnerability Type: Unsafe recursive deletion without validation or recovery controls
Risk Level: HighVulnerable Code:
markdown **Wipe:** Clear all vector memory ```bash rm -rf ~/.clawdbot/memory/lancedb/Then restart gateway:
clawdbot gateway restarttext ### Technical Analysis The Skill recommends executing `rm -rf` directly against the complete LanceDB storage directory. This operation is recursive, irreversible, and does not include path canonicalization, existence or ownership checks, an interactive confirmation, a backup, or transaction and recovery handling. Although the path is nominally limited to the user's home directory, its effective target depends on environment expansion and filesystem layout. The command could remove all valid vector memories immediately. Symbolic links, unexpected home-directory configuration, or changes to the expected storage layout could also cause behavior beyond the intended cleanup scope. The subsequent gateway restart does not restore deleted information and may make the destructive operation appear to have completed normally. ### Attack Path 1. A user invokes the documented “Wipe” procedure to perform memory maintenance. 2. The shell expands `~` to the executing account's home directory. 3. `rm -rf` recursively removes the entire `memory/lancedb` directory without requesting confirmation. 4. All valid and invalid vector-memory records are deleted together. 5. The gateway is restarted, but the deleted memory remains unavailable because no backup or rollback mechanism exists. ### Impact Assessment Exploitation does not grant additional operating-system privileges; the command runs with the privileges of the invoking user or agent. Within those privileges, however, it can permanently delete the complete vector-memory database. The affected scope includes all memories stored in t ...[truncated 336 chars]- Remediation
View remediation
Remediation Suggestions
- Replace direct recursive deletion with a supported LanceDB or memory-plugin cleanup API where available.
- Stop or quiesce the gateway before modifying its storage to prevent concurrent access and database corruption.
- Resolve and canonicalize the target path, then verify that it exactly matches the expected database directory.
- Reject symbolic links and verify ownership and permissions before deletion.
- Require explicit user confirmation that identifies the exact path and expected data loss.
- Create a timestamped backup or atomic snapshot before cleanup and document a tested restoration procedure.
- Prefer selective deletion based on age, category, or confidence rather than deleting the complete database.
- If filesystem deletion remains necessary, use a guarded maintenance script that fails closed when any validation check is unsuccessful.
