disk-doctor

• Outcome: Review
• Latest audit: Sep 16, 2026 · 11:11 AM UTC
• Version: 1.0.0

Overview

This disk cleanup skill is mostly coherent, but it needs review because it describes Docker pruning as safe cache cleanup even though it can delete stopped containers and their state without confirmation.

Install only if you are comfortable supervising cleanup commands. Before any Docker cleanup, ask the agent to show `docker system df`, `docker ps -a`, image and network listings, and get explicit approval for exact resources; do not treat stopped containers as disposable unless their data is backed by volumes or bind mounts.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:47

Finding

Docker Cleanup Command Can Delete User-Created Container State Without Confirmation

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 47-54
Vulnerability Type: Unsafe destructive resource cleanup
Risk Level: Medium

Vulnerable Code

bash

These four are pure caches. Every one regenerates on demand. Nothing the user
created is touched.

```bash
npm cache clean --force        # commonly the single biggest win
apt-get clean                  # package archives, already installed
journalctl --vacuum-size=64M   # keeps recent logs, drops the archive
docker system prune -f         # only if docker is present and unused

text

### Technical Analysis

The skill incorrectly describes all four operations as removal of regenerable caches that cannot affect user-created content. In particular, `docker system prune -f` is not restricted to cache data. It can delete stopped containers, unused networks, dangling images, and build cache.

A stopped container may contain application or user-created state in its writable layer. Deleting the container permanently removes that state unless it was separately persisted in a volume or bind mount. The `-f` option suppresses Docker's interactive confirmation, and the instruction “only if docker is present and unused” does not define a reliable verification procedure for determining whether resources are safe to remove.

The issue is an insecure skill instruction rather than evidence of an intentionally malicious payload. Nevertheless, the command contradicts the skill's safety guarantee and can cause destructive changes when followed by an agent with Docker access.

### Attack Path

1. A user asks the agent to reclaim disk space.
2. The agent follows Step 3 and determines, without a prescribed resource-level inspection, that Docker is “unused.”
3. The agent executes `docker system prune -f`.
4. Docker removes stopped containers and other unused resources without requesting confirmation.
5. User-created state stored only in a removed container'
...[truncated 1081 chars]

Remediation

View remediation

Remediation Suggestions

1. Remove docker system prune -f from the group described as “pure caches.”
2. Before proposing Docker cleanup, inspect and show the relevant state:

   bash

   docker system df
   docker ps -a
   docker image ls
   docker network ls
   

3. Clearly explain that stopped containers may contain non-regenerable data in their writable layers.
4. Require explicit, informed user approval after identifying the exact Docker resources eligible for deletion.
5. Do not use -f by default; preserve Docker's interactive confirmation as an additional safeguard.
6. Prefer narrowly scoped operations. If only build cache should be reclaimed, inspect it first and use docker builder prune rather than pruning all categories of Docker resources.
7. Where stopped containers are candidates for deletion, verify that important state is persisted in named volumes or bind mounts and that the user has a tested recovery path.
8. Reword the safety claim so it does not state that Docker pruning affects only regenerable caches or that user-created content cannot be touched.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep