Kritische Lücken in x402-SDKs: KI-Agenten konnten Token-Guthaben komplett freigeben

Das fehlende Limit ist eine von 25 Schwachstellen, die V12 im x402-Code fand – und eine von drei, die das Unternehmen als kritisch einstufte und ausführlich beschrieb. Die x402 Foundation, die die SDKs pflegt, hatte alle drei kritischen Lücken bereits mit den Releases vom 18. August behoben. V12 fand die Fehler durch Code-Prüfung und lokale Tests; weder V12 noch die x402 Foundation haben öffentlich Angriffe darüber gemeldet.

x402 ist ein offener Standard, mit dem Software – einschließlich KI-Agenten – einen API-Aufruf innerhalb der Web-Anfrage selbst bezahlen kann, ohne dass ein Mensch jede Zahlung freigibt. Ein Server, der Bezahlung verlangt, antwortet mit dem HTTP-Statuscode 402 Payment Required und listet seine Zahlungsoptionen mit Betrag, Token und Empfänger auf. Der Client wählt eine aus, signiert eine Zahlung und wiederholt die Anfrage. Der Standard-Client nahm stets die erste Option der Liste – und begrenzte den Betrag vor dem Fix nicht.

Eine feindselige API konnte so aus einer gewöhnlichen Datenabfrage eine Forderung über das gesamte Guthaben der Wallet an einem unterstützten Token machen, so V12. Eine vorherige Kleinstzahlung konnte die Wallet-Adresse offenlegen, sodass der Server den Kontostand zuvor nachschlagen konnte. Mit automatischem Signierer und ohne von der Anwendung gesetzte Zahlungsrichtlinie konnte der Client die Zahlung über diesen Betrag signieren. Bei Token, die signierte Transfers unterstützen, konnte der Angreifer die signierte Zahlung anschließend einreichen und die Mittel einziehen.

Die Releases vom 18. August ergänzten Ausgabenkontrollen in den Clients für TypeScript, Python und Go. Standardmäßig begrenzen sie jede Zahlung nun auf 1 US-Dollar und lassen nur US-Dollar-Stablecoins zu, die das SDK kennt, etwa USDC.

Die zweite kritische Lücke betraf die Prüfung von Solana-Zahlungen. In x402 verlässt sich der Server eines Händlers auf einen Facilitator, der jede Zahlung prüft und an die Blockchain übermittelt; auf Solana trägt der Facilitator zudem die Transaktionsgebühr. Der TypeScript-Facilitator-Code für Solana prüfte lediglich, ob eine Zahlung ein erlaubtes Token-Programm aufrief, und las sie dann als Transfer – ohne den Instruktionstyp zu prüfen. Eine Token-Freigabe (Approval), die einem anderen Konto erlaubt, später Token auszugeben, selbst aber keine bewegt, unterscheidet sich von einem Transfer nur im ersten Byte.

Im lokalen Test von V12 akzeptierte der Facilitator eine solche Freigabe als gültige Zahlung; eine echte Transaktion wurde dabei nicht gesendet. Ein Händler, der sich auf den Facilitator verlässt, hätte damit eine bezahlte Ressource ausliefern können, ohne Token zu erhalten – V12 spricht von „einer vollständigen Umgehung der Bezahlung". Der Angreifer brauchte nur ein Token-Konto, aber kein Guthaben, und der Facilitator zahlte jedes Mal die Transaktionsgebühr. Die SDKs für Python und Go prüften den Instruktionstyp bereits; die Releases vom 18. August ergänzten dieselbe Prüfung im TypeScript-Code. Unter den x402-SDKs war nur das TypeScript-SDK betroffen. Allen veröffentlichten @x402/svm-Versionen von 2.0.0 bis 2.22.0 fehlt die Prüfung, ab 2.23.0 ist sie enthalten.

Die dritte kritische Schwachstelle betrifft die Anmeldeerweiterung Sign-In-With-X (SIWx). Sie erlaubt einem Agenten, sich durch Signieren einer kurzen Nachricht mit seiner Wallet anzumelden, etwa um eine frühere Zahlung nachzuweisen, statt erneut zu zahlen. Auf Ethereum nennt die Nachricht die Website, die Wallet-Adresse und einen Einmalcode. Der automatisierte Client signierte diese Nachrichten, ohne zu prüfen, ob die darin genannte Website jene war, die er kontaktiert hatte.

Ein bösartiger Server konnte eine frische Anmeldenachricht einer anderen Seite besorgen, sie an den Agenten weiterreichen und sich mit der Signatur dort als dessen Wallet anmelden, so V12. Das funktioniert überall dort, wo die andere Seite die weitergeleitete Nachricht akzeptiert; der Angreifer erhält den Zugang, den die Anmeldung gewährt. Die Releases vom 18. August lassen die Clients für TypeScript, Python und Go die Signatur verweigern, wenn die Seite in der Nachricht nicht mit der Seite übereinstimmt, die die 402-Antwort gesendet hat. Auch die SIWx-Spezifikation wurde geändert: Sie schreibt nun vor, dass ein Client bei Abweichung nicht signieren darf. TypeScript-Code, der createSIWxPayload direkt aufruft, muss jetzt die URL der 402-Antwort nach etwaigen Weiterleitungen übergeben; die Wrapper @x402/fetch und @x402/axios tun dies selbst.

Die Foundation hat zu den drei Lücken keinen Sicherheitshinweis veröffentlicht; die Changelogs führen die Korrekturen auf, ohne sie als Sicherheitsfixes zu kennzeichnen. Mit Stand 23. Oktober lieferte npm audit für die letzten TypeScript-Releases vor den Fixes keine Advisories, und PyPI wies für das letzte Python-Release davor keine Schwachstellen aus. Wer sich auf diese Prüfungen verlässt, erhält also keinen Hinweis auf die nötige Aktualisierung.

Ein Upgrade auf die neuesten Versionen bringt auch spätere Korrekturen mit, darunter eine für eine separate Zahlungsumgehung in @x402/core 2.27.0 im September. Mit Stand 23. Oktober sind die aktuellen Versionen:

• 2.28.0 für @x402/core, @x402/svm, @x402/extensions, @x402/fetch und @x402/axios
• v2.28.0 für das Go-Modul
• 2.25.0 für das Python-Paket

In TypeScript erhalten Clients den Ausgabenschutz, indem sie @x402/fetch oder @x402/axios auf 2.23.0 oder neuer aktualisieren, was das passende @x402/core nachzieht. Anwendungen mit SIWx benötigen zusätzlich @x402/extensions 2.23.0 oder neuer, das die Anmeldeprüfung enthält. Facilitatoren, die Solana-Zahlungen prüfen, brauchen @x402/svm 2.23.0 oder neuer. Nach dem Upgrade sind bestehende Clients auf 1 US-Dollar pro Zahlung und auf erkannte Stablecoins begrenzt, sofern die Anwendung keine eigenen Ausgabenkontrollen setzt. Mit spendControls: false werden all diese Kontrollen abgeschaltet.

Teams, die noch nicht aktualisieren können, können eine Zahlungsrichtlinie registrieren, die jede Option oberhalb eines festgelegten Betrags verwirft. Die älteren Clients unterstützen das mit registerPolicy in TypeScript und Go sowie register_policy in Python, das zudem eine fertige max_amount-Richtlinie mitbringt. V12 rät Clients, vor dem Signieren zu prüfen, ob eine SIWx-Anmeldenachricht die kontaktierte Seite nennt, Budgets je Zahlung und insgesamt zu setzen sowie Token, Netzwerke und Empfänger zu beschränken.

x402 stammt von Coinbase und wurde in diesem Jahr an die x402 Foundation übergeben, ein Projekt der Linux Foundation, zu dessen Mitgliedern Visa und Mastercard zählen. Coinbase hält den ranghöchsten Sitz im technischen Steuerungsgremium der Foundation.