Kritische Schwachstellen im x402-SDK ermöglichen es bösartigen APIs, die Wallets von KI-Agenten zu leeren

KI-Agenten, die den x402-Standard für automatisierte Mikrozahlungen nutzen, waren dem schweren Risiko ausgesetzt, dass ihr gesamtes Token-Guthaben durch bösartige APIs entwendet wird. Das Sicherheitsunternehmen V12 gab am 22. Oktober bekannt, dass die Standard-Clients in den Software Development Kits (SDKs) von x402 keine Ausgabelimits besaßen. Dies erlaubte es feindlichen Servern, das gesamte Guthaben der Wallet anzufordern und zu erhalten.

Die x402 Foundation, die diese Open-Source-Tools pflegt, veröffentlichte bereits am 18. August Patches für diese kritischen Schwachstellen. Diese Updates wurden jedoch in öffentlichen Warnhinweisen nicht als Sicherheitspatches gekennzeichnet. Dadurch blieben viele Entwickler trotz des potenziellen Risikos erheblicher finanzieller Verluste in agentischen Workflows ahnungslos.

Was passiert ist

V12 identifizierte 25 Schwachstellen in der x402-Codebasis, von denen drei als kritisch eingestuft wurden. Die gefährlichste Sicherheitslücke befand sich in der Logik des Standard-Clients über die TypeScript-, Python- und Go-SDKs hinweg. Wenn ein API-Server mit einem HTTP-Statuscode 402 Payment Required antwortete, konnte er Zahlungsoptionen mit beliebigen Beträgen auflisten. Der Standard-Client wählte automatisch die erste Option aus und unterzeichnete eine Zahlung für diesen Betrag, ohne zu prüfen, ob dieser ein angemessenes Limit überschritt.

Ein Angreifer konnte dies ausnutzen, indem er zunächst eine kleine, legitime Anfrage stellte, um die Wallet-Adresse des Agenten zu ermitteln. Anschließend konnte er das Guthaben der Wallet auf der Blockchain überprüfen und eine nachfolgende 402-Antwort erstellen, die genau diesen Betrag anforderte. Wenn die Anwendung des Agenten keine spezifischen Zahlungsrichtlinien festgelegt hatte, unterzeichnete das SDK die Transaktion, sodass der Angreifer sie einreichen und die Gelder entwenden konnte. Dieses Risiko war auf Agenten beschränkt, die so konfiguriert waren, dass sie Zahlungen ohne menschliches Eingreifen automatisch signieren.

Die anderen beiden kritischen Schwachstellen betrafen bestimmte Teile des Ökosystems. Eine Sicherheitslücke im TypeScript-Facilitator für Solana ermöglichte einen „vollständigen Zahlungs-Bypass“. Der Facilitator, der Zahlungen validiert, bevor sie die Blockchain erreichen, unterschied nicht zwischen einem Token-Transfer und einer Token-Genehmigung (Approval). Ein Angreifer konnte eine Anweisung zur Token-Genehmigung senden, die keine Gelder bewegt, aber Spendiergenehmigungen erteilt; der Facilitator akzeptierte dies als gültige Zahlung. Der Händler lieferte die Ressource aus, aber es wechselten keine Tokens den Besitzer, während der Facilitator die Transaktionsgebühr zahlte.

Der dritte Fehler betraf die Sign-In-With-X-Erweiterung (SIWx). Clients signierten Login-Nachrichten für Ethereum-basierte Websites, ohne zu verifizieren, dass die in der Nachricht genannte Website mit der aktuell kontaktierten Seite übereinstimmte. Ein bösartiger Server konnte eine Login-Nachricht von einer anderen, vertrauenswürdigen Seite weiterleiten und den Agenten dazu bringen, diese zu signieren. Der Angreifer konnte dann diese Signatur verwenden, um sich als der Agent bei der vertrauenswürdigen Seite anzumelden und unbefugten Zugriff zu erlangen.

Wie es funktioniert

Der x402-Standard ermöglicht maschinelle Zahlungen (Machine-to-Machine), indem Zahlungsanweisungen direkt in HTTP-Anfragen eingebettet werden. Wenn ein Server eine Zahlung verlangt, gibt er den Statuscode 402 zusammen mit einer Liste von Zahlungsoptionen zurück, wobei jede Option einen Betrag, einen Token-Typ und einen Empfänger angibt. Der Client wählt eine Option aus, signiert einen kryptografischen Zahlungsnachweis und wiederholt die Anfrage. Dieser Prozess ist darauf ausgelegt, für KI-Agenten nahtlos zu funktionieren, die autonom API-Aufrufe bezahlen müssen.

Die Schwachstelle entstand, weil die Implementierung des Standard-Clients Bequemlichkeit vor Sicherheit stellte. Er wählte automatisch die erste vom Server präsentierte Zahlungsoption aus und legte vor dem Update am 18. August kein maximales Ausgabelimit fest. Dieses Vertrauensmodell ging davon aus, dass API-Anbieter immer faire Beträge anfordern würden – eine Annahme, die bei der Interaktion mit böswilligen Akteuren fehlschlägt. Der Fix führt ein Standard-Limit von 1 USD pro Transaktion ein und beschränkt Zahlungen auf anerkannte Stablecoins wie USDC, es sei denn, der Entwickler konfiguriert explizit andere Regeln.

Beim Problem mit dem Solana-Facilitator lag die Ursache in einer fehlenden strengen Validierung der Anweisungen. Token-Transfers und Token-Genehmigungen sind auf der Solana-Blockchain ähnliche Datenstrukturen, die sich nur durch das initiale Instruktions-Byte unterscheiden. Der TypeScript-Facilitator prüfte zwar, ob die Transaktion ein gültiges Token-Programm aufruft, verifizierte aber nicht den spezifischen Instruktions-Typ. Durch die Hinzufügung einer Prüfung für den Instruktions-Typ stellt das aktualisierte SDK sicher, dass nur tatsächliche Transfers als Zahlung akzeptiert werden, was verhindert, dass Angreifer leere Genehmigungen nutzen, um das System zu täuschen.

Wichtige Details

• V12 entdeckte 25 Schwachstellen im x402-Code, von denen drei als kritisch eingestuft und in ihrem Bericht detailliert beschrieben wurden.
• Die Standard-x402-Clients für TypeScript, Python und Go hatten vor den Veröffentlichungen am 18. August keine Ausgabelimits.
• Eine Solana-spezifische Schwachstelle im TypeScript-Facilitator erlaubte es, Token-Genehmigungen als gültige Zahlungen zu akzeptieren, wodurch tatsächliche Geldtransfers umgangen wurden.
• Die SIWx-Erweiterung ermöglichte es Agenten, Login-Nachrichten für Websites zu signieren, die sie gerade nicht besuchten, was Kontenübernahmen begünstigte.
• Fixes wurden am 18. August veröffentlicht, aber es wurde kein öffentlicher Sicherheitshinweis herausgegeben, und Paketregistrierungen wie npm und PyPI markierten ältere Versionen nicht als verwundbar.
• Stand 23. Oktober sind die neuesten sicheren Versionen 2.28.0 für TypeScript/Go-Pakete und 2.25.0 für Python.

Warum das wichtig ist

Für Entwickler, die KI-Agenten bauen, die mit kostenpflichtigen APIs interagieren, verdeutlicht dieser Vorfall die Risiken der Automatisierung finanzieller Transaktionen ohne strenge Schutzmaßnahmen. Agentische Workflows arbeiten oft mit hoher Autonomie, was bedeutet, dass ein einzelner ungeprüfter API-Aufruf sofort zu finanziellem Verlust führen kann. Das Fehlen expliziter Sicherheitshinweise bedeutet, dass Teams, die sich auf Standard-Schwachstellenscanner wie npm audit verlassen, möglicherweise weiterhin unwissentlich dem Risiko ausgesetzt sind, selbst nachdem Patches verfügbar sind.

Dies unterstreicht auch die Bedeutung der Validierung externer Eingaben in dezentralen Zahlungssystemen. Wenn Geld programmatisch fließt, muss der Code jede Zahlungsanfrage als potenziell feindlich betrachten. Die x402-Schwachstellen zeigen, wie subtile Unterschiede in Blockchain-Anweisungen oder fehlende Domänenprüfungen in Login-Prozessen zu einer vollständigen Kompromittierung des Systems führen können. Teams müssen nun ihre Agent-Konfigurationen auditierten, um sicherzustellen, dass sie keine veralteten SDKs verwenden oder wesentliche Ausgabenkontrollen deaktivieren.

Was Sie tun können

• Aktualisieren Sie alle x402-Pakete auf die neuesten Versionen: 2.28.0 für TypeScript und Go sowie 2.25.0 für Python.
• Stellen Sie sicher, dass Ihre Anwendung spendControls: false nicht setzt, da dies das neue Standard-Limit von 1 USD und die Stablecoin-Einschränkungen deaktivieren würde.
• Wenn Sie nicht sofort aktualisieren können, registrieren Sie eine Zahlungsrichtlinie mit registerPolicy (TypeScript/Go) oder register_policy (Python), um einen maximalen Betrag pro Transaktion durchzusetzen.
• Stellen Sie für Solana-Facilitatoren sicher, dass Sie @x402/svm in Version 2.23.0 oder höher verwenden, um Zahlungs-Bypässe über Token-Genehmigungen zu verhindern.
• Aktualisieren Sie @x402/extensions auf Version 2.23.0 oder höher, um die Domänenübereinstimmung für SIWx-Login-Signaturen zu erzwingen.
• Auditierten Sie die Wallet-Berechtigungen Ihres Agenten und erwägen Sie die Verwendung dedizierter Wallets mit begrenztem Guthaben für automatisierte API-Interaktionen.