claudebox

• Outcome: Review
• Latest audit: Sep 13, 2026 · 3:02 AM UTC
• Version: 2.3.12

Overview

This skill is upfront about being a powerful Claude-in-Docker service, but its documented setup can expose broad agent, file, and Docker-host control if installed or deployed carelessly.

Install only on a trusted, isolated machine or disposable worker. Before enabling API or MCP modes, set strong tokens, bind to localhost or an authenticated proxy, avoid sharing workspaces, and do not mount /var/run/docker.sock unless the task truly needs host container control. Prefer pinned installer/image versions or verify the downloaded installer before running it, and use separate low-privilege Anthropic, SSH, and project credentials.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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

Findings (3)

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/setup.md:8
• Finding: Mutable Remote Installer Is Downloaded and Executed Without Cryptographic Verification<![CDATA[ ## Vulnerability Details **File Location**: `references/setup.md`, lines 8-10 **Vulnerability Type**: `T03: Remote Payload Retrieval and Execution` **Risk Level**: High ### Vulnerable Code ```bash curl -fsSL https://raw.githubusercontent.com/psyb0t/docker-claudebox/master/install.sh -o install.sh less install.sh # read it before running anything you downloaded bash install.sh ``` ### Technical Analysis The installation procedure retrieves executable shell code from the mutable `master` branch of a personal GitHub repository and subsequently runs it with the invoking user's privileges. The download is not pinned to a reviewed commit or immutable release, and no checksum or cryptographic signature is verified. Manual inspection with `less` is preferable to directly piping the response into a shell, but it does not establish reproducible integrity. The contents can change after the Skill has been audited, and users or automated agents may not reliably identify malicious changes during manual review. The installer is documented as creating directories and SSH keys, pulling container images, and installing a wrapper under `/usr/local/bin`. These operations give a compromised installer access to security-sensitive paths and may cause it to be run with elevated privileges. ### Attack Path 1. An attacker compromises the upstream repository, maintainer account, GitHub token, or mutable `master` branch. 2. The attacker replaces or modifies `install.sh` with a malicious payload. 3. A user or automation follows the documented installation procedure. 4. `curl` downloads the attacker-controlled current version without validating a checksum, signature, or commit identity. 5. The user executes `bash install.sh`. 6. The payload runs with the user's privileges and can access that user's files, credentials, SSH configuration, Docker access, and writable executable paths. 7. If installation is performed with administrative privileges, the payload can obtain syst ...[truncated 605 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin the installer URL to an immutable, reviewed commit hash rather than `master`. 2. Publish versioned release artifacts with SHA-256 or stronger checksums. 3. Cryptographically sign releases and verify the signature before execution. 4. Vendor the reviewed installer into the Skill package where feasible. 5. Abort installation if checksum or signature verification fails. 6. Run installation with the least-privileged account possible and avoid `sudo` unless a narrowly scoped operation requires it. 7. Separate privileged installation steps from unprivileged key generation and configuration. 8. Document the exact expected installer digest in the Skill so automated agents can verify it reproducibly. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: references/setup.md:151
• Finding: Privileged API and MCP Services Fail Open When Authentication Tokens Are Unset<![CDATA[ ## Vulnerability Details **File Location**: `references/setup.md`, lines 151-158 **Vulnerability Type**: `T09: Insecure Skill Coding Practices` **Risk Level**: Critical ### Vulnerable Code ```markdown | Variable | Description | Default | | --- | --- | --- | | `CLAUDEBOX_API_MODE` | `1` to start the HTTP API server | _(none)_ | | `CLAUDEBOX_API_MODE_PORT` | API server port | `8080` | | `CLAUDEBOX_API_MODE_TOKEN` | Bearer token for `/run`, `/files`, `/status`, `/openai/*` | _(none — no auth)_ | | `CLAUDEBOX_AVAILABLE_MODELS` | CSV of model aliases surfaced at `/openai/v1/models`. Optional — claudebox's adapter has a built-in default (`haiku,sonnet,opus,opusplan`); set this to override it. The API server only refuses to boot if the resolved list ends up empty. | _(none — adapter default applies)_ | | `CLAUDEBOX_AVAILABLE_EFFORTS` | CSV of effort levels surfaced to Telegram `/effort` picker | adapter default | | `CLAUDEBOX_MCP_MODE` | `1` to expose MCP. Mounts at `/mcp` on the API port if `CLAUDEBOX_API_MODE=1` is also set; otherwise runs standalone on its own port | _(none)_ | | `CLAUDEBOX_MCP_MODE_PORT` | Port for the standalone MCP process (only used when API mode is off) | `8081` | | `CLAUDEBOX_MCP_MODE_TOKEN` | Bearer token for MCP (independent of the API token, no fallback) | _(none — no auth)_ | ``` ### Technical Analysis The API and MCP modes use optional bearer tokens and deliberately operate without authentication when their respective token variables are absent. This is a fail-open access-control design. These are not low-privilege informational interfaces. The documented API provides agent execution through `/run`, OpenAI-compatible agent requests, and workspace file operations. MCP provides tools for running prompts and listing, reading, writing, and deleting workspace files. The underlying Claude Code process uses `--permission-mode bypassPermissions` by default, allowing unrestricted shell and file operations inside the container. Cons ...[truncated 1816 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Fail closed: refuse to start API or MCP mode unless a strong authentication token is configured. 2. If unauthenticated development mode is necessary, require an explicit option such as `CLAUDEBOX_ALLOW_UNAUTHENTICATED_LOCALHOST=1`. 3. Bind unauthenticated development services exclusively to loopback. 4. Generate high-entropy tokens through a secret manager rather than placing literal secrets in Compose files. 5. Require TLS for remote use and deploy behind an authenticating reverse proxy with rate limits and request-size limits. 6. Apply authorization by workspace and operation instead of granting every authenticated caller global file and execution access. 7. Disable deletion, shell execution, and unnecessary internal tools unless explicitly required. 8. Add startup warnings and health-check failures for insecure network exposure. 9. Avoid passing bearer credentials in query parameters because URLs may be retained in logs, browser history, monitoring systems, and proxy telemetry. 10. Add audit logging, request attribution, run quotas, and automated credential rotation. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/setup.md:80
• Finding: Published Agent Service Is Combined With Host Docker Socket Access<![CDATA[ ## Vulnerability Details **File Location**: `references/setup.md`, lines 80-102 **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Critical ### Vulnerable Code ```yaml # docker-compose.yml services: claudebox: image: psyb0t/claudebox:latest ports: - "8080:8080" environment: - CLAUDEBOX_API_MODE=1 - CLAUDEBOX_API_MODE_TOKEN=your-secret-token - CLAUDEBOX_AVAILABLE_MODELS=haiku,sonnet,opus,opusplan - CLAUDE_CODE_OAUTH_TOKEN=<YOUR_OAUTH_TOKEN> volumes: - ~/.claude:/home/aicode/.claude - /your/projects:/workspace - /var/run/docker.sock:/var/run/docker.sock ``` ```markdown Mounting `/var/run/docker.sock` grants host-level container control — anything that can reach the socket (including Claude itself, by design, or an attacker who compromises the API/MCP surface above) can create, inspect, or destroy any container on the host, not just this one. Only mount it on a host you trust, and only if you need docker-in-docker for this workload. ``` ### Technical Analysis The primary server-mode example both publishes the agent API on host port 8080 and mounts `/var/run/docker.sock` into the container. Access to the Docker daemon is effectively equivalent to host-root access in common Docker deployments. A process that can communicate with the socket can ask the daemon to create privileged containers, mount arbitrary host paths, inspect other containers, access container environment variables, or modify host files. Dropping Linux capabilities inside the claudebox container does not sufficiently mitigate this problem because operations requested through the socket are performed by the host Docker daemon. Docker access is not necessary for ordinary prompt processing, API operation, file handling, or model communication. Including it in the default server example therefore exceeds the minimum privileges needed for most declared functionality. ### Attack Path ...[truncated 1563 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove `/var/run/docker.sock` from the default API, MCP, Telegram, and cron deployment examples. 2. Make Docker access an explicit, separately documented opt-in available only when a task genuinely requires container management. 3. Run Docker-dependent workloads on an isolated worker or disposable virtual machine rather than the main host. 4. Where unavoidable, place a restrictive Docker socket proxy between the agent and daemon and allow only the minimum required API operations. 5. Do not permit container creation, privileged mode, arbitrary host mounts, daemon administration, secret inspection, or access to unrelated containers. 6. Authenticate all agent interfaces and restrict network access with loopback binding, firewall rules, private networks, or mutually authenticated TLS. 7. Use separate low-privilege workspaces and credentials for each caller. 8. Avoid mounting SSH keys, broad source trees, and the Docker socket into the same remotely controlled container. 9. Monitor Docker daemon events and alert on privileged container creation, unexpected bind mounts, or access from the claudebox workload. 10. Retain capability dropping, `no-new-privileges`, resource limits, and read-only filesystems as defense-in-depth, but do not treat them as substitutes for removing the socket. ]]>

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
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence

Findings (18)

Docker Socket Access

High

• Category: Privilege Escalation

Content

- **No auth when the per-mode token is unset.** `CLAUDEBOX_API_MODE_TOKEN` and `CLAUDEBOX_MCP_MODE_TOKEN` each default to no auth if unset — see [HTTP REST API mode](#http-rest-api-mode) and [MCP server mode](#mcp-server-mode) for details and the exact capability exposed unauthenticated in each case.
- **File operations include removal.** Deleting a workspace file has no undo — only remove files the current task created, and only when the user asked.
- **Mounting `/var/run/docker.sock` grants host-level container control** — see [Server modes (API / OpenAI / MCP / Telegram / Cron)](references/setup.md#server-modes-api--openai--mcp--telegram--cron) in `references/setup.md`, only do this on a host you trust.
- **`--permission-mode bypassPermissions` is on by default** — Claude has full, unrestricted shell/file/docker access inside the container by design (see [When NOT To Use](#when-not-to-use)). Don't treat the container boundary as a sandbox for untrusted input unless you've isolated the container itself.
- **Install script is piped from curl into bash by default** — a safer download-inspect-run alternative is documented alongside it; see [references/setup.md](references/setup.md#quick-install-cli-wrapper).

• Confidence: 98% confidence
• Finding: The skill explicitly documents mounting /var/run/docker.sock, which grants code inside the container effective control over the host Docker daemon and often root-equivalent host access. In this skill's context that danger is amplified because the container also runs an agent with bypassed permission checks and network-facing control surfaces, so remote prompt execution could become host compromise if the socket is mounted.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

- **Interactive shell** — `claudebox` drops you into the native `claude` CLI, container-backed, with automatic session resumption.
- **One-shot exec** — `claudebox "prompt" [flags]` — non-interactive, prompt in / structured output out, for scripts and CI.
- **HTTP REST API** — `CLAUDEBOX_API_MODE=1`. `POST /run`, async runs polled via `GET /run/result?runId=`, `GET/PUT/DELETE /files/{path}`, workspace isolation.
- **OpenAI-compatible endpoint** — same API-mode server, `/openai/v1/chat/completions` + `/openai/v1/models`. Streaming SSE, multi-turn, multimodal image input.
- **MCP server** — `CLAUDEBOX_MCP_MODE=1`, 5 tools over streamable HTTP. Mounts at `/mcp` on the API port when `CLAUDEBOX_API_MODE=1` is also set; otherwise runs standalone as a sidecar process on its own port (`CLAUDEBOX_MCP_MODE_PORT`, default `8081`), coexisting with Telegram/Cron/interactive mode.
- **Telegram bot** — `CLAUDEBOX_TELEGRAM_MODE=1`, per-chat isolated workspaces, file/photo/video/voice ingestion, slash commands.

• Confidence: 97% confidence
• Finding: The documented API includes writable and destructive file operations, including DELETE /files/{path}, on a service that may be unauthenticated when tokens are unset. In this skill's context, exposing a network service that can read, overwrite, and delete workspace files through user-controlled path parameters materially increases the chance of destructive misuse or cross-tenant tampering on shared deployments.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

curl -X DELETE "http://localhost:8080/files/myproject/src/old.py" -H "Authorization: Bearer token"
```

`DELETE /files/{path}` removes a file under `/workspace` (no undo). Confirm the target path first, only remove files the current task created, and on a shared instance don't touch another caller's workspace — see [Security & safety](#security--safety).

**Introspection and lifecycle:**

• Confidence: 96% confidence
• Finding: This snippet documents direct deletion of arbitrary files under /workspace via a path parameter. Even if traversal is blocked, a remotely reachable delete endpoint is dangerous in a system that may run without auth and may host multiple callers' workspaces, enabling data loss or sabotage within the permitted root.

Docker Socket Access

High

• Category: Privilege Escalation

Content

volumes:
      - ~/.claude:/home/aicode/.claude
      - /your/projects:/workspace
      - /var/run/docker.sock:/var/run/docker.sock
```

Mounting `/var/run/docker.sock` grants host-level container control — anything that can reach the socket (including Claude itself, by design, or an attacker who compromises the API/MCP surface above) can create, inspect, or destroy any container on the host, not just this one. Only mount it on a host you trust, and only if you need docker-in-docker for this workload.

• Confidence: 99% confidence
• Finding: Mounting `/var/run/docker.sock` into the container gives processes inside effectively root-equivalent control over the host's container runtime. The documentation itself acknowledges that Claude or anyone who compromises the exposed API/MCP surfaces could create or destroy arbitrary containers, so this is a real and severe breakout/environments-control risk.

Docker Socket Access

High

• Category: Privilege Escalation

Content

- /var/run/docker.sock:/var/run/docker.sock
```

Mounting `/var/run/docker.sock` grants host-level container control — anything that can reach the socket (including Claude itself, by design, or an attacker who compromises the API/MCP surface above) can create, inspect, or destroy any container on the host, not just this one. Only mount it on a host you trust, and only if you need docker-in-docker for this workload.

Add `CLAUDEBOX_MCP_MODE=1` + `CLAUDEBOX_MCP_MODE_TOKEN` alongside `CLAUDEBOX_API_MODE=1` to mount MCP on the same port. Set `CLAUDEBOX_TELEGRAM_MODE=1` + `CLAUDEBOX_TELEGRAM_MODE_TOKEN` for the bot, or `CLAUDEBOX_CRON_MODE=1` + `CLAUDEBOX_CRON_MODE_FILE` for the scheduler — any combination can run in the same container (e.g. cron + Telegram share one workspace).

• Confidence: 99% confidence
• Finding: This is the same dangerous Docker socket mount described in the compose example, and in context it sits alongside optional API/MCP/Telegram surfaces that may be remotely reachable. Combining remote execution features, permissive default permissions, and host Docker socket access creates a clear path from service compromise to host-level control.

External Transmission

Medium

• Category: Data Exfiltration

Content

```

```bash
curl -X POST http://localhost:8080/run \
  -H "Authorization: Bearer your-secret-token" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "what does this repo do", "workspace": "myproject"}'

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

Raw JSON-RPC for debugging (streamable-HTTP handshake — `initialize` then reuse the returned `mcp-session-id`):

```bash
curl -s -D - -X POST "http://localhost:8080/mcp/" \
  -H "Authorization: Bearer your-mcp-token" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Session Persistence

Medium

• Category: Rogue Agent

Content

Look at the git log for the last hour. Summarize commits.
  - name: every_30_seconds
    schedule: "*/30 * * * * *"     # 6-field sub-minute
    instruction: Write the current UTC timestamp to ./status.txt.
```

Per-job/root fields: `model`, `effort`, `system_prompt`, `append_system_prompt`, `telegram_chat_id` (requires `CLAUDEBOX_TELEGRAM_MODE_TOKEN`). Template vars usable in `instruction`/`system_prompt`/`append_system_prompt`: `{system_datetime}`, `{job_name}`. `effort` has the same no-effect caveat as [Telegram bot mode](#telegram-bot-mode) — accepted, not currently wired into the CLI invocation.

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

External Transmission

Medium

• Category: Data Exfiltration

Content

### Fire-and-poll a long refactor over HTTP

```bash
RUN_ID=$(curl -s -X POST http://localhost:8080/run -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"prompt": "refactor the auth module", "workspace": "myproject", "async": true}' | jq -r .runId)

until curl -s "http://localhost:8080/run/result?runId=$RUN_ID" -H "Authorization: Bearer $TOKEN" | jq -e '.status != "running"' >/dev/null; do

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Session Persistence

Medium

• Category: Rogue Agent

Content

The installer pulls the image, generates an ed25519 SSH key at `~/.ssh/claudebox/id_ed25519` for git operations inside the container, creates `~/.claude`, and installs the wrapper to `/usr/local/bin/claudebox` (override with `CLAUDEBOX_INSTALL_DIR` / `CLAUDEBOX_BIN_NAME`). Add the generated public key to GitHub/GitLab for git push/pull to work from inside the container.

Manual setup without piping to bash: `mkdir -p ~/.claude`, generate the SSH key yourself, `docker pull psyb0t/claudebox:latest` (or `:latest-full`), then fetch `wrapper.sh` and install it as your `claudebox` binary.

## Image Variants

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 80% confidence
• Finding: The manual setup instructs users to pull `psyb0t/claudebox:latest`, which is mutable and can change over time without review. Using a floating image reference undermines reproducibility and can expose users to a malicious or compromised image update.

Session Persistence

Medium

• Category: Rogue Agent

Content

| DB clients | — | sqlite3, psql, mysql, redis-cli |
| Shell utils | — | ripgrep, bat, exa, fd-find, ag, htop, tmux, shellcheck, shfmt |

Minimal has passwordless sudo, so Claude installs whatever else it needs via `apt-get`/`pip`/`npm` on the fly — smaller pull, slower first task. Use `/aicodebox-init.d/*.sh` hooks to pre-install tooling on first container create instead of burning tokens on package management.

`CLAUDEBOX_FULL=1` at install time bakes the full-variant choice into the wrapper permanently; at runtime it overrides per-invocation. Pre-v2 `CLAUDEBOX_MINIMAL=1` is a no-op (minimal is already the default).

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence
• Finding: Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 90% confidence
• Finding: The example uses `npx -y @some/mcp-server` without pinning a package version, so each invocation may fetch whatever the registry serves at that time. In this context, MCP servers are explicitly used to reach external systems, so an upstream compromise or malicious new release could lead to arbitrary code execution inside the claudebox environment.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 90% confidence
• Finding: This second example repeats the same unpinned `npx` pattern, which allows supply-chain drift and execution of unexpected code from the npm registry. Because claudebox can mount sensitive host resources and pass credentials into the container, the risk is amplified beyond a normal developer workstation example.

Natural-Language Policy Violations

Medium

• Confidence: 92% confidence
• Finding: The note says `--permission-mode bypassPermissions` is the default and later references `RunRequest.extra_args` to override behavior, but elsewhere the file repeatedly frames interaction with fixed command phrases like `claudebox "do stuff"` and operational text entirely in English without any stated language choice. More directly, the skill never offers locale selection while describing chat and cron/Telegram interactions that are presented as the default user interface, which can amount to an implicit forced language policy when no opt-in or alternative is documented.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 82% confidence
• Finding: The management section tells users to update with `docker pull psyb0t/claudebox:latest`, again relying on a mutable tag. That creates a supply-chain risk where future pulls may introduce unexpected or malicious code into a privileged tooling container.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 82% confidence
• Finding: The `latest-full` tag is also mutable, so users pulling updates receive whatever image is currently published under that name. In a container designed to run code and potentially access host-mounted resources, mutable tags increase the blast radius of a compromised registry or publisher account.

Static analysis

No suspicious patterns detected.