Back to skill

Security audit

pibox

Security checks for vulnerabilities and agentic risk

Overview

Review before installing: this skill documents a networked coding-agent container that can run prompts, modify or delete workspace files, and is commonly launched with broad networking and an unpinned Docker image.

Install only if you are comfortable running a long-lived coding-agent service against the mounted workspace. Pin and verify the Docker image, avoid host networking unless truly needed, bind services to localhost or a trusted proxy, set nonempty API and MCP tokens, prefer Authorization headers over URL tokens, mount the smallest workspace needed, and treat delete and cron capabilities as administrative actions.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Findings (3)

T08 · Insecure Dependencies

Warning
Location
references/setup.md:13
Finding
Mutable Third-Party Container Image Is Downloaded and Executed<![CDATA[ ## Vulnerability Details **File Location**: `references/setup.md:13-20` **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium ### Vulnerable Code ```bash docker run -it --rm \ -e ANTHROPIC_AUTH_TOKEN=your-token \ -e ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic \ -e ANTHROPIC_MODEL=glm-4.6 \ -v "$PWD/workspace:/workspace" \ psyb0t/pibox:latest ``` The same mutable image reference is used throughout `SKILL.md` and `references/setup.md`, including API, Telegram, cron, one-shot, and Docker Compose examples. ### Technical Analysis The installation instructions execute `psyb0t/pibox:latest`, a mutable image tag hosted under a third-party namespace. A mutable tag can resolve to different image content over time, meaning the effective executable payload may change after the Skill has been reviewed. The project contains no Dockerfile, immutable image digest, signature-verification procedure, checksum, or reproducible-build instructions that would allow users to verify that the downloaded image matches the version covered by this audit. The container receives sensitive and privileged resources in the documented workflows, including: - LLM provider API keys or bearer tokens. - Telegram bot credentials. - API and MCP bearer tokens. - Read and write access to a host-mounted workspace. - Network access, including host networking in some examples. - The ability to execute an autonomous coding Agent. Although no malicious implementation was found in the audited Markdown files, the unpinned dependency creates a supply-chain trust boundary outside the reviewed project. ### Attack Path 1. An attacker compromises the container registry account, image publishing pipeline, upstream source repository, or maintainer credentials. 2. The attacker publishes a modified image under `psyb0t/pibox:latest`. 3. A user follows the documented `docker run` command or executes the documented `docker pull psyb0t/pibox:latest` update command. ...[truncated 1194 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace every mutable tag with an immutable, verified image digest: ```bash docker run ... psyb0t/pibox@sha256:VERIFIED_DIGEST ``` 2. Publish the exact source revision and build configuration corresponding to the approved digest. 3. Provide container-signature verification instructions using a mechanism such as Cosign. 4. Use an automated dependency-update process that submits digest changes for security review instead of silently tracking `latest`. 5. Run the container as a non-root user and use a read-only root filesystem where compatible. 6. Mount only the minimum required workspace path and use a read-only mount for tasks that do not require modification. 7. Supply secrets through Docker secrets or another dedicated secret manager rather than ordinary command-line environment configuration where possible. 8. Apply outbound network restrictions so the container can reach only the configured model provider and other explicitly required services. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:188
Finding
MCP Bearer Token May Be Transmitted in a URL Query Parameter<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:188` **Vulnerability Type**: `T09: Insecure Skill Coding Practices` **Risk Level**: Medium ### Vulnerable Code ```text Auth: `PIBOX_MCP_MODE_TOKEN=<token>` — bearer via `Authorization: Bearer …`, or `?apiToken=…` query param for clients that can't set headers. Empty = no auth. **No fallback to `PIBOX_API_MODE_TOKEN`.** ``` ### Technical Analysis The Skill permits the MCP bearer credential to be supplied through the `apiToken` URL query parameter. Query strings are frequently retained in locations where authorization headers are normally omitted or redacted, including: - Reverse-proxy and web-server access logs. - Application and observability logs. - Network monitoring telemetry. - Browser or client history. - Copied URLs, screenshots, and support diagnostics. - Error reports and tracing systems. The token protects an MCP interface that exposes `run_prompt`, `list_files`, `read_file`, `write_file`, and `delete_file`. Consequently, leakage is not limited to read-only metadata access: it may grant Agent execution and destructive workspace operations. TLS protects the request while it is in transit but does not prevent the URL from being stored by clients, servers, proxies, or monitoring systems. ### Attack Path 1. A client unable to set an authorization header connects using a URL such as `https://host/mcp?apiToken=SECRET`. 2. A reverse proxy, MCP service, client, or telemetry platform records the complete request URL. 3. An operator, attacker, support recipient, or compromised logging system obtains the recorded URL. 4. The attacker extracts the bearer token from the query string. 5. The attacker replays the token against the MCP endpoint before it is revoked or rotated. 6. The attacker invokes Agent prompts or file tools using the privileges associated with that token. ### Impact Assessment Successful exploitation may permit: - Arbitrary prompts to be submitted to the coding Agent. - Lis ...[truncated 436 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove query-parameter authentication and require: ```http Authorization: Bearer TOKEN ``` 2. Treat clients that cannot set authorization headers as unsupported rather than weakening credential handling. 3. If temporary legacy compatibility is unavoidable: - Disable query-token support by default. - Require an explicit server-side opt-in. - Use short-lived, narrowly scoped tokens. - Redact the `apiToken` parameter in application, proxy, tracing, and monitoring logs. - Prevent request URLs containing tokens from appearing in errors or diagnostics. 4. Add token expiration, rotation, and revocation support. 5. Use separate credentials for each client so an exposed token can be revoked without affecting every integration. 6. Document that any token previously used in a URL should be considered exposed and rotated. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
references/setup.md:27
Finding
Host Networking Grants the Agent Container Unnecessary Network Reachability<![CDATA[ ## Vulnerability Details **File Location**: `references/setup.md:27-39` **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: Medium ### Vulnerable Code ```bash docker run -d --name pibox --network host \ -e PIBOX_API_MODE=1 \ -e PIBOX_API_MODE_TOKEN=your-secret \ -e PIBOX_AVAILABLE_MODELS=glm-4.6,glm-4.5-air \ -e PIBOX_MCP_MODE=1 \ -e PIBOX_MCP_MODE_TOKEN=your-mcp-secret \ -e ANTHROPIC_AUTH_TOKEN=your-token \ -e ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic \ -e ANTHROPIC_MODEL=glm-4.6 \ -v "$PWD/workspace:/workspace" \ psyb0t/pibox:latest ``` Equivalent `--network host` guidance also appears in `SKILL.md` and in the LiteLLM setup example. ### Technical Analysis Docker host networking removes the network namespace isolation ordinarily provided by Docker bridge networking. The container shares the host's network namespace and can directly access services reachable through host interfaces, including services listening only on host loopback. Host networking is broader than necessary for the declared API functionality. The server can instead be exposed through explicit port publishing. The risk is amplified because: - The container executes an autonomous coding Agent. - The image is a mutable third-party dependency. - The API and MCP token variables default to an unauthenticated state when empty or unset. - The exposed interfaces support Agent execution and workspace file operations. - A service bound broadly in host-network mode may be reachable from unintended network interfaces. The documentation warns users about unauthenticated exposure and mentions explicit port publishing, but the primary API and MCP quick-start still grants host-network access. ### Attack Path One exploitation path involving a compromised dependency is: 1. A user follows the quick-start and launches the third-party image with `--network host`. 2. Malicious or compromised code runs inside the container. 3. The ...[truncated 1602 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove `--network host` from the default and recommended deployment commands. 2. Use Docker bridge networking with loopback-only port publication: ```bash docker run -d --name pibox \ -p 127.0.0.1:8080:8080 \ ... ``` 3. Publish the MCP sidecar port separately and only when required: ```bash -p 127.0.0.1:8081:8081 ``` 4. Require nonempty API and MCP tokens before starting any network-accessible mode. Prefer fail-closed startup rather than supporting unauthenticated operation. 5. Bind application listeners to the narrowest appropriate interface. 6. Place externally accessed deployments behind an authenticated TLS reverse proxy. 7. Apply host firewall rules and container egress restrictions so the Agent can reach only necessary upstream providers. 8. Use separate Docker networks for the Agent and internal services; do not attach the Agent container to unrelated application or database networks. 9. Retain independent authentication on host-local services rather than relying on loopback origin as a trust signal. 10. Reserve host networking for exceptional, documented cases where bridge networking cannot satisfy a verified requirement. ]]>
Vulnerability Patterns
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Tool Parameter Abuse

High
Category
Tool Misuse
Content
- **No auth when `PIBOX_API_MODE_TOKEN` is unset.** With it empty the REST/OpenAI-compatible API surface is UNAUTHENTICATED — anyone who can reach it gets full agent-execution and workspace file-read/write/delete access. NEVER expose such an instance on a network or to untrusted agents; set the token and bind to loopback / behind an authenticating proxy.
- **No auth when `PIBOX_MCP_MODE_TOKEN` is unset.** Same story for the MCP surface (`/mcp` or the sidecar) — empty token means unauthenticated `run_prompt`/file-tool access, and it does not fall back to `PIBOX_API_MODE_TOKEN`. Set it explicitly.
- **Destructive & irreversible.** `DELETE /run/{id}`, `DELETE /files/{path}`, and the MCP `delete_file` tool remove state with no undo (canceled runs can't be resumed; deleted files are gone). An agent must NEVER call these unless the user explicitly asked for that exact action; confirm the specific target first, scope it to the current task, and never enumerate-then-bulk-delete. On a shared/multi-tenant instance a deletion can destroy another caller's in-flight run or workspace file — treat these routes as admin-only.

## When To Use
Confidence
98% confidence
Finding
The documented `DELETE /files/{path}` capability allows irreversible deletion of workspace files, and the same section warns that it can destroy another caller's data on shared instances. Because pibox gives remote agents file operations, this is a real high-risk destructive primitive if authorization, scoping, or user confirmation are insufficient.

Tool Parameter Abuse

High
Category
Tool Misuse
Content
- **No auth when `PIBOX_API_MODE_TOKEN` is unset.** With it empty the REST/OpenAI-compatible API surface is UNAUTHENTICATED — anyone who can reach it gets full agent-execution and workspace file-read/write/delete access. NEVER expose such an instance on a network or to untrusted agents; set the token and bind to loopback / behind an authenticating proxy.
- **No auth when `PIBOX_MCP_MODE_TOKEN` is unset.** Same story for the MCP surface (`/mcp` or the sidecar) — empty token means unauthenticated `run_prompt`/file-tool access, and it does not fall back to `PIBOX_API_MODE_TOKEN`. Set it explicitly.
- **Destructive & irreversible.** `DELETE /run/{id}`, `DELETE /files/{path}`, and the MCP `delete_file` tool remove state with no undo (canceled runs can't be resumed; deleted files are gone). An agent must NEVER call these unless the user explicitly asked for that exact action; confirm the specific target first, scope it to the current task, and never enumerate-then-bulk-delete. On a shared/multi-tenant instance a deletion can destroy another caller's in-flight run or workspace file — treat these routes as admin-only.

## When To Use
Confidence
98% confidence
Finding
The documented `DELETE /files/{path}` capability allows irreversible deletion of workspace files, and the same section warns that it can destroy another caller's data on shared instances. Because pibox gives remote agents file operations, this is a real high-risk destructive primitive if authorization, scoping, or user confirmation are insufficient.

Static analysis

No suspicious patterns detected.