/
← Voltar ao feed
high cryptocurrency technology financial services

V12 discloses 25 x402 SDK flaws, including three critical ones that let malicious APIs drain AI agent wallets

1 fonte(s) · 1 atualização(ões) · publicado 23/10/2026 05:35 · coletado há 2 horas

Security firm V12 reported on October 22 that the x402 SDKs, an open standard for AI agents paying for API calls over HTTP 402, contained 25 flaws, three rated critical. The most notable was that the default client set no spending limit, so a malicious API could get an agent with an automatic signer to sign a payment for its full balance of a supported token. The x402 Foundation (a Linux Foundation project; Coinbase created x402) fixed all three critical flaws in releases on August 18. Neither V12 nor the foundation has reported attacks using them. The foundation published no security advisory, and The Hacker News found that npm audit and PyPI show no warnings for the vulnerable versions, so developers relying on those checks get no upgrade signal.

Entenda a falha

A vulnerabilidade

V12 found 25 flaws in the x402 SDKs (TypeScript, Python, Go), an open standard for AI agents paying for API calls over HTTP 402, and detailed three critical ones. First, the default client had no spending limit: a malicious API could get an agent with an automatic signer and no app-set payment policy to sign a payment for its full balance of a supported token. Second, the TypeScript Solana facilitator code (@x402/svm 2.0.0 to 2.22.0) accepted a token approval as a valid payment, so an attacker with a token account but no balance could get paid resources for free. Third, the SIWx client signed login messages for a site other than the one it contacted, letting a malicious server relay a login and sign in elsewhere as the agent's wallet. All were fixed in releases on August 18; current versions are 2.28.0 (TypeScript, Go) and 2.25.0 (Python).

Como funciona

In x402, a server that wants payment answers with a 402 status listing options, each with an amount, token and recipient. The client picks one, signs a payment and resends the request. The default client took the first option without checking the amount, so a hostile server could first learn the wallet address from a small payment, look up the balance and ask for all of it. On Solana, the facilitator checks each payment and submits it, paying the fee. It verified the call went to an allowed token program, then read it as a transfer without checking the instruction type, so an approval, which moves no tokens, passed. For SIWx, the agent signs a login message naming a website, and the client did not compare that site to the one that sent the 402 response.

Por que é vulnerável

All three are missing validation. The client trusted whatever the server offered, with no amount cap or token allowlist. The TypeScript Solana code assumed any instruction to the allowed token program was a transfer; an approval differs only in its first byte, and the Python and Go SDKs already checked the instruction type. The SIWx client did not bind the signed message to the origin that asked for it. The fixes add spend controls (default cap of $1 per payment, recognized USD stablecoins only), the instruction-type check in TypeScript, and a refusal to sign when the message's site does not match the 402 response URL. The SIWx spec was also changed to require that refusal.

Onde está

The articles point to the default client in @x402/core (spend controls via @x402/fetch and @x402/axios 2.23.0+), the TypeScript Solana facilitator code in @x402/svm, and createSIWxPayload in @x402/extensions; no commit is named.

Como foi descoberta

V12, a security firm, found the flaws through code review and local tests, and published its findings on October 22. The x402 Foundation, a Linux Foundation project maintaining the SDKs (Coinbase created x402), had already fixed the three critical flaws in the August 18 releases. Neither V12 nor the foundation has reported attacks. The foundation published no security advisory and its changelogs do not label the fixes as security fixes; The Hacker News found that npm audit and PyPI showed no warnings for the vulnerable versions as of October 23. The articles do not say when V12 reported the flaws to the foundation.

Explicação gerada por IA a partir da matéria e dos artigos, em 23/10/2026 07:16.

Detalhes técnicos

  • No spending limit in the default client: the client picked the first payment option in a 402 response with no amount cap. A hostile server could learn the wallet address from an earlier small payment, look up the balance, and request all of it. For tokens that support signed transfers, the attacker could then submit the signed payment and collect the funds. Only agents with automatic signing and no app-set payment policy were at risk.
  • Solana token approval accepted as payment: the TypeScript facilitator code (@x402/svm 2.0.0 to 2.22.0) checked for an allowed token program but did not check the instruction type. A token approval differs from a transfer only in its first byte, so in V12's local test it was accepted as a valid payment ("a complete payment bypass"). The attacker needed a token account but no balance, and the facilitator paid the fee. The Python and Go SDKs already checked the instruction type. The test sent no live transaction.
  • Sign-In-With-X (SIWx) relay: the automated client signed login messages without verifying that the site named in the message was the one it had contacted. A malicious server could relay a fresh login message from another site and use the agent's signature to log in there as the agent's wallet.
  • V12 found the flaws through code review and local tests.

Remediação

  • Upgrade to the latest releases: 2.28.0 for @x402/core, @x402/svm, @x402/extensions, @x402/fetch and @x402/axios; v2.28.0 for the Go module; 2.25.0 for the Python package. These also include a later fix for a separate payment bypass in @x402/core 2.27.0.
  • TypeScript minimums are 2.23.0 for @x402/fetch or @x402/axios (spend controls), @x402/extensions (SIWx check) and @x402/svm (Solana facilitators). Code calling createSIWxPayload directly must now pass the 402 response URL.
  • After the upgrade, clients are capped at $1 per payment and limited to recognized USD stablecoins such as USDC. Apps that pass spendControls: false turn these controls off.
  • If upgrading is not possible, register a payment policy that drops options above a set amount (registerPolicy in TypeScript and Go; register_policy and max_amount in Python).
  • V12 advises checking that a SIWx message identifies the contacted site before signing, setting per-payment and total budgets, and limiting allowed tokens, networks and recipients.

Linha do tempo

  1. thehackernews.com ↗ · pub. 23/10/2026 05:35 · coletado 23/10 07:00 primeiro registro

    V12 discloses 25 x402 SDK flaws, including three critical ones that let malicious APIs drain AI agent wallets

    ler a análise desta fonte

    Security firm V12 reported on October 22 that the x402 SDKs, an open standard for AI agents paying for API calls over HTTP 402, contained 25 flaws, three rated critical. The most notable was that the default client set no spending limit, so a malicious API could get an agent with an automatic signer to sign a payment for its full balance of a supported token. The x402 Foundation (a Linux Foundation project; Coinbase created x402) fixed all three critical flaws in releases on August 18. Neither V12 nor the foundation has reported attacks using them. The foundation published no security advisory, and The Hacker News found that npm audit and PyPI show no warnings for the vulnerable versions, so developers relying on those checks get no upgrade signal.

    Technical Details

    • No spending limit in the default client: the client picked the first payment option in a 402 response with no amount cap. A hostile server could learn the wallet address from an earlier small payment, look up the balance, and request all of it. For tokens that support signed transfers, the attacker could then submit the signed payment and collect the funds. Only agents with automatic signing and no app-set payment policy were at risk.
    • Solana token approval accepted as payment: the TypeScript facilitator code (@x402/svm 2.0.0 to 2.22.0) checked for an allowed token program but did not check the instruction type. A token approval differs from a transfer only in its first byte, so in V12's local test it was accepted as a valid payment ("a complete payment bypass"). The attacker needed a token account but no balance, and the facilitator paid the fee. The Python and Go SDKs already checked the instruction type. The test sent no live transaction.
    • Sign-In-With-X (SIWx) relay: the automated client signed login messages without verifying that the site named in the message was the one it had contacted. A malicious server could relay a fresh login message from another site and use the agent's signature to log in there as the agent's wallet.
    • V12 found the flaws through code review and local tests.

    Remediation

    • Upgrade to the latest releases: 2.28.0 for @x402/core, @x402/svm, @x402/extensions, @x402/fetch and @x402/axios; v2.28.0 for the Go module; 2.25.0 for the Python package. These also include a later fix for a separate payment bypass in @x402/core 2.27.0.
    • TypeScript minimums are 2.23.0 for @x402/fetch or @x402/axios (spend controls), @x402/extensions (SIWx check) and @x402/svm (Solana facilitators). Code calling createSIWxPayload directly must now pass the 402 response URL.
    • After the upgrade, clients are capped at $1 per payment and limited to recognized USD stablecoins such as USDC. Apps that pass spendControls: false turn these controls off.
    • If upgrading is not possible, register a payment policy that drops options above a set amount (registerPolicy in TypeScript and Go; register_policy and max_amount in Python).
    • V12 advises checking that a SIWx message identifies the contacted site before signing, setting per-payment and total budgets, and limiting allowed tokens, networks and recipients.