AI-agents die API-aanroepen betalen met de x402 SDK’s konden een betaling ondertekenen voor hun volledige saldo van een ondersteund token als een kwaadaardige API erom vroeg, zei beveiligingsbedrijf V12 op 22 oktober.
De oorzaak was de standaardclient van de SDK’s, die geen bestedingslimiet instelde totdat de releases van 18 augustus er één toevoegde. Het risico beperkte zich tot agents die automatisch betalingen ondertekenden en waarvan de apps geen eigen limieten instelden.
De ontbrekende limiet is één van de 25 kwetsbaarheden die V12 in de x402-code vond, en een van de drie die het bedrijf als kritiek waardeerde en in detail beschreef. De x402 Foundation, die de SDK’s onderhoudt, had alle drie de kritieke kwetsbaarheden al opgelost in de releases van 18 augustus.
Een van de andere twee stelde een facilitator, de dienst die x402-betalingen controleert, in staat een Solana-transactie te accepteren die geen tokens verplaatste als een geldige betaling. Onder de x402 SDK’s had alleen de TypeScript-versie dit euvel. De andere kwetsbaarheid liet een kwaadaardige server een agent een inlogbericht voor een andere website laten ondertekenen.
V12 ontdekte de fouten door de code te beoordelen en lokale tests uit te voeren. Noch V12 noch de x402 Foundation heeft publiekelijk meldingen gedaan van aanvallen waarbij deze kwetsbaarheden zijn uitgebuit.
De foundation heeft geen security advisory gepubliceerd voor de drie issues, en in de changelogs worden de fixes genoemd zonder ze als beveiligingsfixes te etiketteren. Op 23 oktober gaf The Hacker News aan dat npm audit geen waarschuwingen teruggaf voor de laatste TypeScript-releases vóór de fixes, en dat PyPI geen kwetsbaarheden vermeldde voor de laatste Python-release daarvoor. Een ontwikkelaar die op die checks vertrouwt krijgt dus geen waarschuwing om te upgraden.
Coinbase creëerde x402 en droeg het dit jaar over aan de x402 Foundation, een project van de Linux Foundation waarvan leden onder meer Visa en Mastercard zijn. Coinbase heeft de meest senior zetel in het technische stuurgroeplid van de foundation.
Geen bestedingslimiet in de standaardclient
x402 is een open standaard die software, waaronder AI-agents, in staat stelt te betalen voor een API-aanroep binnen het webverzoek zelf, zonder dat een persoon elke betaling goed hoeft te keuren.
Een server die betaling wil antwoordt met de HTTP-statuscode 402 Payment Required en geeft zijn betaalopties weer, elk met een bedrag, een token en een ontvanger. De client kiest er één, ondertekent een betaling en stuurt het verzoek opnieuw.
De standaardclient nam de eerste optie in de lijst en stelde vóór de fix geen limiet aan het bedrag.
Een vijandige API kon dat misbruiken om een routinematig datarequest te veranderen in een verzoek om het volledige saldo van een ondersteund token van de wallet, zei V12. Een eerdere kleine betaling zou het wallet-adres kunnen onthullen, zodat de server eerst het saldo kon opzoeken.
Met een automatische ondertekenaar en zonder door de app ingestelde betalingspolicy kon de client een betaling voor dat bedrag ondertekenen. Voor een token dat ondertekende transfers ondersteunt kon de aanvaller daarna de ondertekende betaling indienen en de fondsen innen.
De releases van 18 augustus voegden bestedingscontroles toe aan de TypeScript-, Python- en Go-clients. Standaard beperken ze nu elke betaling tot $1 en staan ze alleen door de SDK herkende Amerikaanse stablecoins toe, zoals USDC.
Token-goedkeuringen geaccepteerd als Solana-betalingen
In x402 vertrouwt een verkoper op een facilitator om elke betaling te controleren en deze naar de blockchain te sturen. Op Solana betaalt de facilitator ook de transactiekosten.
De TypeScript-facilitatorcode voor Solana controleerde dat een betaling hoorde bij een zogenaamd allowed token program, maar interpreteerde deze daarna als een transfer zonder het instructietype te controleren. Een tokengoedkeuring (approval), die een ander account later toestaat tokens uit te geven maar zelf geen tokens verplaatst, verschilt van een transfer alleen in de eerste byte van de instructie.
In V12’s lokale test accepteerde de facilitator zo’n approval als een geldige betaling. De test stuurde geen live-transactie.
Een verkoper die op die facilitator vertrouwt kon dus een betaalde bron leveren terwijl er geen tokens werden ontvangen, zei V12, en noemde het “een volledige betaling-bypass.” De aanvaller had een tokenaccount nodig, maar geen saldo, en de facilitator betaalde elke keer de transactiekosten.
De Python- en Go-SDK’s controleerden het instructietype al. De releases van 18 augustus voegden dezelfde controle toe aan de TypeScript-code.
Elke gepubliceerde @x402/svm-release van 2.0.0 tot 2.22.0 miste die controle, en elke release vanaf 2.23.0 bevat die controle, vond The Hacker News door de gepubliceerde pakketten te doorzoeken.
Inlogberichten ondertekend voor andere websites
x402 heeft ook een aanmeldextensie genaamd Sign-In-With-X (SIWx). Daarmee kan een agent inloggen door een kort bericht met zijn wallet te ondertekenen, bijvoorbeeld om een eerdere betaling te bewijzen in plaats van opnieuw te betalen. Op Ethereum vermeldt het bericht de website, het wallet-adres en een eenmalige code.
De geautomatiseerde client ondertekende deze berichten zonder te verifiëren dat de in het bericht genoemde website overeenkwam met de site die de client had gecontacteerd.
Een kwaadaardige server kon een nieuw inlogbericht van een andere site ophalen, het aan de agent voorleggen en de handtekening gebruiken om op die andere site in te loggen als het wallet-adres van de agent, zei V12. Dat zou werken waar die andere site het doorgestuurde bericht accepteerde, en de aanvaller zou de toegang krijgen die de login gaf.
De releases van 18 augustus zorgen ervoor dat de TypeScript-, Python- en Go-clients weigeren te ondertekenen tenzij de site in het bericht overeenkomt met de site die de 402-respons stuurde. Het project wijzigde ook de SIWx-specificatie: die zegt nu expliciet dat een client moet weigeren te ondertekenen als de twee sites niet overeenkomen.
TypeScript-code die direct createSIWxPayload aanroept moet nu de URL van de 402-respons doorgeven, na eventuele redirects. De wrappers @x402/fetch en @x402/axios geven die URL automatisch door.
Wat te updaten
Upgraden naar de nieuwste releases brengt ook latere fixes, waaronder een aparte betaling-bypass in @x402/core 2.27.0 in september. Op 23 oktober waren de nieuwste versies 2.28.0 voor @x402/core, @x402/svm, @x402/extensions, @x402/fetch en @x402/axios, versie v2.28.0 voor de Go-module en 2.25.0 voor het Python-pakket.
In TypeScript krijgen clients de bestedingsfix door @x402/fetch of @x402/axios bij te werken naar 2.23.0 of later, wat de overeenkomstige @x402/core meebrengt. Apps die SIWx gebruiken hebben ook @x402/extensions 2.23.0 of later nodig, waarin de login-controle zit. Facilitators die Solana-betalingen controleren hebben @x402/svm 2.23.0 of later nodig.
Na de upgrade worden bestaande clients standaard beperkt tot $1 per betaling en toegestane stablecoins, tenzij de app zelf bestedingscontroles instelt. Apps die spendControls: false doorgeven schakelen al deze controles uit.
Teams die nog niet kunnen upgraden kunnen een betaalbeleid registreren dat elke optie boven een ingesteld bedrag weglaat. De oudere clients ondersteunen dit met registerPolicy in TypeScript en Go en register_policy in Python, waarin ook een kant-en-klare max_amount-policy aanwezig is.
V12 raadt aan dat clients controleren of een SIWx-inlogbericht de site identificeert die ze hebben gecontacteerd vóór ondertekening, budgetten instellen per betaling en in totaal, en beperken welke tokens, netwerken en ontvangers ze zullen betalen.
