Hummingbot Deploy

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

Overview

The skill is for Hummingbot deployment, but it asks users to run mutable remote shell code and uses weak plaintext defaults for trading-related services.

Review carefully before installing. Use only pinned, reviewed scripts and container images; replace all default credentials with strong unique values; avoid exposing the API beyond trusted hosts; do not create the sudo shim; and verify where agent MCP configuration stores API credentials.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Tool Hijacking and Spoofing: Modifies or replaces tools so legitimate-looking calls execute attacker logic
• 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 (4)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:35
• Finding: Unpinned Remote Scripts Are Downloaded and Executed Directly<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:35`, `SKILL.md:106-107`, `SKILL.md:112-113`, and `SKILL.md:143` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ### Vulnerable Code ```bash bash <(curl -s https://raw.githubusercontent.com/hummingbot/skills/main/skills/hummingbot-deploy/scripts/check_env.sh) ``` ```bash bash <(curl -s https://raw.githubusercontent.com/hummingbot/skills/main/skills/hummingbot-deploy/scripts/install_mcp.sh) \ --agent <YOUR_CLI> --user <API_USER> --pass <API_PASS> ``` ```bash bash <(curl -s https://raw.githubusercontent.com/hummingbot/skills/main/skills/hummingbot-deploy/scripts/install_mcp.sh) \ --agent claude --user admin --pass admin ``` ```bash bash <(curl -s https://raw.githubusercontent.com/hummingbot/skills/main/skills/hummingbot-deploy/scripts/verify.sh) ``` ### Technical Analysis The instructions stream shell scripts from the mutable `main` branch of a remote GitHub repository directly into Bash. No immutable commit reference, checksum, signature, or local review is required before execution. Consequently, the effective code executed by the Skill can change after this package has been reviewed. The project already contains local copies of these scripts, so remote retrieval is not necessary for the declared deployment functionality. The MCP installation command is especially sensitive because API credentials are supplied as arguments to code retrieved from the network. If the upstream repository, account, branch, DNS path, or delivery infrastructure is compromised, the replacement script could read those arguments and execute arbitrary commands. ### Attack Path 1. An attacker compromises the upstream repository, maintainer account, or mutable `main` branch. 2. The attacker replaces one of the referenced scripts with a malicious payload. 3. A user or AI agent follows the instructions in `SKILL.md`. 4. `curl` retrieves the changed payload and process substitution ...[truncated 871 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Execute the scripts bundled with the Skill instead of downloading mutable copies: ```bash bash scripts/check_env.sh bash scripts/install_mcp.sh --agent codex --user "$API_USER" --pass "$API_PASS" bash scripts/verify.sh ``` - If remote retrieval is unavoidable, pin the URL to an immutable reviewed commit. - Download the script to a regular file before execution. - Verify a published cryptographic checksum or trusted signature. - Fail closed if verification does not succeed. - Display or review the downloaded content before running it. - Never provide credentials to code that has not been authenticated and verified. - Use `curl --fail --show-error --silent` so HTTP failures do not silently produce unexpected shell input. ]]>

T07 · Tool Hijacking and Spoofing

Error

• Location: SKILL.md:61
• Finding: Installation Creates a Global Fake sudo Executable<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:61-63` **Vulnerability Type**: Tool hijacking and spoofing **Risk Level**: High ### Vulnerable Code ```bash # Set USER env var and create sudo shim if needed export USER=${USER:-root} [ "$(id -u)" = "0" ] && ! command -v sudo &>/dev/null && echo -e '#!/bin/bash\nwhile [[ "$1" == *=* ]]; do export "$1"; shift; done\nexec "$@"' > /usr/local/bin/sudo && chmod +x /usr/local/bin/sudo ``` ### Technical Analysis When executed as root in an environment without `sudo`, the installation instructions create `/usr/local/bin/sudo`. This program does not implement sudo's authentication, authorization, user-selection, policy, logging, or environment-sanitization behavior. Instead, it exports leading assignment arguments and directly executes the remaining command. Creating a globally discoverable executable under the trusted name `sudo` affects unrelated programs after the deployment step finishes. Programs may detect it with `command -v sudo` and incorrectly assume that genuine sudo security semantics are available. The deployment task does not require replacing a system administration tool. Because the condition requires the current process to already be root, commands can be invoked directly without installing a spoofed `sudo`. ### Attack Path 1. The Skill runs as root in a container or other environment where genuine `sudo` is absent. 2. The command writes the shim to `/usr/local/bin/sudo` and makes it executable. 3. `/usr/local/bin` remains in the command search path after installation. 4. A later installer or administrative script checks for and invokes `sudo`. 5. The shim executes the supplied command directly as the already privileged user, without expected sudo policy enforcement or environment handling. 6. Attacker-influenced arguments or environment variables accepted by the later script may consequently be processed with root privileges. ### Impact Assessment The direct effect is a persistent ...[truncated 500 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove the instruction that creates `/usr/local/bin/sudo`. - When the installer is already root, invoke the required setup commands directly. - Modify the specific deployment workflow to support root execution without assuming that sudo is installed. - If compatibility wrapping is unavoidable, use an explicitly named local helper outside the system `PATH`. - Reference that helper by its exact path and remove it immediately after the specific operation. - Never emulate a privileged system utility under its standard name. - Document the exact privileges required by each installation operation and reject unsupported environments rather than globally changing tool behavior. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/verify.sh:8
• Finding: Verification Executes Dotenv Files as Arbitrary Shell Code<![CDATA[ ## Vulnerability Details **File Location**: `scripts/verify.sh:8-14` **Vulnerability Type**: Unsafe credential-file parsing and arbitrary shell execution **Risk Level**: High ### Vulnerable Code ```bash # Load .env if present for f in hummingbot-api/.env ~/.hummingbot/.env .env; do if [ -f "$f" ]; then set -a; source "$f"; set +a break fi done API_URL="${HUMMINGBOT_API_URL:-http://localhost:8000}" ``` ### Technical Analysis The Bash `source` command executes a file as shell code; it is not a safe dotenv parser. A dotenv file containing command substitution, shell functions, redirections, or ordinary shell commands will execute them with the privileges of the verification process. The verification operation only consumes `HUMMINGBOT_API_URL`, but the script searches three broad paths, including the current directory and a credential-related home directory. It then exports every variable loaded from the first matching file by enabling `set -a`. This violates least privilege by reading and exporting unrelated secrets such as API, broker, or database credentials. A repository-controlled `.env` file or a maliciously modified `hummingbot-api/.env` can therefore turn a routine verification command into an arbitrary code-execution mechanism. ### Attack Path 1. An attacker places or modifies one of the searched files, such as `.env` in the current working directory. 2. The file includes shell syntax, for example a command substitution or direct command. 3. The user invokes `scripts/verify.sh`, or follows the remote verification instruction in `SKILL.md`. 4. The loop selects the first existing file. 5. `source "$f"` evaluates the attacker's content in the current shell. 6. The malicious command executes with the verification user's privileges. 7. All variables in that file are also exported and become available to later child processes such as `curl` and `grep`. ### Impact Assessment Exploitation results in arbitrary command ex ...[truncated 402 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not use `source`, `.`, or `eval` to parse dotenv files. - Accept the API URL through an explicit command-line option or an already defined environment variable. - If dotenv support is required, parse only the exact `HUMMINGBOT_API_URL` key with a strict parser. - Reject command substitutions, shell metacharacters, multiline values, and malformed entries. - Do not enable automatic export for the entire credential file. - Avoid searching `~/.hummingbot/.env` when only a deployment-local endpoint is needed. - Use a fixed, documented configuration path and verify its ownership and permissions before reading it. - Keep unrelated secrets out of the environment inherited by `curl` and other child processes. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:67
• Finding: Predictable Default Credentials Are Persisted in Plaintext Configuration<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:67-79` and `scripts/install_mcp.sh:29-31, 82-89` **Vulnerability Type**: Hardcoded weak credentials and plaintext secret persistence **Risk Level**: High ### Vulnerable Code From `SKILL.md`: ```bash # Create .env manually (skip interactive setup) # Note: In containers, services communicate via Docker network (use container names, not localhost) cat > .env << EOF API_USER=admin API_PASS=admin CONFIG_API_PASS=admin DEBUG_MODE=false BROKER_HOST=hummingbot-broker BROKER_PORT=1883 BROKER_API_USER=admin BROKER_PASSWORD=password DATABASE_URL=postgresql+asyncpg://hbot:hummingbot-api@hummingbot-postgres:5432/hummingbot_api BOTS_PATH=/hummingbot-api/bots EOF ``` From `scripts/install_mcp.sh`: ```bash API_URL=$(get_docker_host_url) API_USER="admin" API_PASS="admin" AGENT_CLI="" MCP_IMAGE="hummingbot/hummingbot-mcp:latest" ``` ```bash # Build the docker command DOCKER_CMD="docker run --rm -i -e HUMMINGBOT_API_URL=$API_URL -e HUMMINGBOT_API_USERNAME=$API_USER -e HUMMINGBOT_API_PASSWORD=$API_PASS -v hummingbot_mcp:/root/.hummingbot_mcp $MCP_IMAGE" # Different CLIs have slightly different syntax case "$AGENT_CLI" in gemini) # Gemini: gemini mcp add <name> <command> [args...] $AGENT_CLI mcp add hummingbot $DOCKER_CMD ;; *) # Claude/Codex: <cli> mcp add <name> -- <command> [args...] $AGENT_CLI mcp add hummingbot -- $DOCKER_CMD ;; esac ``` ### Technical Analysis The noninteractive installation writes publicly known credentials, including `admin/admin` and broker password `password`, to a plaintext `.env` file. These values are not randomly generated and no mandatory rotation is performed. The MCP installer independently defaults to `admin/admin`. It interpolates the password into a Docker command that is passed to an agent CLI for persistent MCP registration. Depending on the CLI implementation, this complete command can be stored in an agent configura ...[truncated 1701 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Generate cryptographically strong, unique credentials during every noninteractive installation. - Do not use functional defaults such as `admin/admin` or `password`. - Fail installation if required secrets have not been supplied securely. - Create credential files with restrictive permissions, such as mode `0600`, before writing secrets. - Bind the API to localhost by default unless the user explicitly requests remote exposure. - Use Docker secrets, protected environment files, or an operating-system secret store instead of embedding passwords in persisted MCP command strings. - Avoid accepting passwords as command-line arguments. - Prompt through a protected input channel or accept a path to a restricted secret file. - Ensure agent configuration files containing sensitive values have restrictive ownership and permissions. - Require credential rotation when upgrading any existing deployment that uses documented defaults. ]]>

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
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults

Findings (19)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 88% confidence
• Finding: The declared description is broader than what this code chunk actually does. The script does support Hummingbot setup in a limited sense, but only for MCP server access through external agent CLIs such as Claude, Gemini, or Codex. It validates the CLI, pulls the `hummingbot/hummingbot-mcp` Docker image, and configures the CLI to launch that container with API connection environment variables. There is no code here to deploy the Hummingbot API server itself, no setup of a Condor Telegram bot, and no general infrastructure provisioning. Because the declared purpose describes a more comprehensive deployment capability than this script provides, this is a material description-to-behavior mismatch.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The skill explicitly uses default credentials like `admin/admin/admin` for API and config access and does not prominently warn that these are insecure and must be changed. In deployment context, especially for network-exposed services and bot infrastructure, default credentials can lead to immediate unauthorized access and account compromise.

Credential Access

High

• Category: Privilege Escalation

Content

export USER=${USER:-root}
[ "$(id -u)" = "0" ] && ! command -v sudo &>/dev/null && echo -e '#!/bin/bash\nwhile [[ "$1" == *=* ]]; do export "$1"; shift; done\nexec "$@"' > /usr/local/bin/sudo && chmod +x /usr/local/bin/sudo

# Create .env manually (skip interactive setup)
# Note: In containers, services communicate via Docker network (use container names, not localhost)
cat > .env << EOF
API_USER=admin

• Confidence: 98% confidence
• Finding: The skill writes plaintext credentials directly into a `.env` file, including API and broker passwords, using insecure hardcoded defaults. Storing secrets this way is dangerous because `.env` files are easily leaked through backups, logs, shell history, accidental commits, or over-broad file permissions.

Credential Access

High

• Category: Privilege Escalation

Content

# Create .env manually (skip interactive setup)
# Note: In containers, services communicate via Docker network (use container names, not localhost)
cat > .env << EOF
API_USER=admin
API_PASS=admin
CONFIG_API_PASS=admin

• Confidence: 99% confidence
• Finding: The specific values shown (`API_PASS=admin`, `CONFIG_API_PASS=admin`) normalize deployment with trivially guessable credentials and encourage insecure copy-paste behavior. Because this is trading infrastructure that may expose control interfaces, compromise could allow unauthorized bot management, data access, or service abuse.

Chaining Abuse

High

• Category: Tool Misuse

Content

cd ./hummingbot-api && docker compose logs -f

# Reset
cd ./hummingbot-api && docker compose down -v && rm -rf ./hummingbot-api
```

## See Also

• Confidence: 84% confidence
• Finding: The command chains `docker compose down -v` with `rm -rf ./hummingbot-api`, so a single execution performs multiple destructive actions without pause or validation. Chaining amplifies operator mistakes and can increase damage if the working directory or path assumptions are wrong.

Credential Access

High

• Category: Privilege Escalation

Content

#
set -eu

# Load .env if present
for f in hummingbot-api/.env ~/.hummingbot/.env .env; do
    if [ -f "$f" ]; then
        set -a; source "$f"; set +a

• Confidence: 97% confidence
• Finding: The script sources the first matching .env file directly into the current shell using `source`, which executes arbitrary shell code, not just variable assignments. If an attacker can modify any of these files or influence the working directory, running this verification script can trigger unintended command execution and expose secrets via exported environment variables.

Credential Access

High

• Category: Privilege Escalation

Content

set -eu

# Load .env if present
for f in hummingbot-api/.env ~/.hummingbot/.env .env; do
    if [ -f "$f" ]; then
        set -a; source "$f"; set +a
        break

• Confidence: 96% confidence
• Finding: This finding is part of the same unsafe pattern: the script iterates through multiple candidate .env locations, including a relative `.env`, and sources the first one found. That expands the attack surface because a malicious repository-local or current-directory .env can be used for code execution when the verification script runs.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 95% confidence
• Finding: The skill instructs the agent to run multiple shell commands, including remote script execution, git clone, Docker deployment, file edits, and destructive reset commands, but declares no explicit tool scope or allowed-tools restrictions. In a skill framework, this increases the chance of unintended or over-broad execution because consumers cannot easily constrain what the skill is permitted to do.

Vague Triggers

Medium

• Confidence: 94% confidence
• Finding: The invocation text is broad enough to match generic install/setup/configuration requests, which can cause the skill to trigger in contexts where the user did not specifically request Hummingbot infrastructure deployment. Because the skill performs high-impact shell and Docker actions, over-triggering materially raises security and safety risk.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

**In containers** (no TTY - check with `[ -t 0 ] && echo "TTY" || echo "No TTY"`):
```bash
# Set USER env var and create sudo shim if needed
export USER=${USER:-root}
[ "$(id -u)" = "0" ] && ! command -v sudo &>/dev/null && echo -e '#!/bin/bash\nwhile [[ "$1" == *=* ]]; do export "$1"; shift; done\nexec "$@"' > /usr/local/bin/sudo && chmod +x /usr/local/bin/sudo

• Confidence: 93% confidence
• Finding: The skill contains logic intended for root execution and creates a `sudo` shim in `/usr/local/bin` when running as UID 0. Modifying a common system command path in this way can alter privilege semantics, mask the absence of real `sudo`, and create persistence or command-confusion risks in the environment.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```bash
# Set USER env var and create sudo shim if needed
export USER=${USER:-root}
[ "$(id -u)" = "0" ] && ! command -v sudo &>/dev/null && echo -e '#!/bin/bash\nwhile [[ "$1" == *=* ]]; do export "$1"; shift; done\nexec "$@"' > /usr/local/bin/sudo && chmod +x /usr/local/bin/sudo

# Create .env manually (skip interactive setup)
# Note: In containers, services communicate via Docker network (use container names, not localhost)

• Confidence: 91% confidence
• Finding: This finding is tied to the same root-execution container block, where the skill proceeds with privileged environment modification and deployment after setting `USER=root` semantics and installing a `sudo` shim. In a deployment skill, performing filesystem and service setup as root without strict safeguards increases blast radius if anything in the chain is wrong or compromised.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

Install the MCP server using your CLI's native command. Use the same credentials from API setup.

**IMPORTANT:** Do NOT ask the user which CLI to use. You already know which CLI you are:
- If you are Claude Code, use `claude`
- If you are Gemini CLI, use `gemini`
- If you are Codex CLI, use `codex`

• Confidence: 80% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 86% confidence
• Finding: The instruction to run `npx skills add hummingbot/skills` does not pin a version or integrity value, so the executed package may change over time or be replaced upstream. This creates a supply-chain risk where future installs could pull unreviewed or malicious code into the user's environment.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 96% confidence
• Finding: The script pulls a container image from a mutable `latest` tag, which allows the image contents to change over time without any script change or integrity guarantee. If the registry account or supply chain is compromised, users may install and trust a malicious MCP server image that will then receive API credentials and be registered with an agent CLI.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 93% confidence
• Finding: The `docker run` path also relies on the same mutable `latest` image reference, so execution is not reproducible and can silently shift to attacker-controlled code if the image is replaced upstream. In this skill context, that risk is amplified because the container is launched with Hummingbot API credentials in environment variables and is then integrated into an agent workflow.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The script embeds API credentials directly into a constructed Docker command and passes them to agent CLI configuration without warning, which can expose secrets through shell history, process listings, agent config/state, logs, or debugging output. In this deployment context, the risk is heightened because default credentials are weak (`admin`/`admin`) and the configured MCP server may persist access to a trading API backend.

Context-Inappropriate Capability

Medium

• Confidence: 76% confidence
• Finding: The manifest describes installing and deploying Hummingbot components such as the API server, MCP server, and Telegram bot. This script goes further by modifying external AI agent CLI configuration through '<agent> mcp add ...', which affects another tool's local setup rather than only deploying Hummingbot itself.

Tool Parameter Abuse

Low

• Category: Tool Misuse

Content

cd ./hummingbot-api && docker compose logs -f

# Reset
cd ./hummingbot-api && docker compose down -v && rm -rf ./hummingbot-api
```

## See Also

• Confidence: 15% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Intent-Code Divergence

Low

• Confidence: 97% confidence
• Finding: The comments say the script should use 'host.docker.internal' on Mac/Windows and 'host-gateway' on Linux, implying different behavior by platform. However, both branches echo the identical URL, so the inline documentation contradicts the actual implementation.

Static analysis

No suspicious patterns detected.