AI-agenten die gebruikmaken van betalingen via de x402 SDK lopen mogelijk een serieus risico. Volgens een analyse van V12 (22 oktober) kunnen kwaadaardige API’s ervoor zorgen dat een agent namens zichzelf een betaling ondertekent die tot de volledige tokenbalans kan oplopen. Daarbij spelen meerdere x402 SDK kwetsbaarheden een rol, waaronder een ontbrekende bestedingslimiet in de standaardclient en validatieproblemen in betalingsverwerking.
Hoewel er volgens V12 geen publiek bekende aanvallen zijn misbruikt met deze issues, is de impact direct: als een agent automatisch ondertekent en de toepassing geen eigen beleid met limieten instelt, kan een kwaadwillende partij het betaalsysteem verleiden tot fout gedrag.
Wat is x402 en waarom raakt dit AI-agenten?
x402 is een open standaard waarmee software, waaronder AI-agenten, tijdens een webrequest zelf kan betalen voor een API-call. In plaats van dat een gebruiker elke betaling handmatig goedkeurt, kan de server aangeven welke betalingsopties beschikbaar zijn. De client kiest vervolgens een optie, ondertekent de betaling en stuurt de aanvraag nogmaals.
Dat maakt het systeem handig, maar ook kwetsbaar als er in de SDK onvoldoende controles zitten. Juist bij agenten die automatisch signeren, kan een fout in de clientlogica leiden tot betalingen die niet overeenkomen met het beoogde budget.
Issue 1: standaardclient had geen bestedingslimiet
De kern van het eerste probleem zit in de default client van de x402 SDK’s. In de periode vóór een fix (release op 18 augustus) stond er volgens V12 geen bestedingslimiet op betalingen. De default client koos daarbij bovendien de eerste optie uit de lijst die de server aanreikt.
Het gevaar: een vijandige API kan een “normale” gegevensaanvraag omzetten in een verzoek om te betalen vanuit de wallet met de volledige balans voor een ondersteunde token. V12 beschrijft dat een eerdere kleine betaling mogelijk ook het walletadres prijsgeeft, zodat een aanvaller de balans vooraf kan inschatten.
Vervolgens kan die aanvaller, mits de token de juiste “signed transfers” ondersteunt, de ondertekende betaling gebruiken om geld in te vorderen.
De fix: in de augustus 18 releases voegden de TypeScript-, Python- en Go-clients bestedingslimieten toe. Sindsdien capen ze standaard elke betaling op $1 en beperken ze betalingen tot specifieke US dollar stablecoins die de SDK herkent (zoals USDC), tenzij de toepassing eigen spend controls instelt.
Issue 2: Solana facilitator kan “token approval” als betaling accepteren
Een tweede probleem draait om de manier waarop de facilitator betalingen controleert en op Solana doorzet naar de blockchain. Op Solana betaalt de facilitator ook de transactiekosten.
V12 meldt dat de TypeScript-facilitator een token-onderdeel anders interpreteerde dan bedoeld: de code controleerde onvoldoende het type instruction. Daardoor kon een “token approval” (een goedkeuring om later tokens te besteden, waarbij er op dat moment geen tokens bewegen) ten onrechte als geldige betaling worden gezien.
Het resultaat is een zogenaamde complete payment bypass: de facilitator levert een betaald resource aan de merchant server terwijl de aanvaller geen tokens levert. De aanvaller heeft wel een token-account nodig, maar zonder saldo kan de facilitator toch betalen voor de transactiefee—herhaalbaar, volgens V12.
V12 geeft aan dat Python en Go deze instructie-check al deden. In TypeScript ontbreekt de check in gepubliceerde versies van @x402/svm vanaf 2.0.0 tot en met 2.22.0; vanaf 2.23.0 is het gecorrigeerd. Bij de analyse is dit gebaseerd op lokale tests en pakketinspectie.
Issue 3: SIWx-login kan worden hergebruikt voor andere websites
Naast betalingen speelt ook authenticatie. x402 heeft een extensie voor “Sign-In-With-X” (SIWx), waarmee een agent kan inloggen door een kort bericht te ondertekenen met zijn wallet. Dat kan helpen om een eerdere betaling te bewijzen in plaats van steeds opnieuw te betalen.
Volgens V12 ondertekende de automated client deze SIWx-berichten zonder goed te verifiëren of de website in het bericht overeenkomt met de website waar de client de 402-respons van ontving.
Een kwaadaardige server zou daardoor een vers loginbericht van een andere site kunnen doorgeven aan de agent. De signature kan vervolgens toegang geven tot de doelsite—op elke plek waar die andere site deze “relayed” message accepteert.
Ook hiervoor kwamen er fixes in de augustus 18 releases. De TypeScript-, Python- en Go-clients zouden vanaf dan weigeren te ondertekenen als de site in het bericht niet matcht. Daarnaast werd de SIWx-specificatie aangepast: een client moet weigeren wanneer de URL’s niet overeenkomen.
Wat je nu moet doen: welke updates tellen
Voor organisaties die x402 integreren in AI-agent tooling is het belangrijkste advies: update naar de laatste versies waarin de controles zijn toegevoegd. V12 noemt daarnaast een extra fix die later is doorgevoerd voor een aparte payment bypass in @x402/core 2.27.0 (september).
Per 23 oktober vermeldde The Hacker News dat de nieuwste versies o.a. zijn: 2.28.0 voor @x402/core, @x402/svm, @x402/extensions, @x402/fetch en @x402/axios; daarnaast 2.28.0 voor de Go-module en 2.25.0 voor de Python package.
TypeScript: update de juiste packages
Voor de bestedingsfix in TypeScript adviseert de rapportage om @x402/fetch of @x402/axios bij te werken naar 2.23.0 of later. Die afhankelijkheid trekt vervolgens de passende @x402/core versie mee.
Voor SIWx geldt: als je SIWx gebruikt, moet je ook @x402/extensions op 2.23.0 of later zetten, zodat de login-check beschikbaar is.
Voor Solana-facilitators moet @x402/svm ook naar 2.23.0 of later.
Eigen spend controls (voor het geval je niet direct kunt upgraden)
Een belangrijk detail: na een upgrade gelden standaard limieten (zoals $1 per betaling) en beperkingen op tokens. Maar die kunnen weer veranderen als je in je app spendControls verkeerd inzet. V12 meldt dat apps met spendControls: false de controles uitschakelen.
Kun je nog niet upgraden, dan kun je volgens V12 toch mitigeren door een payment policy te registreren die opties boven een drempel blokkeert. De oudere clients ondersteunen dit via policy-registratie-functies zoals registerPolicy (TypeScript en Go) en register_policy (Python). In Python is er bovendien een kant-en-klare max_amount policy.
Praktische aandachtspunten voor security teams
Los van de upgrades is het verstandig om een paar controles structureel in te bouwen rond AI-agent betaling en authenticatie:
- Controleer automatische signering: als een agent automatisch betaalt, zorg dan dat je budgets in total en per betaling afdwingt.
- Beperk tokens, netwerken en ontvangers: laat de SDK alleen betalen aan goedgekeurde tokens en endpoints.
- Verifieer SIWx site-binding: signeren mag alleen als het bericht verwijst naar exact de website die de 402-respons stuurde.
- Test met pakketversies: ook afhankelijkheden als fetch/axios/extensions/svm kunnen de echte check bevatten of missen.
Als je wilt vergelijken hoe zulke supply-chain of dependency-risico’s zich voordoen in AI-gateways, kan dit helpen: LiteLLM supply chain aanval via PyPI en Docker. Dat artikel gaat over een ander incident, maar raakt wel aan hetzelfde thema: wat je in je keten installeert, bepaalt of je agenten veilig blijven.
Waarom er geen openbare meldingen waren (en waarom dat toch niets zegt)
V12 geeft aan dat noch V12, noch de x402 Foundation publiekelijk aanvallen hebben gemeld die direct aan deze issues zijn gekoppeld. Ook publiceerde de foundation volgens het rapport geen formele security advisory voor de drie genoemde problemen; in changelogs werden fixes genoteerd zonder expliciet “security fix” te benadrukken.
Bovendien zouden de checks in npm audit en PyPI volgens The Hacker News geen waarschuwingen hebben gegeven voor de laatste versies vóór de fixes. Dat betekent dat ontwikkelaars die alleen op automatische advisories leunen, mogelijk geen upgrade-prompt krijgen.
Daarom is een handmatige review van SDK-versies en integratiebeleid zo belangrijk—zeker als je agenten laat betalen voor API-calls zonder menselijke goedkeuring.
Conclusie: update x402 en klem budgets vast
De x402 SDK kwetsbaarheden die V12 beschrijft, tonen hoe snel een klein verschil in defaults en validatie kan uitgroeien tot financieel en identiteitsgerelateerd risico voor AI-agenten. Het gaat om ontbrekende bestedingslimieten in de default client, een validatieprobleem in de Solana payment facilitator en een mismatch in SIWx-loginondertekening.
De concrete actie is helder: werk x402-onderdelen bij naar de recentste releases (o.a. 2.23.0+ voor de belangrijkste checks en 2.25.0/2.28.0 als actuele versies), stel waar nodig eigen payment policies in en controleer of SIWx alleen ondertekent voor de juiste website. Zo voorkom je dat een agent onbedoeld betaalt met een veel te groot budget of loginrechten misbruikt.
Bron: https://thehackernews.com/2026/10/critical-x402-sdk-flaw-could-let.html
