x402@0.7.3 security report

Uses a dynamic require('crypto').webcrypto fallback for nonce generation, but only as a fallback when globalThis.crypto is unavailable; this is a legitimate cryptographic primitive usage and not obfuscation or arbitrary code execution.

References Solana RPC URLs (api.devnet.solana.com, api.mainnet-beta.solana.com) and default RPC endpoints for a payment protocol library. These are expected for the library's documented functionality (creating USDC payment header transactions) and are not data exfiltration.

The config object contains hardcoded USDC contract addresses across multiple chains. These are legitimate USDC contract addresses (e.g., 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 on Base) and are not malicious, but hardcoded addresses could be a vector if altered by a malicious fork.

Hardcoded Solana RPC endpoints (api.devnet.solana.com, api.mainnet-beta.solana.com) and WebSocket URLs are used for network communication. This is expected behavior for a payment scheme library but exposes interactions with external infrastructure.

The createNonce function uses a dynamic require('crypto').webcrypto fallback for Node.js environments. While the require target is static, dynamic require calls can be flagged as a potential obfuscation vector.

createNonce uses crypto.getRandomValues (via globalThis.crypto or Node's webcrypto) to generate 32-byte random nonces. This is correct cryptographic practice and not a vulnerability.

The verify function calls client.getCode({ address: payerAddress }) to check if a payer is a deployed smart wallet. This is standard validation but performs an external chain query.

safeBase64Decode and decodeXPaymentResponse use base64 decoding and JSON.parse on potentially untrusted input (HTTP header). While not malicious, it could lead to prototype pollution or denial-of-service if not validated. The regex Base64EncodedRegex limits characters but does not enforce length or content safety for subsequent JSON parsing.

Hardcoded Solana RPC URLs (devnet/mainnet) and WebSocket URLs are present. This is typical for blockchain libraries but could be a vector for man-in-the-middle if not using TLS or if endpoints are compromised. Not malicious by itself.

computeRoutePatterns constructs regular expressions from user-supplied route patterns. Although it escapes special characters, the use of dynamic regex can lead to ReDoS (Regular Expression Denial of Service) if patterns are malicious. The input is likely internal, but this is a potential risk.

The module provides functions like createSigner() and createSignerFromBase58() that accept private keys and create EVM/SVM wallet signers. This is expected functionality for a payment/x402 library, not wallet draining, but it indicates the package handles sensitive key material.

Default Solana RPC URLs (api.devnet.solana.com, api.mainnet-beta.solana.com) and various EVM chain RPC endpoints are hardcoded, but these are public, well-known endpoints and their usage is typical for blockchain client libraries.

settleResponseFromHeader() decodes attacker-controllable header input via Base64 and JSON.parse. Errors would throw but no eval or dynamic execution is involved; input is only parsed, not executed.

The module implements cryptocurrency payment header creation, preparation, and signing for EVM and SVM (Solana) networks. While these are legitimate blockchain operations, the module handles private key signing operations through wallet clients. No private keys are directly handled or exfiltrated in this file, but it's part of a payment signing flow that interacts with wallets—security-sensitive functionality that should be reviewed in full context.

No environment variable harvesting, no child_process spawning, no eval/new Function, no obfuscation, no filesystem manipulation outside package scope, and no install-time execution were observed in this specific file. The code is a thin orchestration layer selecting between EVM/SVM signing paths based on payment requirements.

Fetches latest blockhash and simulates transactions via RPC client. URLs come from paymentRequirements/config parameters, not hardcoded malicious endpoints. Standard blockchain interaction.

Uses __require("crypto") to load Node.js crypto module at runtime for fallback webcrypto access. While used for legitimate nonce generation, dynamic require patterns should be reviewed in third-party packages.

This file is a pure re-export barrel file that imports from an opaque chunk (chunk-3EQVFRKV.mjs) and re-exports symbols including crypto/payment-related names such as decodeXPaymentResponse, processPriceToAtomicAmount, safeBase64Decode, and svm (Solana Virtual Machine) exports. The actual implementation is not visible in this file and must be reviewed in the referenced chunk files to determine intent.

Imports reference hashed chunk filenames (chunk-3EQVFRKV.mjs, chunk-K4TZLEOT.mjs, chunk-EMSAO3AI.mjs). While common in bundled ESM output, these opaque names prevent straightforward auditing of the actual logic, which is relevant for security review of a third-party package.

URLs are constructed dynamically as ${url}/verify, ${url}/settle, ${url}/supported, and ${url}/discovery/resources?${urlParams}. The 'list' function builds a query string from arbitrary config object values, which are passed to a remote server. No obvious SSRF guard restricts the facilitator URL to HTTPS or expected hosts.

The code sends HTTP requests to a facilitator URL that defaults to 'https://x402.org/facilitator' but can be overridden by the caller. Request bodies include 'paymentPayload' and 'paymentRequirements' (payment data) serialized via toJsonSafe. This is a payment verification/settlement client, which is expected behavior for its purpose, but it does transmit potentially sensitive payment payloads to a remote server and follows caller-supplied URLs.

The code calls facilitator.createAuthHeaders() and merges the result into outgoing request headers (authHeaders.verify/settle/supported/list) without validation. If the caller supplies a malicious or compromised facilitator object, arbitrary headers (including credentials) could be attached or leaked to the facilitator URL. However, this is caller-controlled behavior, not an inherent exfiltration by the package itself.