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

Content

View full analysis

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

View 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

Content

View full analysis

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

View 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

Content

View full analysis

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

View 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
• 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.

Content

Scanner excerpt · SKILL.md (reported line 111)May include surrounding context.

md

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

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.

Content

No source excerpt is available for this finding.

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.

Content

No source excerpt is available for this finding.

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.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.