Openclaw Devboxes Skill

• Outcome: Review
• Latest audit: Sep 10, 2026 · 7:45 PM UTC
• Version: 1.4.0

Overview

This skill has a coherent devbox purpose, but its setup grants broad host and network authority with unsafe defaults that users should review carefully before installing.

Install only in a dedicated, non-shared environment where host Docker control, public devbox URLs, and Cloudflare/GitHub token exposure are acceptable. Avoid chmod 666 on the Docker socket, avoid broad tokens, put VSCode/VNC behind authentication, and prefer pinned images and isolated infrastructure before using this skill.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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 (6)

T09 · Insecure Skill Coding Practices

Error

• Location: docker/entrypoint.sh:61
• Finding: Externally Routed VSCode and VNC Services Disable Authentication<![CDATA[ ## Vulnerability Details **File Location**: `docker/entrypoint.sh:61-77`; externally exposed by `docker/devbox-init.sh:86-103` and `docker/devbox-init.sh:151-184` **Vulnerability Type**: Unauthenticated remote development environment **Risk Level**: Critical ### Vulnerable Code ```bash if [ "${ENABLE_VNC:-false}" = "true" ]; then VNC_PORT=5900 x11vnc -display :1 -rfbport "${VNC_PORT}" -shared -forever -nopw -localhost & websockify --web=/usr/share/novnc "${NOVNC_PORT}" "localhost:${VNC_PORT}" > /dev/null 2>&1 & echo "[devbox] noVNC ready on port ${NOVNC_PORT}" fi if [ "${ENABLE_VSCODE:-false}" = "true" ]; then "${OPENVSCODE_SERVER_ROOT}/bin/openvscode-server" \ --host 0.0.0.0 \ --port "${VSCODE_PORT}" \ --without-connection-token \ --default-folder /workspace \ > /dev/null 2>&1 & echo "[devbox] VSCode ready on port ${VSCODE_PORT}" fi ``` The services are subsequently assigned externally reachable hostnames: ```bash cat > "${CF_CONFIG_DIR}/config.yml" << CFEOF ingress: - hostname: vscode-${DEVBOX_ID}.${DEVBOX_DOMAIN} service: http://localhost:${VSCODE_PORT} - hostname: novnc-${DEVBOX_ID}.${DEVBOX_DOMAIN} service: http://localhost:${NOVNC_PORT} ``` ### Technical Analysis OpenVSCode Server is launched with `--without-connection-token`, explicitly disabling its connection-token authentication. VNC is launched with `-nopw`, explicitly disabling password authentication. The initialization script then creates public Traefik or Cloudflare Tunnel routes for both services. No authentication middleware, identity-aware access policy, source-address restriction, or independently generated session secret is configured in the audited project. Sequential devbox identifiers also make hostnames such as `vscode-1.example.com` easier to predict. ### Attack Path 1. An attacker identifies the configured base domain through DNS, documentation, certificate transparency, or normal reconnaissa ...[truncated 905 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove `--without-connection-token` and require a cryptographically random, per-devbox OpenVSCode connection token. - Remove `-nopw` and configure a strong, independently generated VNC credential. - Put both services behind an identity-aware proxy, such as Cloudflare Access or authenticated Traefik middleware. - Restrict access to approved users, source networks, or VPN identities. - Use non-sequential, high-entropy route identifiers rather than predictable numeric IDs. - Do not return service URLs until authentication and routing policies have been applied successfully. - Add automated tests that reject configurations exposing VSCode or noVNC without authentication. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:78
• Finding: World-Writable Docker Socket Grants Host-Equivalent Privileges<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:78-97`; repeated in `README.md:60-75` **Vulnerability Type**: Excessive host privilege and unsafe Docker daemon authorization **Risk Level**: Critical ### Vulnerable Code ```bash which docker docker version ``` If Docker is unavailable, the Skill instructs the user to start OpenClaw with: ```text -v /usr/bin/docker:/usr/bin/docker:ro -v /var/run/docker.sock:/var/run/docker.sock ``` It then requires the following host-level permission change: ```bash chmod 666 /var/run/docker.sock ``` ### Technical Analysis Possession of write access to the Docker daemon socket is normally equivalent to host-root access. A Docker client can ask the daemon to create privileged containers, mount arbitrary host directories, access host namespaces, or overwrite sensitive host files. Setting mode `0666` allows every local user and process to communicate with the daemon, rather than granting access only to a narrowly scoped service identity. Mounting the socket into an Agent-controlled environment further increases exposure because prompt-driven execution, compromised dependencies, or another application flaw can reach this host-level control plane. ### Attack Path 1. An attacker obtains code execution in the OpenClaw container or any other local context allowed to access the world-writable socket. 2. The attacker connects to `/var/run/docker.sock`. 3. The attacker creates a container that mounts the host root filesystem, for example at `/host`. 4. The attacker reads host secrets or modifies files such as SSH configuration, service definitions, or application data. 5. The attacker can establish host-level control under the privileges of the Docker daemon. ### Impact Assessment Exploitation can result in complete host compromise, including access to all containers, host files, service credentials, application data, and network resources available to the Docker daemon. The attacker may also create privileged wor ...[truncated 116 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Never set the Docker socket to mode `0666`. - Place container lifecycle operations behind a narrowly scoped, authenticated service or Docker socket proxy. - Allow only the specific API operations and image/network/bind configurations required to create devboxes. - Run rootless Docker or another isolated container runtime where feasible. - If group-based access is unavoidable, use a dedicated group with tightly controlled membership and document that it remains a high-privilege boundary. - Separate prompt-driven Agent execution from the component holding Docker privileges. - Enforce policies that reject privileged containers, host namespace sharing, arbitrary bind mounts, and unapproved images. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:226
• Finding: GitHub and Cloudflare Credentials Are Exposed to Devbox Processes<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:226-252` and `SKILL.md:319-335` **Vulnerability Type**: Plaintext sensitive credentials in broadly accessible environment variables **Risk Level**: High ### Vulnerable Code ```json "env": { "ENABLE_VNC": "true", "ENABLE_VSCODE": "true", "DEVBOX_DOMAIN": "{domain}", "APP_TAG_1": "app1", "APP_TAG_2": "app2", "APP_TAG_3": "app3", "APP_TAG_4": "app4", "APP_TAG_5": "app5", "GITHUB_TOKEN": "{github_token}", "ROUTING_MODE": "{traefik|cloudflared}", "CF_TUNNEL_TOKEN": "{cf_tunnel_token}", "CF_API_TOKEN": "{cf_api_token}", "CF_ZONE_ID": "{cf_zone_id}", "CF_TUNNEL_ID": "{cf_tunnel_id}" } ``` The spawned Agent is expressly told that the token is available in its environment: ```python task=f"... GitHub token is in $GITHUB_TOKEN. ALWAYS use /workspace as the working directory! ..." ``` The project documentation also permits repository-controlled setup scripts to run with devbox environment variables available. ### Technical Analysis The design injects long-lived GitHub and Cloudflare credentials into the general process environment of each development container. Environment variables are inherited by child processes and can be read by repository setup scripts, package lifecycle hooks, IDE extensions, debuggers, and other processes operating under the same user. The Cloudflare API token is only needed for a narrow DNS-registration operation, but it remains exposed throughout the devbox session. The GitHub token may similarly remain present after cloning is complete. This violates least exposure and makes supply-chain or repository-level compromise sufficient to steal infrastructure credentials. ### Attack Path 1. A user clones an untrusted or compromised repository into the devbox. 2. A setup script, package installation hook, build tool, or IDE extension executes. 3. The code reads `GITHUB_TOKEN`, `CF_API_TOKEN`, or `CF_TUNNEL_TOKEN` from the process environment. 4. The cod ...[truncated 679 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not inject infrastructure credentials into the general devbox environment. - Perform DNS registration in a separate, minimal helper service and never pass the Cloudflare API token to the development container. - Use short-lived GitHub credentials with repository-specific, read-only permissions. - Use a credential broker or isolated secret mount accessible only to the process that needs the secret. - Remove credentials immediately after the narrowly scoped operation completes. - Prevent project setup scripts and package hooks from inheriting infrastructure credentials. - Rotate existing credentials after migrating to the safer design. - Log credential use without logging credential values, and alert on use outside expected operations. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: docker/devbox-init.sh:10
• Finding: Unsanitized Configuration Values Are Evaluated as Shell and Python Source<![CDATA[ ## Vulnerability Details **File Location**: `docker/devbox-init.sh:10-69` and `docker/devbox-init.sh:151-184` **Vulnerability Type**: Command injection through generated executable source **Risk Level**: High ### Vulnerable Code The first argument and environment values are written into a shell file without escaping, after which that file is sourced: ```bash if [ -z "${1:-}" ]; then echo "[devbox-init] ERROR: Missing argument. Usage: devbox-init <id>" exit 1 fi export DEVBOX_ID="$1" cat > /etc/devbox.env << EOF export DEVBOX_ID=$DEVBOX_ID export DEVBOX_DOMAIN=$DEVBOX_DOMAIN export VSCODE_URL=$VSCODE_URL export NOVNC_URL=$NOVNC_URL $(for i in 1 2 3 4 5; do tag_var="APP_TAG_$i" port_var="APP_PORT_$i" echo "export APP_TAG_$i=${!tag_var}" echo "export APP_PORT_$i=${!port_var}" echo "export APP_URL_$i=$(eval echo \$APP_URL_$i)" done) EOF cp /etc/devbox.env /etc/profile.d/devbox.sh grep -q '/etc/devbox.env' /root/.bashrc 2>/dev/null || echo ". /etc/devbox.env" >> /root/.bashrc . /etc/devbox.env ``` The same values are interpolated directly into Python source: ```bash python3 -c " import sys devbox_id = '${DEVBOX_ID}' container = '${CONTAINER_NAME}' domain = '${DEVBOX_DOMAIN}' services = {'vscode': ${VSCODE_PORT}, 'novnc': ${NOVNC_PORT}} tags = ['${APP_TAG_1}','${APP_TAG_2}','${APP_TAG_3}','${APP_TAG_4}','${APP_TAG_5}'] ports = [${APP_PORT_1},${APP_PORT_2},${APP_PORT_3},${APP_PORT_4},${APP_PORT_5}] for tag, port in zip(tags, ports): services[tag] = port ``` ### Technical Analysis `DEVBOX_ID`, domain, tags, URLs, and port values are treated as trusted source text rather than data. Shell metacharacters placed in a value written to `/etc/devbox.env` can introduce command substitutions, separators, or additional commands when the file is sourced. The file is also loaded by future root shells through `/root/.bashrc`. In the Traefik branch, a single quote in a string value can terminate its Python literal and inject arbi ...[truncated 1426 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Require `DEVBOX_ID` to match a strict numeric expression such as `^[0-9]+$`. - Validate domains as DNS names, app tags against a conservative hostname-label allowlist, and ports as integers within the permitted range. - Do not generate and source shell code to store data. - If a shell-compatible file is unavoidable, serialize each value with `printf '%q'`; prefer a non-executable data format with a safe parser. - Remove the unnecessary `eval` used while resolving application URL variables. - Pass Python values through `sys.argv`, standard input, or environment variables and parse them as data. - Generate YAML through a safe serialization library rather than hand-built executable templates. - Avoid automatically sourcing generated files from `/root/.bashrc`. - Add regression tests containing quotes, command substitutions, newlines, semicolons, and Python delimiters. ]]>

T08 · Insecure Dependencies

Error

• Location: SKILL.md:216
• Finding: Runtime Components Are Retrieved Through Mutable and Unpinned References<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:216-220`; related installer guidance in `README.md:120-128` and dependency declarations in `package.json:10-16` **Vulnerability Type**: Mutable third-party dependency and container image references **Risk Level**: High ### Vulnerable Code ```bash docker pull ghcr.io/adshrc/openclaw-devbox:latest ``` The installation guidance similarly uses a mutable package tag: ```bash npx clawhub@latest install devboxes ``` Release plugins are declared without exact versions, and no lockfile is present in the supplied directory: ```json "plugins": [ "@semantic-release/commit-analyzer", "@semantic-release/release-notes-generator", "@semantic-release/npm", "@semantic-release/github" ] ``` ### Technical Analysis The `latest` image and package tags are mutable. The bytes executed during a future installation can therefore differ from those reviewed during this audit without any change to this repository. The container image is especially sensitive because it hosts the IDE, receives credentials, and runs startup scripts. The unversioned release plugin declarations and absence of a supplied lockfile also prevent deterministic dependency resolution if these packages are installed. This creates a supply-chain trust dependency on future registry state and upstream account security. ### Attack Path 1. An upstream account, registry, image repository, or release process is compromised, or a later release introduces unsafe behavior. 2. The mutable `latest` reference is updated to point to the altered artifact. 3. A user follows onboarding and pulls or executes the mutable artifact. 4. The altered component runs in the devbox or installation environment. 5. It can access source code, network resources, and credentials made available to that environment. ### Impact Assessment A compromised image can execute arbitrary code in every newly created devbox, capture GitHub or Cloudflare credentials, tamper with re ...[truncated 257 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin the container image by immutable digest, for example `image@sha256:<verified-digest>`. - Pin the installer to an exact reviewed version instead of `@latest`. - Specify exact dependency versions and commit a lockfile. - Use reproducible, lockfile-enforced installation in continuous integration. - Verify image signatures and provenance before deployment. - Scan pinned images and packages for known vulnerabilities. - Review updates explicitly and change pins only after validation rather than following mutable tags automatically. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:180
• Finding: Onboarding Disables Main-Agent Isolation and Enables Global Session Visibility<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:180-212` and `SKILL.md:254-258` **Vulnerability Type**: Excessive Agent permissions and cross-session access **Risk Level**: High ### Vulnerable Code The onboarding instructions disable sandboxing for the main Agent: ```bash node /app/openclaw.mjs config set agents.list[{index}].sandbox.mode "off" ``` The example configuration likewise creates an unsandboxed default Agent: ```json { "id": "main", "default": true, "subagents": { "allowAgents": [ "devbox" ] }, "sandbox": { "mode": "off" } } ``` Onboarding then globally enables Agent communication and visibility across all sessions: ```bash node /app/openclaw.mjs config set tools.agentToAgent.enabled true node /app/openclaw.mjs config set tools.sessions.visibility "all" ``` ### Technical Analysis The Skill needs a mechanism to request devbox creation, but it broadens permissions beyond that narrow operation. Disabling the main Agent sandbox exposes its full filesystem and tool context. Setting session visibility to `all` removes session-level isolation, while globally enabling Agent-to-Agent communication increases the number of paths through which one Agent may influence another. These settings are particularly sensitive because the same main Agent is expected to have access to the host Docker socket. A compromise or instruction-manipulation event affecting any reachable Agent therefore has a larger blast radius than a session-scoped configuration would permit. ### Attack Path 1. An attacker compromises or manipulates an Agent or session through malicious repository content, an exposed service, or another application flaw. 2. The compromised context uses globally enabled Agent-to-Agent communication or all-session visibility to inspect or influence another session. 3. It reaches or manipulates the unsandboxed main Agent. 4. The main Agent's filesystem, tools, and Docker-management capability are abused. 5. The ...[truncated 436 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Keep the main Agent sandbox enabled unless a narrowly documented operation strictly requires otherwise. - Delegate Docker operations to a minimal service with a constrained API rather than granting direct Docker access to the main Agent. - Use explicit per-Agent allowlists and session-scoped communication. - Retain session isolation instead of setting global visibility to `all`. - Require authorization for every devbox lifecycle request and bind each request to its originating session. - Separate infrastructure credentials and management tools from conversational Agent contexts. - Audit and alert on cross-Agent messages, session access, and container lifecycle operations. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger

Findings (36)

Docker Socket Access

High

• Category: Privilege Escalation

Content

The OpenClaw container needs access to the Docker daemon on the host to manage devbox containers. Start your OpenClaw container with these additional flags:

```bash
-v /var/run/docker.sock:/var/run/docker.sock
-v /usr/bin/docker:/usr/bin/docker:ro
```

• Confidence: 98% confidence
• Finding: Mounting `/var/run/docker.sock` into the application container grants it direct control over the host Docker daemon. Any bug, prompt-injection path, or compromised subcomponent in the agent can then create privileged containers, mount host paths, and fully escape the intended sandbox.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: Instructing users to run `chmod 666 /var/run/docker.sock` makes the Docker control socket world-writable. Any local user or process that can reach that socket can gain effectively root-level control of the host by starting privileged containers, mounting host filesystems, or extracting secrets.

Docker Socket Access

High

• Category: Privilege Escalation

Content

On the host, set the correct permissions to make the Docker socket accessible:

```bash
chmod 666 /var/run/docker.sock
```

> **Note:** This must be done on the host machine before starting the OpenClaw container. If the container is already running, restart it after adding the volume mounts (e.g. docker-compose.yml)

• Confidence: 99% confidence
• Finding: Making `/var/run/docker.sock` world-writable compounds the existing Docker socket risk by allowing any local principal to issue Docker API calls. This transforms a dangerous privileged integration into a trivially exploitable host-compromise condition.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

On the host, set the correct permissions to make the Docker socket accessible:

```bash
chmod 666 /var/run/docker.sock
```

> **Note:** This must be done on the host machine before starting the OpenClaw container. If the container is already running, restart it after adding the volume mounts (e.g. docker-compose.yml)

• Confidence: 95% confidence
• Finding: The README instructs a highly dangerous host command (`chmod 666`) on a sensitive control interface. In an agent-assisted setup, such guidance can directly lead users to weaken core system protections, enabling abuse by other local processes or compromised tools.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

| `/home/node/.openclaw/.devbox-counter` | `/shared/.devbox-counter` | ID counter                                |
| `/home/node/.openclaw/traefik/configs` | `/traefik`                | Traefik route configs (Traefik mode only) |

> **Important:** Both paths must be writable by sandbox containers (UID 1000). The counter file needs `chmod 666`, and the Traefik devboxes dir should be owned by `1000:1000`.

## Self-Registration

• Confidence: 80% confidence
• Finding: The documentation normalizes world-writable shared files for convenience, which is an unsafe default and can be abused by other containers or users to tamper with shared state. Although not host-compromise by itself, it weakens integrity boundaries and can facilitate cross-session interference.

Credential Access

High

• Category: Privilege Escalation

Content

nvm install && nvm use
npm install

cp template.env .env
sed -i "s/PORT=.*/PORT=$APP_PORT_1/" .env

tmux new -d -s my-server "source /root/.nvm/nvm.sh; nvm use; npm run dev; exec \$SHELL"

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

nvm install && nvm use
npm install

cp template.env .env
sed -i "s/PORT=.*/PORT=$APP_PORT_1/" .env

tmux new -d -s my-server "source /root/.nvm/nvm.sh; nvm use; npm run dev; exec \$SHELL"

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

| ------------------------------ | --------------------- | --------------------------------------------- |
| `/home/node/.openclaw/traefik` | `/traefik`            | Route configs (only if using Traefik routing) |

**Important:** Due to OpenClaw Security measures, all user capabilites are dropped by default. So even root (in the devbox) has no write access to bind mounts, and can only read from them. The only solution currently is `chmod 777` on the host path that is mapped to `/home/node/.openclaw/traefik`.

### Known Paths

• Confidence: 95% confidence
• Finding: The skill recommends an unsafe parameter/permission change (`chmod 777`) as the operational fix for a mount-write limitation. This is dangerous because it weakens host filesystem protections to make the workflow succeed, enabling tampering with shared routing files from less-trusted contexts.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The onboarding flow instructs users to mount the Docker socket and relax socket permissions with `chmod 666` without a strong safety warning. Docker socket access effectively grants root-equivalent control over the host, and world-writable socket permissions further widen the attack surface to any local process able to reach it.

Docker Socket Access

High

• Category: Privilege Escalation

Content

```
-v /usr/bin/docker:/usr/bin/docker:ro
-v /var/run/docker.sock:/var/run/docker.sock
```

and that they need to set `chmod 666 /var/run/docker.sock` manually on the host, so that the OpenClaw container can work with it.

• Confidence: 99% confidence
• Finding: Mounting `/var/run/docker.sock` into the main agent container gives the skill the ability to control Docker on the host, which is effectively root-equivalent access. In the context of a skill that can spawn containers, inspect mounts, and write configuration, this dramatically increases the blast radius of any misuse, prompt injection, or compromise.

Docker Socket Access

High

• Category: Privilege Escalation

Content

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

and that they need to set `chmod 666 /var/run/docker.sock` manually on the host, so that the OpenClaw container can work with it.

The OpenClaw container needs to be restarted then. After that, they can ask to set up the devbox skill again.

• Confidence: 99% confidence
• Finding: The Docker socket reference here is coupled with advice to relax permissions, making already dangerous host control even easier to abuse. Any process within reach of the socket could create privileged containers, mount the host filesystem, or extract secrets from other containers.

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: The skill directs collection of GitHub and Cloudflare tokens but does not warn the user that these secrets will be persisted into configuration and environment variables accessible to spawned environments. This creates a substantial risk of credential exposure, accidental logging, and later misuse by subagents or processes inside the devbox.

Ssd 3

High

• Confidence: 98% confidence
• Finding: The onboarding process explicitly collects sensitive tokens for later operational use, which is a direct secret-handling risk. In this skill's context, those secrets are not transient input to a single command but are intended to become persistent infrastructure credentials, magnifying exposure if the skill, config, logs, or spawned environments are compromised.

Docker Socket Access

High

• Category: Privilege Escalation

Content

Store the value as `HOST_OPENCLAW_PATH`. If `HOST_OPENCLAW_PATH` is a "system directory", OpenClaw will not be able to spawn a devbox.

System directories are: /etc, /private/etc, /proc, /sys, /dev, /root, /boot, /run, /var/run, /private/var/run, /var/run/docker.sock, /private/var/run/docker.sock and /run/docker.sock.

If the `HOST_OPENCLAW_PATH` is such a "system directory", abort here and tell the user they need to change their OpenClaw container setup to use a host path for OpenClaw data that is not a system directory. For example, they can create a directory like `/home/openclaw` or `/opt/openclaw` on the host.

• Confidence: 90% confidence
• Finding: Potential security issue detected. Manual review is recommended.

Ssd 3

High

• Confidence: 96% confidence
• Finding: The skill stores Cloudflare and related credentials as retained values for ongoing use across the devbox environment. Persistent storage of infrastructure secrets increases blast radius because any later compromise of the agent, config store, or container environment can expose credentials that permit external DNS and tunnel manipulation.

Ssd 3

High

• Confidence: 99% confidence
• Finding: The devbox agent configuration injects GitHub and Cloudflare secrets directly into container environment variables. Environment variables are commonly exposed to processes, subprocesses, debug tooling, crash reports, and sometimes UIs, making them an unsafe place for broad-scoped credentials in multi-process dev environments.

YARA rule 'backdoor_persistence': Backdoor persistence with malicious payloads (shell commands, SSH key injection, hidden root users) [malware]

High

• Category: YARA Match

Content

L
export NOVNC_URL=$NOVNC_URL
$(for i in 1 2 3 4 5; do
    tag_var="APP_TAG_$i"
    port_var="APP_PORT_$i"
    echo "export APP_TAG_$i=${!tag_var}"
    echo "export APP_PORT_$i=${!port_var}"
    echo "export APP_URL_$i=$(eval echo \$APP_URL_$i)"
done)
EOF

# Make env vars available in all new shells
cp /etc/devbox.env /etc/profile.d/devbox.sh
grep -q '/etc/devbox.env' /root/.bashrc 2>/dev/null || echo ". /etc/devbox.env" >> /root/.bashrc

# Source into the current shell
. /etc/devbox.env

echo "[devbox-init] Env files written"

########################################
# Routing: Traefik or Cloudflare Tunnel
########################################
: "${ROUTING_MODE:=traefik}"

if [ "$ROUTING_MODE" = "cloudflared" ]; then
    ########################################
    # Cloudflare Tunnel routing
    ########################################
    echo "[devbox-init] Routing mode: cloudflared"

    if [ -z "${CF_TUNNEL_TOKEN:-}" ]; then
        echo "[devbox-init] ERROR: CF_TUNNEL_TOKEN i

• Confidence: 75% confidence
• Finding: YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

Context-Inappropriate Capability

Medium

• Confidence: 96% confidence
• Finding: The documentation requires mounting the host Docker socket into the OpenClaw container and making it accessible so the skill can create and manage containers. Docker socket access is effectively root-equivalent on the host, so any compromise of the agent or skill flow can lead to arbitrary container creation, filesystem mounts, secret extraction, and host takeover far beyond ordinary devbox management.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

On the host, set the correct permissions to make the Docker socket accessible:

```bash
chmod 666 /var/run/docker.sock
```

> **Note:** This must be done on the host machine before starting the OpenClaw container. If the container is already running, restart it after adding the volume mounts (e.g. docker-compose.yml)

• Confidence: 97% confidence
• Finding: The documented `chmod 666 /var/run/docker.sock` requires privileged host modification and grants universal write access to the Docker daemon. Because the Docker daemon can launch containers with arbitrary mounts and privileges, this is effectively a host root-compromise pathway.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The README directs storage of sensitive Cloudflare credentials and tunnel tokens in agent configuration without emphasizing secure secret handling. If the agent config is exposed through logs, workspace files, backups, or other skills, attackers could take over DNS and tunnel infrastructure for the user's domain.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 78% confidence
• Finding: The README instructs installation via `npx clawhub@latest install devboxes`, which pulls and executes the latest published package without pinning a version or integrity. That creates a supply-chain risk: if the upstream package is compromised or a breaking/malicious release is published, users may execute unreviewed code during installation.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

| `/home/node/.openclaw/.devbox-counter` | `/shared/.devbox-counter` | ID counter                                |
| `/home/node/.openclaw/traefik/configs` | `/traefik`                | Traefik route configs (Traefik mode only) |

> **Important:** Both paths must be writable by sandbox containers (UID 1000). The counter file needs `chmod 666`, and the Traefik devboxes dir should be owned by `1000:1000`.

## Self-Registration

• Confidence: 80% confidence
• Finding: Recommending `chmod 666` on the shared counter file creates unnecessary world-writable state shared across containers. While less severe than the Docker socket, it permits tampering with ID assignment and can enable denial of service, collisions, or interference between devboxes.

Unsafe Defaults

Medium

• Category: Tool Misuse

Content

## Important Notes

- Sandbox containers run with **all Linux capabilities dropped** (`CapDrop: ALL`). Bind-mounted files/dirs must be world-writable.
- The devbox working directory is always `/workspace`.

## License

• Confidence: 86% confidence
• Finding: The README states that bind-mounted files and directories must be world-writable due to dropped capabilities, establishing an unsafe operational default. World-writable mounts increase the chance of tampering, accidental overwrite, and cross-container interference, especially in a multi-tenant or partially trusted environment.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 87% confidence
• Finding: The skill performs sensitive actions including shell execution, file writes, Docker interaction, and configuration changes, yet it declares no explicit tool scope or permission boundaries. That increases the chance the skill is invoked with broader capabilities than necessary and makes risky operations less visible to operators.

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The activation description is broad enough to trigger the skill for common 'setup' or 'manage' requests, including first-time onboarding that performs highly privileged host and Docker operations. Over-broad activation increases the risk that an agent routes ordinary user requests into a dangerous administrative workflow without sufficient confirmation.

Static analysis

No suspicious patterns detected.