Clawhub Skill Bandwidth Income

• Outcome: Review
• Latest audit: Sep 10, 2026 · 11:45 PM UTC
• Version: 1.0.0

Overview

The skill is not deceptive, but it asks users to run persistent network-facing bandwidth and exit-node containers with elevated networking and weak safety scoping.

Review this carefully before installing. Only run it on a dedicated host or VM, verify each container image and pin trusted digests, avoid exposing management ports publicly, use safer secret handling than command-line or environment passwords, and confirm that your ISP, cloud provider, and local rules allow exit-node or bandwidth-relay traffic from your IP.

A.I.G

Vulnerability Patterns

• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T08 · Insecure Dependencies

Error

• Location: SKILL.md:81
• Finding: Mutable and Unverified Container Images Create a Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md:81-86`, `SKILL.md:99-107`, `SKILL.md:121-134`, `SKILL.md:135-171` **Vulnerability Type**: Unpinned and partly unofficial container dependencies **Risk Level**: High ### Vulnerable Code ```bash docker run -d \ --name grass-node \ --restart unless-stopped \ -e GRASS_USER=[e-mail] \ -e GRASS_PASS=yourpassword \ mrcolorrain/grass:latest ``` ```bash docker run -d \ --name mysterium-node \ --restart unless-stopped \ --cap-add NET_ADMIN \ -p 4449:4449 \ -v ~/.mysterium:/root/.mysterium \ mysteriumnetwork/myst:latest \ service --agreed-terms-and-conditions ``` ```bash docker run -d \ --name storj-node \ --restart unless-stopped \ -p 28967:28967 \ -p 14002:14002 \ -e WALLET="0xYOUR_ETH_WALLET" \ -e EMAIL="[e-mail]" \ -e ADDRESS="YOUR_PUBLIC_IP:28967" \ -e STORAGE="500GB" \ -v /path/to/storj/data:/app/identity \ -v /path/to/storj/storage:/app/config \ storjlabs/storagenode:latest ``` ```yaml services: grass: image: mrcolorrain/grass:latest container_name: grass-node restart: unless-stopped environment: - GRASS_USER=${GRASS_EMAIL} - GRASS_PASS=${GRASS_PASSWORD} mysterium: image: mysteriumnetwork/myst:latest container_name: mysterium-node restart: unless-stopped cap_add: - NET_ADMIN ports: - "4449:4449" volumes: - mysterium_data:/root/.mysterium command: service --agreed-terms-and-conditions honeygain: image: honeygain/honeygain:latest container_name: honeygain-node restart: unless-stopped environment: - HONEYGAIN_EMAIL=${HONEYGAIN_EMAIL} - HONEYGAIN_PASS=${HONEYGAIN_PASSWORD} - HONEYGAIN_DEVICE=homelab-01 ``` ### Technical Analysis All documented container images use the mutable `latest` tag rather than i ...[truncated 2294 chars]
• Remediation: ## Remediation Suggestions 1. Replace every `latest` reference with a reviewed version and immutable SHA-256 digest, for example: ```yaml image: vendor/image:reviewed-version@sha256:EXPECTED_DIGEST ``` 2. Confirm each image against the platform vendor's official documentation and registry namespace. 3. Do not recommend the personal-namespace Grass image until its source repository, Dockerfile, build pipeline, ownership, and resulting digest have been independently verified. 4. Verify image signatures with a mechanism such as Sigstore Cosign and enforce signature policies in deployment tooling. 5. Review image SBOMs and scan pinned images for known vulnerabilities before deployment. 6. Configure controlled update procedures rather than automatically adopting newly published images. 7. Drop Linux capabilities by default and retain `NET_ADMIN` only where documented as strictly necessary. 8. Run containers as non-root where supported and apply read-only filesystems, seccomp, AppArmor or SELinux policies, resource limits, and isolated Docker networks.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:81
• Finding: Account Passwords Are Passed Through Docker Environment Variables## Vulnerability Details **File Location**: `SKILL.md:81-86`, `SKILL.md:141-150`, `SKILL.md:162-170` **Vulnerability Type**: Insecure storage and handling of authentication credentials **Risk Level**: Medium ### Vulnerable Code ```bash docker run -d \ --name grass-node \ --restart unless-stopped \ -e GRASS_USER=[e-mail] \ -e GRASS_PASS=yourpassword \ mrcolorrain/grass:latest ``` ```yaml grass: image: mrcolorrain/grass:latest container_name: grass-node restart: unless-stopped environment: - GRASS_USER=${GRASS_EMAIL} - GRASS_PASS=${GRASS_PASSWORD} ``` ```yaml honeygain: image: honeygain/honeygain:latest container_name: honeygain-node restart: unless-stopped environment: - HONEYGAIN_EMAIL=${HONEYGAIN_EMAIL} - HONEYGAIN_PASS=${HONEYGAIN_PASSWORD} - HONEYGAIN_DEVICE=homelab-01 ``` ### Technical Analysis The instructions place Grass and Honeygain account passwords in container environment variables. Docker preserves configured environment values in container metadata, where they may be exposed through container inspection, privileged Docker API access, diagnostics, backups, or orchestration interfaces. The direct `docker run` example may also lead users to place a plaintext password in shell history, terminal logs, process-auditing records, or copied deployment documentation. The Compose example likely relies on a local `.env` file, but no restrictive permissions, exclusion from version control, or rotation guidance is provided. Environment-variable substitution prevents the password from being written literally in the Compose YAML file, but it does not make the value a protected secret after it is supplied to Docker. ### Attack Path 1. A user replaces the placeholders with real account credentials or stores them in a Compose `.env` file. 2. The credentials enter shell history, local files, Docker container configuration, or deploym ...[truncated 911 chars]
• Remediation: ## Remediation Suggestions 1. Use Docker secrets or restrictive read-only secret files instead of ordinary environment variables whenever the applications support file-based credentials. 2. Avoid placing passwords directly in `docker run` command lines. 3. If a temporary `.env` file is unavoidable: - Set ownership to the dedicated deployment account. - Set permissions to `0600`. - Add `.env` and all secret files to `.gitignore`. - Exclude them from logs, support bundles, and unencrypted backups. 4. Use dedicated platform passwords that are not reused for email, wallets, host administration, or other services. 5. Enable multifactor authentication where the platforms support it. 6. Document credential rotation and immediate revocation procedures. 7. Restrict Docker daemon and socket access to trusted administrators because Docker access can expose container configuration and secrets. 8. Redact environment values from monitoring output, diagnostics, and alert messages.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:99
• Finding: Administrative Interfaces Are Published on All Host Interfaces## Vulnerability Details **File Location**: `SKILL.md:99-112`, `SKILL.md:121-134`, `SKILL.md:151-158` **Vulnerability Type**: Unsafe network exposure of management and dashboard services **Risk Level**: High ### Vulnerable Code ```bash docker run -d \ --name mysterium-node \ --restart unless-stopped \ --cap-add NET_ADMIN \ -p 4449:4449 \ -v ~/.mysterium:/root/.mysterium \ mysteriumnetwork/myst:latest \ service --agreed-terms-and-conditions # 3. Claim your node: # Visit: http://YOUR_SERVER_IP:4449 # Enter your wallet address from my.mystnodes.com ``` ```bash docker run -d \ --name storj-node \ --restart unless-stopped \ -p 28967:28967 \ -p 14002:14002 \ -e WALLET="0xYOUR_ETH_WALLET" \ -e EMAIL="[e-mail]" \ -e ADDRESS="YOUR_PUBLIC_IP:28967" \ -e STORAGE="500GB" \ -v /path/to/storj/data:/app/identity \ -v /path/to/storj/storage:/app/config \ storjlabs/storagenode:latest ``` ```yaml mysterium: image: mysteriumnetwork/myst:latest container_name: mysterium-node restart: unless-stopped cap_add: - NET_ADMIN ports: - "4449:4449" volumes: - mysterium_data:/root/.mysterium command: service --agreed-terms-and-conditions ``` ### Technical Analysis Docker port mappings in the form `HOST_PORT:CONTAINER_PORT` bind to all host interfaces by default unless the daemon is configured otherwise. Thus, `-p 4449:4449`, `-p 14002:14002`, and `"4449:4449"` may make the associated interfaces reachable from the LAN or public internet. Port 4449 is explicitly described as the Mysterium node-claim interface and is accessed using plain HTTP. The instructions do not require loopback binding, firewall allowlisting, authentication verification, TLS, an SSH tunnel, or an authenticated reverse proxy. Storj port 14002 is similarly published without protective guidance, despite normally serving dashboard functionality. Port 28967 ...[truncated 1675 chars]
• Remediation: ## Remediation Suggestions 1. Bind management interfaces to loopback: ```bash -p 127.0.0.1:4449:4449 -p 127.0.0.1:14002:14002 ``` ```yaml ports: - "127.0.0.1:4449:4449" ``` 2. Access loopback-bound interfaces through an SSH tunnel or a VPN restricted to authorized administrators. 3. If remote browser access is necessary, place the interface behind an authenticated TLS reverse proxy with strict source-IP allowlisting. 4. Add host and upstream firewall rules that deny public access to ports 4449 and 14002. 5. Publish only ports that are operationally required. Treat Storj port 28967 separately from its management dashboard and expose it only as required by official vendor guidance. 6. Verify that each management interface enforces authentication before permitting network access. 7. Do not transmit sensitive setup information over plain HTTP across an untrusted network. 8. Place the containers on isolated networks or VLANs and prevent unnecessary access to internal infrastructure. 9. Document a post-installation verification step using tools such as `ss`, firewall inspection, and an external port scan to confirm that management ports are not publicly reachable.

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (5)

Privileged Container / Container Escape

High

• Category: Privilege Escalation

Content

docker run -d \
  --name mysterium-node \
  --restart unless-stopped \
  --cap-add NET_ADMIN \
  -p 4449:4449 \
  -v ~/.mysterium:/root/.mysterium \
  mysteriumnetwork/myst:latest \

• Confidence: 94% confidence
• Finding: The skill tells users to run a container with NET_ADMIN, granting powerful network-management capabilities inside the container. If the image is compromised or exploited, an attacker could manipulate routing, firewall rules, packet handling, or use the elevated capability as part of a broader host/network attack path; in this skill's context, that risk is heightened because the service is intentionally network-facing and handles third-party traffic.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 84% confidence
• Finding: The skill instructs users to pull and run third-party Docker images using mutable tags, including ':latest', without pinning a trusted digest. This creates a supply-chain risk: a compromised publisher account or image update could silently deliver malicious code to users running the setup later.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 84% confidence
• Finding: The Mysterium setup uses an unpinned container image, allowing future image changes to alter what code is executed on the host. Because this container is network-exposed and granted elevated networking capability, the risk from a compromised or malicious image is amplified.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 84% confidence
• Finding: The Storj deployment similarly relies on a mutable image reference rather than an immutable digest. Users following the skill may unknowingly run different code over time, increasing exposure to supply-chain compromise and reducing reproducibility.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: This skill promotes bandwidth-sharing and VPN exit-node operation but does not clearly warn that third-party traffic may appear to originate from the user's IP, potentially leading to abuse complaints, law-enforcement inquiries, account sanctions, or ISP action. The brief privacy notes mention IP sharing, but they do not adequately communicate the legal and operational risk of becoming an exit point for others' traffic.

Static analysis

No suspicious patterns detected.