Bitget Wallet Skill.Disabled

• Outcome: Review
• Latest audit: May 29, 2026 at 9:27 PM UTC
• Version:
  1.0.0

Overview

This is a functional crypto wallet, trading, and payment skill with real fund-moving authority, despite metadata and descriptions that understate or conflict with that power.

Install only if you intentionally want an agent-capable crypto wallet/trading/payment helper. Use a fresh low-balance wallet, avoid providing existing seed phrases or high-value keys, prefer an external wallet or hardware signer, review every transaction and x402 payment before approval, avoid auto-pay, and do not accept unpinned self-updates without reviewing the diff.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (29)

Description-Behavior Mismatch

Medium

• Confidence: 94% confidence
• Finding: The README materially expands the skill's capabilities beyond the declared metadata by documenting fund-moving actions such as order creation, transaction submission, and x402 payments. This scope mismatch is dangerous because agents, reviewers, or policy layers may treat the skill as read-only market/security tooling while it actually supports spending funds and interacting with arbitrary paid endpoints.

Intent-Code Divergence

High

• Confidence: 97% confidence
• Finding: The documentation claims the agent cannot sign independently, yet elsewhere instructs workflows where the agent signs swap transactions and x402 payment authorizations once provided wallet keys. That contradiction can mislead operators into granting key access under a false assumption of non-custodial behavior, enabling autonomous spending or transaction authorization by the agent runtime.

Description-Behavior Mismatch

High

• Confidence: 95% confidence
• Finding: The skill instructs the agent to create and persist a new wallet mnemonic even though the manifest mostly presents an API interaction and market/swap utility. Secret generation and custodial storage are materially different from informational API access and introduce custody, exfiltration, and irreversible asset-loss risk if the agent or storage boundary is compromised.

Context-Inappropriate Capability

High

• Confidence: 96% confidence
• Finding: Mnemonic generation, persistence, and on-the-fly private-key derivation give the skill effective control over user funds across multiple chains. Even with stated safety rules, embedding these capabilities in a broadly-triggered skill dramatically increases blast radius: compromise of the agent, logs, prompts, storage integration, or downstream scripts could expose the mnemonic or enable unauthorized signing.

Context-Inappropriate Capability

High

• Confidence: 98% confidence
• Finding: The self-update instruction tells the agent to fetch code from a remote GitHub branch, replace all local skill files, and continue operating. This is a classic remote code supply-chain risk: if the repository, branch, transport, or referenced files are tampered with, the agent can silently install new behavior, endpoints, secret handling, or exfiltration logic.

Description-Behavior Mismatch

Medium

• Confidence: 92% confidence
• Finding: The documented x402 payment signing and pay flow expands the skill beyond its declared Bitget wallet/market-data/swap/security scope into generic third-party payment execution. In a wallet-related skill, undocumented scope expansion is dangerous because it can normalize signing and transmitting value-bearing transactions to arbitrary services without clear user expectations or trust boundaries.

Context-Inappropriate Capability

High

• Confidence: 97% confidence
• Finding: The `x402_pay.py pay --url ... --private-key ...` command enables generic payment execution against arbitrary URLs, which is far broader than a Bitget wallet helper should need. This creates a path for exfiltration of signing authority or unauthorized value transfer, especially if an agent or user is induced to pay an attacker-controlled endpoint.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The documentation explicitly instructs the agent to derive a private key from a stored mnemonic and use it to sign and submit blockchain transactions. That is a highly sensitive capability extending beyond passive wallet data and quote retrieval into active fund movement, which materially increases the blast radius if the agent is compromised, misprompted, or misused.

Description-Behavior Mismatch

Medium

• Confidence: 92% confidence
• Finding: The documented workflow goes beyond providing quotes and risk checks by enabling the agent to execute swaps on the user's behalf after confirmation. Even with a confirmation gate, this changes the skill from informational to transactional, creating risk of unauthorized or mistaken asset transfers if prompts, tool wiring, or confirmations are mishandled.

Context-Inappropriate Capability

High

• Confidence: 98% confidence
• Finding: Handling mnemonic-derived private keys inside the skill is especially dangerous because compromise of that flow can lead directly to irreversible theft of on-chain assets. The context makes this more dangerous, not less, because this is a wallet-management skill operating on real-value credentials and explicitly instructing derivation, transient use, and signing within the agent-controlled workflow.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The document correctly warns against passing secrets via command-line arguments, but nearby usage examples still show private keys supplied as CLI flags. This contradiction is dangerous because operators and downstream agents often follow examples over prose, causing wallet private keys to be exposed through process listings, shell history, job logs, and monitoring tools.

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The key retrieval section explicitly instructs the agent to pass derived private keys to order_sign.py via --private-key/--private-key-sol, directly conflicting with the earlier warning not to expose secrets in command-line arguments. In an agent context, this is especially risky because automation frameworks may log executed commands verbatim, turning ephemeral derived keys into widely exposed credentials that enable immediate theft of wallet assets.

Description-Behavior Mismatch

Medium

• Confidence: 86% confidence
• Finding: The file implements a full transaction lifecycle for crypto swaps, including quote, confirm, order creation, and final broadcast via send(), while the skill description emphasizes wallet/market data and token checks. In an agent setting, this capability expansion is dangerous because users or higher-level orchestration may invoke real fund-moving actions without the transparency, consent gates, and risk framing expected for trading functionality.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The script explicitly describes a workflow to create, sign, and broadcast blockchain transactions using user private keys, which materially exceeds the skill's stated read-oriented wallet/market-data purpose. In an agent setting, this creates a dangerous privilege expansion: a user or downstream component may invoke what appears to be an informational skill but actually authorize value-moving transactions.

Context-Inappropriate Capability

High

• Confidence: 98% confidence
• Finding: This code accepts raw EVM or Solana private keys, signs arbitrary transaction data returned by make_order, and immediately sends the signed transactions on-chain. Even if intended for convenience, handling raw keys in-process and coupling signing directly to submission creates a high-risk path for unauthorized fund movement, misuse by other agent components, and key exposure via process arguments or surrounding tooling.

Description-Behavior Mismatch

Medium

• Confidence: 95% confidence
• Finding: The file is explicitly a signing helper that accepts user private keys and produces signed orders/transactions, which materially exceeds a skill description centered on wallet info, market data, quotes, and security audits. In an agent-skill context, embedding transaction-signing logic enables direct asset-authorizing actions and turns the skill from informational tooling into a fund-moving capability, increasing risk of misuse or deceptive invocation.

Context-Inappropriate Capability

High

• Confidence: 98% confidence
• Finding: The code directly signs EVM hashes, raw EVM transactions, gasless authorization messages, and Solana transactions using user-supplied private keys. In an agent setting, this is highly dangerous because any compromise, prompt injection, or malicious workflow using this helper can generate valid authorizations to transfer assets or approve on-chain actions without relying on a trusted wallet UI.

Intent-Code Divergence

Medium

• Confidence: 84% confidence
• Finding: The helper's documentation says eth_sign should include the Ethereum Signed Message prefix, but the implementation actually uses unsafe_sign_hash on the raw 32-byte hash without prefixing. This mismatch can cause operators or downstream code to believe they are authorizing one signature scheme while producing another, leading to incorrect verification assumptions and potentially signing unintended authorizations.

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: This script accepts a blockchain private key via environment variable for signing payments, which introduces direct secret-handling and transaction-authorizing capability unrelated to the declared Bitget Wallet market-data/token-info skill. In the context of an agent skill, this is dangerous because any misuse of the command path can turn passive data access into active fund movement using a sensitive credential.

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: The file implements x402 payment signing and settlement logic, including EIP-3009 and Solana transaction signing, which is materially outside the advertised skill purpose of Bitget Wallet market data, token info, and security checks. This scope mismatch is dangerous because it conceals fund-movement functionality inside a seemingly informational skill, increasing the chance that an operator or agent invokes privileged behavior unexpectedly.

Description-Behavior Mismatch

High

• Confidence: 97% confidence
• Finding: The pay command makes arbitrary outbound HTTP requests to a caller-supplied URL, parses a 402 payment challenge, signs a payment, and retries with the payment signature. In a skill advertised for market-data access, this creates an unexpected payment-and-exfiltration path where a malicious endpoint can induce the agent to authorize transfers to attacker-controlled recipients.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The x402 example normalizes passing a private key directly on the command line to sign payment authorizations and access third-party paid APIs, without prominent warnings about fund spending, shell history exposure, process-list leakage, or trust in arbitrary resource servers. In an agent setting, this can lead to silent micropayments, credential exposure, and repeated unauthorized spending against attacker-controlled 402 endpoints.

Missing User Warnings

High

• Confidence: 94% confidence
• Finding: The wallet setup flow directs the agent to generate and store a mnemonic without an upfront, explicit warning that this creates a highly sensitive custodial secret whose compromise can irreversibly drain funds. In the context of an agent skill, users may not realize they are authorizing secret custody and cross-chain signing authority, making social/UX-driven misuse more likely.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The documentation repeatedly instructs users to provide private keys directly to command-line utilities for signing and sending transactions, but provides no explicit security warning about credential exposure, shell history leakage, process inspection, or irreversible transaction risk. In a wallet/swap context this is especially dangerous because the material being handled is sufficient to authorize asset transfers.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: This line instructs passing a private key on the command line without an immediate, prominent warning that command arguments are commonly visible to other local users, orchestration systems, audit logs, and shell history. Because this skill manages cryptocurrency wallets, disclosure of a private key is equivalent to full compromise of the associated assets and signing authority.

VirusTotal

55/55 vendors flagged this skill as clean.