Drie kritieke x402-fouten tonen risico’s van automatisch betalende AI-agents
Een automatisch betalende agent kon via x402 onder voorwaarden toestemming geven om zijn volledige tokensaldo uit te geven. Een andere fout liet een Solana-goedkeuring doorgaan alsof er werkelijk was betaald.
Beveiligingsbedrijf V12 beschreef op 22 oktober drie kritieke kwetsbaarheden in x402. De fouten waren volgens de onderzoekers uiterlijk 20 augustus al gerepareerd. Het gaat dus om openbaarmaking van oude problemen, niet om drie bekende lekken die vandaag nog openstaan.
V12 vond 25 kwetsbaarheden in x402
V12 onderzocht de code van x402, een protocol waarmee software rechtstreeks voor digitale diensten kan betalen.
Een server kan bijvoorbeeld aangeven dat een dataset $0,10 kost. De client ontvangt daarop betalingsvoorwaarden, ondertekent de betaling en vraagt de dienst opnieuw op.
Dat proces is aantrekkelijk voor AI-agents die zelfstandig data, rekentijd of andere diensten willen inkopen.
V12 zegt in zijn onderzoeksrapport in totaal 25 kwetsbaarheden te hebben gevonden.
Drie daarvan kregen het label kritiek.
Dertien andere bevindingen werden als hoog risico gemeld. Later volgden nog negen problemen met middelhoge of lage ernst.
Een server kon het volledige saldo proberen op te vragen
De eerste kritieke fout zat aan de kant van de betalende client.
In de onderzochte standaardopzet ontbrak een harde bestedingslimiet voordat een betaling werd ondertekend.
De server leverde onder meer het bedrag, de token, het netwerk en het ontvangstadres aan.
Een kwaadwillende server kon daardoor niet alleen een normale prijs van bijvoorbeeld $0,10 opgeven.
Hij kon een veel groter bedrag vragen.
Wanneer een automatisch ondertekenende client geen eigen limieten had ingesteld, kon die betaling vervolgens worden goedgekeurd.
Voor een gefinancierde wallet kon dat volgens V12 oplopen tot het beschikbare saldo van een ondersteunde token.
Een normale API-aanvraag kon zo een grote machtiging worden
Dat risico ontstaat doordat een agent vaak juist is ontworpen om zonder menselijke bevestiging te handelen.
Een gebruiker hoeft dan niet voor iedere dataset of API-aanroep opnieuw op ‘betalen’ te drukken.
Dat gemak maakt de controle vóór de handtekening belangrijk.
De server mag wel vertellen hoeveel zijn dienst kost.
Hij hoort daarmee niet automatisch te bepalen hoeveel de wallet maximaal mag uitgeven.
Die grens moet aan de kant van de betaler liggen.
Nieuwe standaard zet betaling op maximaal één dollar
De x402-code kreeg daarom zogenoemde spend_controls.
De wijzigingen in de code voeren controles uit voordat de client ondertekent.
Voor herkende tokens die aan de Amerikaanse dollar zijn gekoppeld, geldt standaard een maximum van $1 per betaling.
Dat sluit aan bij de huidige x402-documentatie voor standaardassets.
Ontwikkelaars kunnen andere tokens toestaan en eigen maximumbedragen instellen.
Ze kunnen de spend controls ook expliciet uitschakelen.
Een actuele bibliotheek betekent daardoor niet dat iedere toepassing automatisch exact dezelfde bescherming gebruikt.
Eén dollar per betaling is nog geen dagbudget
Daar zit meteen een tweede grens.
Een limiet van $1 voorkomt dat één losse serverreactie rechtstreeks om bijvoorbeeld $10.000 vraagt.
Maar honderd toegestane betalingen van $1 zijn samen nog steeds $100.
Een per-transactielimiet begrenst dus niet hoeveel een agent gedurende een uur, dag of complete taak kan uitgeven.
V12 adviseert daarom naast een maximum per betaling ook een totaalbudget.
Ook toegestane tokens, netwerken en ontvangers moeten volgens de onderzoekers vooraf worden begrensd.
Bij automatisch geld uitgeven is één limiet simpelweg niet genoeg.
Solana-goedkeuring werd behandeld als echte betaling
De tweede kritieke fout zat aan de andere kant van de transactie.
Een verkoper moet erop kunnen vertrouwen dat een goedgekeurde x402-betaling daadwerkelijk geld heeft verplaatst.
Bij de onderzochte Solana-code ging dat mis.
De verifier kon een ApproveChecked-instructie interpreteren alsof het een TransferChecked-betaling was.
Die twee instructies doen iets fundamenteel anders.
Een transfer verplaatst tokens.
Een approval geeft iemand toestemming om tokens te besteden.
Dat laatste is nog geen betaling.
Verkoper kon dienst leveren zonder tokens te ontvangen
V12 bouwde hiervoor een lokale test.
De onderzoekers maakten een approval die door de getroffen controle als geldige betaling werd gezien.
Het systeem gaf isValid: true terug, terwijl geen tokens naar de verkoper hoefden te bewegen.
Een kwaadwillende klant kon daardoor in theorie een betaalde dienst krijgen zonder de bedoelde prijs te voldoen.
De test werd lokaal uitgevoerd.
V12 zegt geen live Solana-transactie voor de demonstratie te hebben verstuurd.
Dat onderscheid is belangrijk: de onderzoekers bewezen de fout in de verificatielogica, niet dat zij zelf publiek geld via Solana hebben buitgemaakt.
Een geldige instructie is niet automatisch de juiste instructie
De fout laat zien waarom alleen controleren op bedrag en adressen onvoldoende kan zijn.
Software moet ook vaststellen welke handeling werkelijk wordt uitgevoerd.
Een toestemming van tien tokens en een overdracht van tien tokens kunnen vergelijkbare gegevens bevatten.
Hun effect op de blockchain is totaal anders.
Voor een betaalprotocol moet de verifier daarom niet alleen vragen: klopt het bedrag?
Hij moet ook vaststellen: is dit werkelijk een betaling?
Derde fout raakte inloggen met een wallet
De derde kritieke bevinding ging niet rechtstreeks over geld overmaken.
x402 ondersteunt ook een uitbreiding waarmee gebruikers zich met een wallet kunnen authenticeren.
Daarbij ondertekent de client een bericht voor een bepaalde website.
De onderzochte automatische wrapper controleerde onvoldoende of het domein en de URI in dat bericht overeenkwamen met de website die de client daadwerkelijk had benaderd.
Een kwaadaardige server kon daardoor een handtekening vragen die bedoeld leek voor een andere website.
Echte handtekening kon bij verkeerde website bruikbaar zijn
Stel dat een agent data.example benadert.
Die server kan volgens het aanvalsscenario een inlogbericht terugsturen waarin app.example staat.
Wanneer de client dat zonder extra controle ondertekent, krijgt de aanvaller een echte handtekening van de wallet voor app.example.
Onder bepaalde voorwaarden kan die handtekening daarna bij de andere dienst worden gebruikt om een sessie te openen.
De cryptografische handtekening zelf is dan niet vervalst.
Juist dat maakt de fout gevaarlijk.
De gebruiker heeft werkelijk getekend, maar voor een domein waarvoor hij dat niet bedoelde.
Technisch geldig betekent opnieuw niet bevoegd
Alle drie de kwetsbaarheden raken uiteindelijk dezelfde foutlijn.
Een geldige handtekening betekent niet dat een bedrag redelijk is.
Een geldige Solana-instructie betekent niet dat er betaald is.
En een cryptografisch correcte loginhandtekening betekent niet dat de gebruiker bewust bij dat domein wilde inloggen.
Automatisering haalt menselijke tussenstappen uit het proces.
Daarom moeten de grenzen die een mens normaal controleert vooraf in software worden vastgelegd.
Reparaties waren in augustus al beschikbaar
V12 meldde de drie kritieke kwetsbaarheden samen met dertien bevindingen met hoge ernst op 12 augustus aan het x402-team.
Volgens het beveiligingsbedrijf waren de drie kritieke fouten uiterlijk 20 augustus gerepareerd.
De huidige openbaarmaking van 22 oktober maakt die problemen dus publiek nadat de fixes al beschikbaar waren.
Dat verkleint het risico dat een technisch rapport direct een nog ongerepareerde aanvalsmethode blootlegt.
V12 zegt niet dat deze drie fouten momenteel nog in bijgewerkte versies aanwezig zijn.
x402 gebruikt nu expliciete bestedingsregels
De huidige x402-documentatie laat zien hoe de betaalcontrole verder is aangescherpt.
Clients kennen standaardassets en kunnen vooraf toegestane bedragen bepalen.
Voor ondersteunde, aan de dollar gekoppelde stablecoins geldt standaard de limiet van $1 per betaling.
Andere assets moeten explicieter worden toegestaan.
Dat is een veel veiliger uitgangspunt dan een serverbedrag rechtstreeks naar een automatische signer doorsturen.
Maar ook deze regels blijven deels configureerbaar.
De ontwikkelaar van de agent bepaalt uiteindelijk welke grenzen werkelijk worden gebruikt.
Updaten alleen lost verkeerde instellingen niet op
Daarom moet de controle verder gaan dan alleen het versienummer van een SDK.
Een ontwikkelaar kan de nieuwste code draaien en toch ruime betaalrechten instellen.
Hij kan de limieten uitschakelen.
Ook kan een per-betalingsmaximum te hoog zijn voor de taak die de agent uitvoert.
Voor een agent die alleen weergegevens van enkele centen koopt, is een toegestane betaling van honderden dollars moeilijk te verdedigen.
Rechten horen dus bij de taak te passen.
Ontvanger en domein verdienen dezelfde aandacht als bedrag
Een degelijk betaalbeleid moet meerdere vragen beantwoorden voordat een handtekening wordt gezet.
Hoeveel mag deze agent maximaal betalen?
Welke tokens mag hij gebruiken?
Op welke netwerken?
Naar welke ontvangers?
Voor welke website mag hij een loginbericht ondertekenen?
En hoeveel mag hij over een langere periode uitgeven?
Geen van die controles kan volledig door een andere worden vervangen.
Een betaling van $0,50 naar de verkeerde ontvanger blijft een verkeerde betaling.
Een correcte login voor het verkeerde domein blijft eveneens fout.
Geen openbaar bewijs dat de drie fouten zijn misbruikt
De V12-publicatie beschrijft technische aanvalspaden en tests.
Daaruit volgt niet dat criminelen deze drie kwetsbaarheden daadwerkelijk hebben gebruikt tegen echte x402-gebruikers.
V12 meldt geen bevestigde buit of getroffen slachtoffers.
Ook de openbare informatie over de reparaties levert geen bewijs van een eerdere aanval op.
Dat onderscheid moet overeind blijven.
Een kritieke kwetsbaarheid beschrijft wat technisch mogelijk was onder bepaalde voorwaarden.
Het is geen bewijs dat die mogelijkheid ook werkelijk is uitgebuit.
Automatisch betalen verschuift de veiligheidsgrens
x402 probeert een probleem op te lossen dat met AI-agents alleen maar groter wordt: software moet zelfstandig kleine bedragen kunnen betalen zonder bij iedere stap menselijke toestemming te vragen.
Juist daardoor verschuift de veiligheidscontrole naar het moment vóór de ondertekening.
De drie gerepareerde fouten maken die grens zichtbaar.
Een agent die zelfstandig geld mag bewegen, heeft niet alleen een private key nodig.
Hij heeft harde regels nodig over bedrag, token, ontvanger, domein en totaalbudget.
Zonder die grenzen kan automatisering één klik besparen en tegelijk veel meer macht weggeven dan de gebruiker ooit bedoelde.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
