Skillv1.0.1

ClawScan security

LP Agent · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousFeb 28, 2026, 12:49 AM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The skill largely implements an LP agent that matches its description, but there are several inconsistencies and risky behaviors (undeclared environment/credential usage, an included deploy script that modifies system files and writes insecure defaults, and scripts that read user .env files and accept private keys) that warrant caution before installing or running it.
Guidance: This skill mostly does what it says (deploy/manage hummingbot-api, gateway, explore pools, add wallets and run LP strategies) but contains several red flags you should consider before running it: - Do not run deploy_hummingbot_api.sh or other scripts as root without reviewing them first. The installer can create files under /usr/local (it may create a sudo shim) and will clone repos and bring up containers. - The scripts read .env files in the project and in your home (~/.hummingbot/.env). Inspect those files before running anything so the skill doesn't pick up unrelated secrets. - The add-wallet flow asks you to paste a Solana private key; this is necessary to add a wallet but you should only do this if you fully trust the API endpoint (HUMMINGBOT_API_URL). Prefer to run the API locally in an isolated environment and change default credentials (do not keep admin/admin). - The registry metadata omitted required environment variables (HUMMINGBOT_API_URL, API_USER, API_PASS) despite the code using them — treat defaults as insecure. If you deploy the API, change the API credentials in the generated .env immediately. - Because the deploy script pulls code/images from the network and the visualization loads resources from CDNs, run these scripts in an isolated VM or container and review network calls if you are concerned. Recommended actions before installing/using: 1. Manually inspect scripts (deploy_hummingbot_api.sh, add_wallet.py, check_* scripts) and references for anything unexpected. 2. Run in a sandbox/VM instead of your main machine. 3. If deploying hummingbot-api, set strong credentials and do not expose the API to the public internet. 4. Do not paste production private keys until you confirm the API is running locally and you understand where the key will be stored/transmitted. 5. If unsure, ask the publisher for provenance or prefer the official hummingbot releases on their GitHub to compare.

Review Dimensions

Purpose & Capability: noteThe skill's code and SKILL.md implement the advertised functionality (deploying/controlling a hummingbot-api, gateway, exploring Meteora pools, adding Solana wallets, running LP strategies). However the registry metadata claimed 'instruction-only / no required env vars' while the included scripts actually rely on environment variables (HUMMINGBOT_API_URL, API_USER, API_PASS) and on local .env files; that mismatch between declared requirements and actual code is an incoherence to surface.
Instruction Scope: concernRuntime instructions direct the agent (and user) to run multiple local scripts that: read .env files in project and user home (~/.hummingbot/.env), call the local Hummingbot API, prompt the user for private keys and POST them to the local API, and perform system-level deployment steps. Reading config from the user's home and prompting for private keys are within the functional scope but are sensitive operations and are not documented in the skill metadata. The SKILL.md instructs execution of scripts that will read environment files beyond the working directory (potentially exposing unrelated credentials) and to paste private keys (which will be transmitted to a local API).
Install Mechanism: concernThere is no registry install spec but the bundle contains a deploy script that clones https://github.com/hummingbot/hummingbot-api.git and uses docker compose to deploy services. Cloning the official GitHub repo is expected for installing hummingbot-api, but the deploy script also contains behavior that modifies the host (it may create a sudo shim at /usr/local/bin/sudo when run as root and writes a .env file with default admin/admin credentials). Scripts will pull external network resources (git clone, docker images, and the visualization HTML loads React/Recharts/Babel from CDNs). These actions are potentially invasive and should be run only after manual review in a controlled environment.
Credentials: concernRegistry metadata lists no required environment variables, but many scripts read HUMMINGBOT_API_URL, API_USER, API_PASS and fall back to defaults (http://localhost:8000, admin/admin). The deploy script creates a .env with admin/admin defaults if non-interactive. The scripts also search for .env files in several locations (hummingbot-api/.env, ~/.hummingbot/.env, .env) and load them, which can surface unrelated secrets from the user's home. Requesting/prompting for a Solana private key is appropriate for wallet management, but users must be aware that the private key is sent to the Hummingbot API (local or remote depending on HUMMINGBOT_API_URL).
Persistence & Privilege: concernThe skill is not marked always:true and does not autonomously force-install in all agents. However the included deploy script can modify the host (cloning repos into ./hummingbot-api, creating /usr/local/bin/sudo shim if run as root, writing .env files, starting docker containers). Those actions give the skill the ability to persist components on the system and alter system state — acceptable for an installer but higher privilege than a pure instruction-only skill. The registry claim of 'instruction-only' vs. included executable scripts that perform host changes is inconsistent.