ClawHub
Back to skill

Security audit

Mi Trading

Security checks for vulnerabilities and agentic risk

Overview

The skill matches its stated Solana trading purpose, but it asks agents to install an unpinned global trading CLI and can execute real wallet swaps without explicit final user approval.

Review carefully before installing. Use only a dedicated low-value wallet, pin and verify the ClawDex CLI before use, avoid relying on an arbitrary PATH executable, set conservative guardrails first, and require explicit approval for every real swap after seeing the exact final trade terms.

A.I.G

Vulnerability Patterns
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Error
Location
SKILL.md:15
Finding
Unpinned Third-Party CLI Is Installed and Given Access to Sensitive Wallet Material## Vulnerability Details **File Location**: `SKILL.md`, lines 15-17 and 25-29 **Vulnerability Type**: Unpinned and mutable third-party dependency with access to secrets **Risk Level**: High **Vulnerable Code**: ```bash which clawdex || npm install -g clawdex@latest ``` ```bash clawdex onboarding \ --jupiter-api-key "$JUPITER_API_KEY" \ --rpc "${SOLANA_RPC_URL:-https://api.mainnet-beta.solana.com}" \ --wallet ~/.config/solana/id.json \ --json ``` ### Technical Analysis The skill instructs the agent to globally install `clawdex@latest`. The `latest` npm tag is mutable, so the installed implementation can change after the skill has been reviewed. No exact version, integrity hash, package provenance check, publisher verification, or package-content validation is required. npm installation may also execute package lifecycle scripts. After installation, the resulting executable is configured with a Jupiter API key, an RPC endpoint, and the path to a Solana wallet key file. A compromised or malicious package release could therefore run code under the invoking user's account and access sensitive wallet or API material. The use of `which clawdex` does not establish that an existing executable is authentic. A spoofed executable earlier in `PATH` could also satisfy the check and receive the sensitive onboarding arguments. ### Attack Path 1. An attacker compromises the npm package, its publisher account, or the mutable `latest` release. 2. The agent runs `npm install -g clawdex@latest`. 3. Malicious package lifecycle code or the installed CLI executes with the permissions of the invoking user. 4. The agent invokes onboarding with the Jupiter API key and wallet key-file path. 5. The malicious CLI reads or exfiltrates accessible credentials and wallet material, or alters subsequent transaction behavior. 6. The attacker uses the exposed material or manipulated signer to perform unauthorized activity. An alte ...[truncated 832 chars]
Remediation
## Remediation Suggestions - Pin the dependency to a specifically reviewed version instead of using `@latest`. - Verify npm provenance, publisher identity, package signatures where available, and the expected package integrity hash before installation. - Prefer a lockfile-controlled local installation over a global installation. - Install and execute the CLI in an isolated environment with minimal filesystem and network permissions. - Disable npm lifecycle scripts during installation where compatible, then separately review any required setup behavior. - Resolve and validate the executable's absolute path rather than trusting `PATH` lookup alone. - Verify the executable or package checksum before passing any sensitive configuration. - Use a dedicated, low-value trading wallet with strictly limited funds rather than a primary wallet. - Prefer a hardware wallet, external signer, or narrowly scoped signing service so the CLI never receives direct access to a private-key file. - Restrict API credentials to the minimum permissions required and rotate them if exposure is suspected. - Document a reviewed upgrade process so dependency updates trigger a new security assessment.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:53
Finding
Real Token Swaps Bypass Interactive Confirmation Without Requiring Explicit Final User Approval## Vulnerability Details **File Location**: `SKILL.md`, lines 53-59, 69-74, and 110-112 **Vulnerability Type**: Unsafe authorization flow for irreversible financial transactions **Risk Level**: Medium **Vulnerable Code**: ```bash ### Execute a swap ```bash clawdex swap --in SOL --out USDC --amount 0.01 --yes --json ``` **`--yes` is required** for non-interactive execution. Without it, ClawDex exits with code 1. ``` ```text 1. **Health check** — `clawdex status --json` — abort if `rpc.healthy` is false 2. **Check balances** — `clawdex balances --json` — verify sufficient funds 3. **Simulate** — `clawdex swap --simulate-only --json` — preview the trade 4. **Execute** — `clawdex swap --yes --json` — only if simulation looks good 5. **Verify** — `clawdex balances --json` — confirm balances updated (may need 5s delay on public RPC) ``` ```text - **Always use `--yes`** for real swaps (not needed for `--simulate-only`) - **Never skip simulation** unless you have a good reason — use `--simulate-only` first ``` ### Technical Analysis The skill directs the agent to use `--yes` for real swaps, suppressing the CLI's interactive confirmation. Although simulation is recommended, the workflow only says to execute when the simulation “looks good.” It does not require explicit user approval after presenting the final input amount, output token, expected and minimum output, route, fees, slippage, price impact, quote expiration, and wallet address. Simulation validates whether a transaction is likely to execute, but it is not equivalent to authorization. It also does not guarantee that market conditions and routing will remain unchanged between simulation and broadcast. The rule permitting simulation to be skipped for an unspecified “good reason” further weakens the safety boundary. ### Attack Path 1. The agent derives swap parameters from a misunderstood, ambiguous, stale, or manipulated request. 2. The agent obta ...[truncated 1093 chars]
Remediation
## Remediation Suggestions - Require explicit user confirmation immediately before every real swap. - Present the input token and amount, output token, expected output, minimum output, route, fees, slippage, price impact, wallet address, and quote expiration before requesting approval. - Bind approval to an immutable transaction summary or quote identifier so approval cannot be reused for changed parameters. - Treat simulation only as a validation step, never as user authorization. - Remove the exception permitting simulation to be skipped, or define narrowly scoped emergency conditions that still require explicit user consent. - Configure conservative trade-size, slippage, and price-impact limits before allowing any execution. - Re-quote or abort when the quote expires or transaction parameters change after approval. - Require separate confirmation for unknown mint addresses, unusually large transactions, or trades near configured limits. - Use `--yes` only after transaction-specific user approval has been recorded in the current session.

SkillSpector

Vulnerability Patterns
  • 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
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.