# x402-fetch@0.7.3 security report (npm)

- Verdict: **Needs review** (risk level: medium)
- Scanned: 2026-10-04T16:46:44.000Z
- Files reviewed: 2
- Findings: 5 medium, 3 low severity findings
- Report: https://security.togoder.click/npm/x402-fetch
- Source: Togoder Security (https://security.togoder.click), AI source-code review

## Summary

Togoder Security scanned the npm package x402-fetch@0.7.3 on Oct 4, 2026. An AI review of 2 source files produced 5 medium, 3 low severity findings. The overall verdict is medium: the findings flag risky but common patterns (dynamic code, unsafe defaults, broad file or network access) rather than confirmed malware.

## Findings

### [medium] Cryptocurrency wallet interaction

Finding ID: `NPS-2E2235857F6F`

File: `dist/cjs/index.js:23`

The library accepts a walletClient and uses it to create payment headers via createPaymentHeader. This involves signing transactions or payment authorizations with the user's private key or wallet. If the walletClient is misconfigured or the endpoint is malicious, funds could be drained. The maxValue parameter defaults to 0.1 USDC (BigInt(0.1 * 10 ** 6)), providing some protection, but this limit can be overridden by the caller.

### [medium] Lack of validation on payment requirements

Finding ID: `NPS-7B50C91D693F`

File: `dist/cjs/index.js:33`

The code parses payment requirements from the server response using PaymentRequirementsSchema.parse, but it does not validate that the selected payment requirements are safe or expected beyond a max value check. A malicious server could request payment to an attacker-controlled address, and the library would automatically sign and send the payment.

### [medium] Suspicious network requests

Finding ID: `NPS-1F26164E82EC`

File: `dist/cjs/index.js:54`

The wrapFetchWithPayment function intercepts HTTP responses and automatically attaches a payment header containing a cryptographically signed payment authorization when a 402 Payment Required status is received. While this is the intended behavior of the x402 payment protocol, it means the library can automatically authorize cryptocurrency payments to any server that returns a 402 response, potentially draining wallet funds if used with a compromised or malicious endpoint.

### [medium] Cryptocurrency Payment Interception

Finding ID: `NPS-934FC54D39B6`

File: `dist/esm/index.mjs:18`

The code wraps fetch to automatically handle HTTP 402 (Payment Required) responses by creating and attaching a cryptocurrency payment header using the provided wallet client. It checks and caps the payment amount via maxValue comparison, which is a security control, but the core behavior involves authorizing blockchain payments based on server responses without explicit end-user confirmation per transaction.

### [medium] Dynamic HTTP Header Injection

Finding ID: `NPS-A27518C221F6`

File: `dist/esm/index.mjs:55`

The wrapper injects an 'X-PAYMENT' header containing a signed payment authorization into subsequent requests. While this is the intended x402 protocol behavior, automatic payment signing based on remote server response data could be abused if the fetch endpoint is controlled by a malicious actor returning crafted 402 payment requirements.

### [low] Dynamic imports or module loading with computed input

Finding ID: `NPS-3A7CBC40423E`

File: `dist/cjs/index.js:20`

The code requires modules from the 'x402' package (x402/types, x402/client, x402/shared). While these are static imports, the overall functionality depends on external packages that handle payment signing and network selection. If any of these dependencies are compromised, malicious code could be executed. This is a supply chain risk.

### [low] External Dependency on x402 Package

Finding ID: `NPS-30FC0ECB4B51`

File: `dist/esm/index.mjs:2`

Core security-relevant logic (createPaymentHeader, PaymentRequirementsSchema, signer validation) is delegated to an external 'x402' package. The safety of this module depends entirely on the integrity of that dependency, which is not auditable from this file alone.

### [low] Retry Loop Guard

Finding ID: `NPS-4AB2E1CC176D`

File: `dist/esm/index.mjs:46`

The code uses a custom __is402Retry flag on the init object to prevent infinite payment retry loops. This is a reasonable safeguard, though relying on user-supplied init mutation is brittle.

## Files reviewed

- `dist/cjs/index.js` (medium): The code implements a payment protocol that automatically signs cryptocurrency payments in response to HTTP 402 responses, which could lead to fund drainage if used with malicious endpoints, though it includes a default maximum payment limit.
- `dist/esm/index.mjs` (medium): This module implements an x402 automatic crypto payment fetch wrapper; no overt malware is present, but it auto-signs blockchain payments in response to server-provided 402 challenges, which is a financially sensitive capability requiring scrutiny.

AI analysis is guidance, not a guarantee. Methodology: https://security.togoder.click/methodology