Goldrush X402

• Outcome: Review
• Latest audit: Sep 11, 2026 · 1:21 PM UTC
• Version: 3.0.5

Overview

The skill is coherent documentation for wallet-paid blockchain API access, but it should be reviewed because its examples give an agent a wallet private key and allow automatic payments without clear local spending controls.

Review this skill before use. Use only a dedicated low-balance wallet, preferably testnet-only, never reuse a wallet that holds valuable assets, store the private key in a secrets manager, pin and audit the x402 dependencies, and add local payment controls for chain, token, recipient, per-request amount, retries, and total spend before allowing an agent to run autonomously.

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 (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:30
• Finding: Unpinned Third-Party Wallet Dependencies<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:30`; duplicate installation guidance appears in `references/overview.md:134-141` **Vulnerability Type**: T08: Insecure Dependencies **Risk Level**: Medium ### Vulnerable Code ```markdown **Install:** `npm install @x402/core @x402/evm` ``` The corresponding installation instructions in `references/overview.md` are: ```bash npm install @x402/core @x402/evm ``` ```bash yarn add @x402/core @x402/evm ``` ### Technical Analysis The Skill instructs users to install `@x402/core` and `@x402/evm` without specifying exact reviewed versions, a lockfile, integrity hashes, or package provenance requirements. The packages subsequently operate in the same process that receives wallet signing material through `WALLET_PRIVATE_KEY`. Because the commands resolve package versions from the npm registry at installation time, the code installed by a user can differ from the code that existed when the Skill was reviewed. A compromised maintainer account, malicious future release, registry compromise, or dependency-chain compromise could therefore introduce arbitrary installation or runtime behavior. This is a supply-chain weakness rather than evidence that the named packages are currently malicious. ### Attack Path 1. An attacker compromises a package maintainer, release process, registry account, or transitive dependency. 2. The attacker publishes a malicious release under a version range accepted by the unpinned installation command. 3. A user follows the Skill and runs `npm install @x402/core @x402/evm` or the equivalent Yarn command. 4. The package executes malicious lifecycle or runtime code with the privileges of the application process. 5. When the application constructs the payment client, malicious code may inspect environment variables, modify payment behavior, or transmit signing material. 6. The attacker can then abuse any credentials or process-level access obtained by the compromised package. ### I ...[truncated 661 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin both direct dependencies to exact, reviewed versions rather than accepting the latest compatible release. 2. Include and verify a committed lockfile, and recommend reproducible installation with `npm ci`. 3. Verify package provenance, signatures, registry ownership, and published integrity metadata before installation. 4. Audit direct and transitive dependencies with an appropriate software-composition analysis tool. 5. Disable package lifecycle scripts during installation where compatible with the packages: ```bash npm ci --ignore-scripts ``` 6. Run the payment client in a dedicated, least-privileged process or container with minimal filesystem and network access. 7. Do not expose a general-purpose wallet key directly to the dependency. Prefer a constrained external signer that enforces network, token, recipient, and amount policies. 8. Establish a controlled upgrade process in which new dependency versions are reviewed and tested before deployment. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:14
• Finding: Automatic Wallet Payments Lack Documented Local Spending Controls<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:14-25,36-41`; related autonomous-agent instructions appear in `references/ai-agents.md:26,60-76` and `references/overview.md:145-165` **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: Medium ### Vulnerable Code The primary example in `SKILL.md` gives the client direct access to the wallet key and enables automatic payment handling: ```typescript import { HTTPClient } from "@x402/core"; import { ExactEvmScheme } from "@x402/evm"; const client = new HTTPClient({ scheme: new ExactEvmScheme({ network: "eip155:84532", // Base Sepolia privateKey: process.env.WALLET_PRIVATE_KEY, }), }); // Get token balances — payment handled automatically const balances = await client.get( "https://x402.goldrush.dev/v1/eth-mainnet/address/demo.eth/balances_v2/" ); console.log(balances); ``` The documented payment sequence is: ```text 1. REQUEST → Agent calls endpoint without payment 2. 402 → Server responds with payment instructions (amount, token, recipient) 3. PAY → Agent signs payment with stablecoins on Base, retries with proof 4. DATA → Server validates request *before* charging, returns data ``` The Skill then states: ```markdown The x402 client libraries handle steps 2-3 automatically. From your code, it's just a GET request. ``` The autonomous-agent guidance further states: ```markdown The x402 protocol was designed with machine-to-machine payments in mind. An AI agent with a funded wallet can autonomously access the full GoldRush API - no signup flow, no credentials to rotate, no billing portal, no human in the loop. ``` ### Technical Analysis The demonstrated design gives an HTTP payment client direct access to a funded wallet private key. The client consumes payment instructions supplied by a remote server and automatically signs a payment before retrying the request. The documentation advises agents to inspect endpoint prices, but it does no ...[truncated 2665 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace direct private-key access with a dedicated signer or wallet service that independently enforces payment policy. 2. Validate every payment instruction locally before signing: - Require the expected chain ID. - Allow only explicitly approved token contracts. - Allow only explicitly approved payment recipients. - Reject expired, malformed, or replayed payment requests. 3. Enforce a maximum payment amount per request and reject any response above that threshold. 4. Track cumulative spending per session, hour, and day, with a fail-closed budget limit. 5. Limit the number of paid requests and automatic retries initiated for one user task. 6. Require explicit human approval when the amount, recipient, endpoint, or selected pricing tier falls outside a preapproved policy. 7. Use a dedicated low-balance wallet that is not reused for unrelated assets or networks. 8. Log the endpoint, amount, token, recipient, transaction identifier, and budget state for every payment without logging the private key. 9. Add an example demonstrating payment validation rather than presenting automatic signing as an unrestricted GET operation. 10. Treat discovery metadata and HTTP 402 responses as untrusted input, even when delivered over TLS. ]]>

SkillSpector

Vulnerability Patterns

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

Findings (5)

Vague Triggers

Medium

• Confidence: 92% confidence
• Finding: The description says to use this skill whenever the user is 'building an AI agent that needs blockchain data', 'wants wallet-based micropayments', or 'wants no-signup/no-onboarding blockchain data access'. These triggers are expansive and lack clear boundaries or exclusion examples, which could cause the skill to be invoked for many ordinary blockchain data requests where another skill may be more appropriate.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The example instructs users to supply a wallet private key and enables automatic payment handling, but it omits warnings about secret handling, hot-wallet risk, and the fact that requests can spend funds. In an agent context, this can lead to unsafe key exposure or unattended micropayment spending if developers copy the example directly into production workflows.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: This markdown file includes a TypeScript example that reads `process.env.WALLET_PRIVATE_KEY`, which is a sensitive credential. The surrounding text explains how to use the key but does not warn users about securely storing the private key or the risks of exposing it.

External Transmission

Medium

• Category: Data Exfiltration

Content

All 60+ Foundational API endpoints are available through the x402 proxy. Endpoint paths mirror the Foundational API.

**Base URL:** `https://x402.goldrush.dev/v1` (replaces `https://api.covalenthq.com/v1`)

### Key Data Endpoints

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

All 60+ Foundational API endpoints are available through the x402 proxy. Endpoint paths mirror the Foundational API.

**Base URL:** `https://x402.goldrush.dev/v1` (replaces `https://api.covalenthq.com/v1`)

### Key Data Endpoints

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Static analysis

No suspicious patterns detected.