Bondterminal X402

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:26 PM UTC
• Version: 0.2.1

Overview

The skill is purpose-aligned, but it teaches automatic real USDC payment signing from a configured wallet without local payment-policy checks or user confirmation.

Review before installing or using with real funds. Use a dedicated low-balance Base USDC wallet, add local checks for maximum amount, token, recipient, network, and expiration before signing, and prefer pinned dependency versions with a lockfile. Do not connect a general-purpose or high-balance wallet to the automatic payment example as written.

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)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:88

Finding

Untrusted Payment Terms Are Signed Without Local Policy Validation

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 88-94
Vulnerability Type: Missing validation of externally supplied cryptocurrency payment terms
Risk Level: High

javascript

const paymentRequired = httpClient.getPaymentRequiredResponse(
  (name) => res.headers.get(name),
  await res.json()
);
const payload = await httpClient.createPaymentPayload(paymentRequired);

Technical Analysis

The example treats payment requirements returned by the remote API as trusted input and immediately creates a signed EIP-3009 payment payload. Although the documentation states that a request costs $0.01 USDC on Base mainnet, the code does not independently enforce:

• The maximum or exact payment amount
• The expected USDC token contract
• The intended payment recipient
• The expected chain and network
• An acceptable authorization validity period
• The expected payment scheme
• A relationship between the payment request and the requested endpoint

Registering an EVM payment implementation for Base does not, by itself, enforce the documented price or intended recipient. If the API origin or its valid HTTPS response is compromised, it could provide altered payment terms that the configured wallet signs automatically.

Attack Path

1. A user invokes one of the documented paid BondTerminal endpoints.
2. The API server, or an attacker capable of controlling its valid HTTPS response, returns HTTP 402 containing manipulated payment requirements.
3. The client parses the attacker-controlled response using getPaymentRequiredResponse.
4. The code passes those terms directly to createPaymentPayload without checking the amount, asset, recipient, network, or expiration.
5. The configured wallet signs the resulting EIP-3009 authorization.
6. The signed authorization is returned to the remote service and may be submitted for settlement.

Impact Assessment

Successful exploitation could auth ...[truncated 412 chars]

Remediation

View remediation

Remediation Suggestions

• Define an explicit local payment policy before creating any signature.
• Verify that the chain ID is exactly Base mainnet (eip155:8453).
• Allow only the expected canonical USDC contract address.
• Allow only a documented and independently verified recipient address.
• Convert the amount to atomic token units and reject any amount above the documented $0.01 charge.
• Validate authorization start and expiration times against a short permitted window.
• Verify that the requested payment scheme and API endpoint match the intended operation.
• Reject payment requirements containing unknown or duplicate fields instead of silently accepting them.
• Require explicit user confirmation whenever payment terms differ from a previously approved policy.
• Use a dedicated low-balance wallet with a strict spending budget rather than a general-purpose wallet.
• Add automated negative tests proving that altered amounts, assets, recipients, networks, and expiration periods are rejected before signTypedData can be called.

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:56

Finding

Unpinned npm Dependencies Create a Mutable Supply-Chain Boundary

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 56-58
Vulnerability Type: Unpinned third-party dependencies without lockfile integrity
Risk Level: Medium

bash

npm install @x402/core @x402/evm viem

Technical Analysis

The installation command does not specify exact dependency versions. The audited project also contains no package manifest or lockfile fixing the complete transitive dependency graph and integrity hashes. Consequently, users following the instructions at different times can install code that was not part of this audit.

npm installation can also execute package lifecycle scripts with the user's privileges. In addition, these dependencies participate directly in wallet-signing and payment construction, so a compromised or unexpectedly changed version could alter security-critical transaction behavior even without an installation script.

This finding identifies unsafe dependency reproducibility and supply-chain exposure. The audit did not establish that any named package is currently malicious.

Attack Path

1. An attacker compromises a dependency maintainer account, a package release, or a transitive dependency resolved by npm.
2. A user follows the documented unversioned npm install command.
3. npm resolves the changed package graph instead of a previously reviewed set of versions.
4. Malicious package code may execute through an installation lifecycle script or when the application imports the dependency.
5. The dependency could access the process environment, tamper with payment construction, request deceptive signatures, or modify outbound payment data.

Impact Assessment

Package code and lifecycle scripts generally execute with the privileges of the user running npm or the application. Depending on the runtime environment, exploitation could affect project files, environment variables, network communications, and wallet-signing behavior accessible to the process. ...[truncated 261 chars]

Remediation

View remediation

Remediation Suggestions

• Specify exact, reviewed versions for every direct dependency rather than floating versions.
• Add and commit a package.json and lockfile containing integrity metadata for the complete dependency graph.
• In automated and reproducible environments, install with npm ci rather than allowing dependency resolution through npm install.
• Review dependency provenance, release signatures where available, maintainer changes, and the resolved transitive dependency graph.
• Run npm audit or an equivalent software-composition analysis tool as an additional control.
• Consider installation with lifecycle scripts disabled, such as npm ci --ignore-scripts, after verifying that the selected packages function correctly under that restriction.
• Execute dependency installation and the payment client in a least-privileged isolated environment.
• Keep wallet secrets outside the npm installation environment and prefer a hardware wallet, KMS signer, or narrowly scoped signing service.
• Use automated dependency update tooling that opens reviewed changes rather than silently resolving new releases during installation.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (2)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The skill provides runnable payment-handling example code that will automatically react to a 402 response by creating a payment payload and retrying the request with a wallet-backed payment signature, but it does not place an explicit warning immediately рядом with the example that real funds may be spent. In an agent-skill context, users or downstream agents may copy or invoke this flow without realizing that ordinary API calls can trigger irreversible micropayments from a configured wallet.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The documentation is internally inconsistent: earlier examples advertise searches like AL30, while the identifier rules later state that bare local tickers such as AL30 and GD30 will fail and require a D or C suffix. This can mislead downstream agents or users into constructing invalid requests, causing avoidable failures, retries, and potentially unnecessary paid x402 requests in a metered API flow.

Content

No source excerpt is available for this finding.