Des failles critiques du SDK x402 permettent à des API malveillantes de vider les portefeuilles des agents IA

Les agents IA utilisant le standard x402 pour les micropaiements automatisés ont été exposés à un risque sévère de voir l'intégralité de leurs soldes de tokens drainés par des API malveillantes. La société de sécurité V12 a révélé le 22 octobre que les clients par défaut des kits de développement logiciel (SDK) x402 ne disposaient pas de limites de dépenses, ce qui permettait aux serveurs hostiles de demander et de recevoir la totalité des fonds du portefeuille.

La Fondation x402, qui maintient ces outils open source, a publié des correctifs pour ces failles critiques le 18 août, mais les mises à jour n'ont pas été signalées comme des correctifs de sécurité dans les avis publics. Cela a laissé de nombreux développeurs inconscients du danger, malgré le risque potentiel de pertes financières importantes dans les flux de travail agentiques.

Ce qui s'est passé

V12 a identifié 25 failles dans la base de code x402, dont trois ont été classées comme critiques. La vulnérabilité la plus dangereuse se trouvait dans la logique du client par défaut sur les SDK TypeScript, Python et Go. Lorsqu'un serveur API répondait avec un statut HTTP 402 Payment Required, il pouvait lister des options de paiement avec des montants arbitraires. Le client par défaut sélectionnait automatiquement la première option et signait un paiement pour ce montant sans vérifier s'il dépassait une limite raisonnable.

Un attaquant pouvait exploiter cette faille en effectuant d'abord une petite requête légitime pour découvrir l'adresse du portefeuille de l'agent. Il pouvait ensuite consulter le solde du portefeuille sur la blockchain et élaborer une réponse 402 ultérieure demandant exactement ce montant. Si l'application de l'agent n'avait pas défini de politiques de paiement spécifiques, le SDK signait la transaction, permettant à l'attaquant de la soumettre et de drainer les fonds. Ce risque était limité aux agents configurés pour signer les paiements automatiquement sans intervention humaine.

Les deux autres failles critiques affectaient des parties spécifiques de l'écosystème. Une vulnérabilité dans le facilitateur TypeScript pour Solana permettait un « contournement complet du paiement ». Le facilitateur, qui valide les paiements avant qu'ils n'atteignent la blockchain, ne faisait pas la distinction entre un transfert de token et une approbation de token. Un attaquant pouvait envoyer une instruction d'approbation de token, qui ne déplace aucun fond mais accorde une autorisation de dépense, et le facilitateur l'acceptait comme un paiement valide. Le marchand livrait la ressource, mais aucun token n'était échangé, tandis que le facilitateur payait les frais de transaction.

La troisième faille concernait l'extension Sign-In-With-X (SIWx). Les clients signaient des messages de connexion pour des sites basés sur Ethereum sans vérifier que le site nommé dans le message correspondait au site avec lequel ils étaient actuellement en contact. Un serveur malveillant pouvait relayer un message de connexion provenant d'un autre site fiable, trompant l'agent pour qu'il le signe. L'attaquant pouvait ensuite utiliser cette signature pour se connecter au site fiable en tant qu'agent, obtenant ainsi un accès non autorisé.

Comment cela fonctionne

Le standard x402 permet les paiements machine-à-machine en intégrant directement les instructions de paiement dans les requêtes HTTP. Lorsqu'un serveur exige un paiement, il renvoie un code d'état 402 accompagné d'une liste d'options de paiement, chacune spécifiant un montant, un type de token et un destinataire. Le client sélectionne une option, signe une preuve cryptographique de paiement et réessaie la requête. Ce processus est conçu pour être transparent pour les agents IA qui doivent payer pour les appels API de manière autonome.

La vulnérabilité découlait du fait que l'implémentation du client par défaut privilégiait la commodité par rapport à la sécurité. Elle choisissait automatiquement la première option de paiement présentée par le serveur et, avant la mise à jour du 18 août, n'imposait aucune limite maximale de dépense. Ce modèle de confiance supposait que les fournisseurs d'API demanderaient toujours des montants équitables, une hypothèse qui échoue face aux acteurs malveillants. Le correctif introduit un plafond par défaut de 1 $ par transaction et restreint les paiements aux stablecoins reconnus comme USDC, sauf si le développeur configure explicitement des règles différentes.

Pour le problème du facilitateur Solana, la cause résidait dans un manque de validation stricte des instructions. Les transferts de tokens et les approbations de tokens sont des structures de données similaires sur la blockchain Solana, ne différant que par leur octet d'instruction initial. Le facilitateur TypeScript vérifiait si la transaction appelait un programme de token valide, mais ne vérifiait pas le type d'instruction spécifique. En ajoutant une vérification du type d'instruction, le SDK mis à jour garantit que seuls les transferts réels sont acceptés comme paiement, empêchant les attaquants d'utiliser des approbations vides pour tromper le système.

Détails clés

• V12 a découvert 25 failles dans le code x402, dont trois classées comme critiques et détaillées dans leur rapport.
• Les clients x402 par défaut pour TypeScript, Python et Go n'avaient aucune limite de dépenses avant les versions publiées le 18 août.
• Une faille spécifique à Solana dans le facilitateur TypeScript permettait aux approbations de tokens d'être acceptées comme des paiements valides, contournant les transferts réels de fonds.
• L'extension SIWx permettait aux agents de signer des messages de connexion pour des sites qu'ils ne visitaient pas actuellement, facilitant la prise de contrôle de compte.
• Les correctifs ont été publiés le 18 août, mais aucun avis de sécurité public n'a été émis, et les registres de paquets comme npm et PyPI n'ont pas signalé les anciennes versions comme vulnérables.
• Au 23 octobre, les dernières versions sécurisées sont la 2.28.0 pour les paquets TypeScript/Go et la 2.25.0 pour Python.

Pourquoi c'est important

Pour les développeurs construisant des agents IA qui interagissent avec des API payantes, cet incident met en lumière les risques liés à l'automatisation des transactions financières sans garde-fous stricts. Les flux de travail agentiques fonctionnent souvent avec une grande autonomie, ce qui signifie qu'un seul appel API non contrôlé peut entraîner une perte financière immédiate. L'absence d'avis de sécurité explicites signifie que les équipes dépendant de scanners de vulnérabilités standards comme npm audit peuvent rester inconscientes du risque, laissant leurs systèmes de production exposés même après la disponibilité des correctifs.

Cela souligne également l'importance de valider les entrées externes dans les systèmes de paiement décentralisés. Lorsque l'argent circule de manière programmée, le code doit traiter chaque demande de paiement comme potentiellement hostile. Les failles x402 démontrent comment des différences subtiles dans les instructions blockchain ou des vérifications de domaine manquantes dans les flux de connexion peuvent conduire à une compromission complète du système. Les équipes doivent désormais auditer les configurations de leurs agents pour s'assurer qu'elles n'utilisent pas de SDK obsolètes ou ne désactivent pas les contrôles essentiels de dépenses.

Ce que vous pouvez faire

• Mettez à niveau tous les paquets x402 vers les dernières versions : 2.28.0 pour TypeScript et Go, et 2.25.0 pour Python.
• Vérifiez que votre application ne définit pas spendControls: false, ce qui désactiverait le nouveau plafond par défaut de 1 $ et les restrictions sur les stablecoins.
• Si vous ne pouvez pas mettre à niveau immédiatement, enregistrez une politique de paiement en utilisant registerPolicy (TypeScript/Go) ou register_policy (Python) pour imposer un montant maximum par transaction.
• Pour les facilitateurs Solana, assurez-vous d'utiliser la version @x402/svm 2.23.0 ou ultérieure pour prévenir le contournement de paiement via les approbations de tokens.
• Mettez à jour @x402/extensions vers la version 2.23.0 ou ultérieure pour appliquer la correspondance de domaine pour les signatures de connexion SIWx.
• Auditez les permissions du portefeuille de votre agent et envisagez d'utiliser des portefeuilles dédiés avec des soldes limités pour les interactions API automatisées.