Le client par défaut du SDK x402 signait des paiements sans plafond et vidait le solde des agents IA
Le 22 octobre 2026, V12 révèle que le client par défaut des SDK de paiement x402 signait des paiements sans plafond, permettant à une API malveillante de vider le solde d’un agent IA en une seule demande. Les correctifs du 18 août existent, mais ils ne sont pas signalés comme sécurité dans npm ni PyPI : mettez à niveau et fixez vos plafonds côté application.
22 octobre 2026. Le cabinet V12 publie une analyse de 25 failles dans les SDK du protocole de paiement x402, dont trois critiques décrites en détail. 18 août 2026. Les correctifs pour ces trois failles sont déjà intégrés dans les versions publiées par la x402 Foundation. 23 octobre 2026. Ni npm ni PyPI ne signalent pourtant de mise à jour de sécurité, et aucune exploitation n’est documentée. Pourquoi c’est important : un agent IA qui signe automatiquement ses paiements pouvait signer la totalité de son solde d’un jeton supporté, sans que son développeur reçoive le moindre avertissement.
x402 fait payer un appel d’API dans la requête elle-même
x402 est un standard ouvert qui permet à un logiciel — au premier rang desquels les agents IA — de payer un appel d’API dans la requête web elle-même, sans qu’un humain valide chaque paiement. Le nom vient du code de statut HTTP 402 Payment Required. Un serveur qui exige un paiement répond avec ce code et liste ses options : un montant, un jeton et un destinataire. Le client en choisit une, signe un paiement et renvoie la requête.
Le standard est né chez Coinbase, qui l’a cédé cette année à la x402 Foundation, un projet de la Linux Foundation dont les membres incluent Visa et Mastercard. Coinbase occupe le siège le plus élevé du comité technique de pilotage de la fondation. C’est dire que le code ne tourne pas dans un coin : il sous-tend des paiements d’agents que des institutions financières regardent de près.
Trois failles critiques, une même signature : le défaut par défaut
La première faille critique tient au client par défaut. Avant les versions du 18 août, ce client ne fixait aucune limite de dépense. Il prenait la première option de la liste proposée par le serveur. Une API hostile pouvait donc transformer une banale demande de données en demande de la totalité du solde du portefeuille dans un jeton supporté — un petit paiement préalable suffisant à révéler l’adresse du portefeuille pour en consulter le solde. Avec un signataire automatique et aucune politique de paiement définie par l’application, le client signait le montant demandé. Pour un jeton qui supporte les transferts signés, l’attaquant n’avait plus qu’à soumettre le paiement signé et encaisser.
La deuxième faille touchait le facilitateur Solana, le service qui vérifie chaque paiement et le soumet à la blockchain. Le code TypeScript lisait un paiement appelant un programme de jetons autorisé comme un transfert sans vérifier le type d’instruction. Or une approbation de jeton — qui autorise un autre compte à dépenser plus tard sans déplacer quoi que ce soit — ne diffère d’un transfert que par son premier octet. Dans le test local de V12, le facilitateur acceptait une telle approbation comme paiement valide, un « contournement de paiement complet » : le marchand livrait une ressource payante sans recevoir le moindre jeton, et c’est le facilitateur qui réglait les frais de transaction à chaque essai. Les SDK Python et Go vérifiaient déjà le type d’instruction ; les versions du 18 août ont ajouté la même vérification au code TypeScript.
La troisième faute concernait Sign-In-With-X (SIWx), l’extension de connexion qui permet à un agent de prouver un paiement antérieur en signant un court message avec son portefeuille. Sur Ethereum, le message nomme le site, l’adresse du portefeuille et un code à usage unique. Le client automatisé signait ces messages sans vérifier que le site nommé était celui qu’il avait contacté. Un serveur malveillant pouvait donc obtenir un message de connexion frais d’un autre site, le passer à l’agent, et réutiliser la signature pour se connecter à ce site en tant que portefeuille de l’agent.
Les correctifs existent, mais le silence de la chaîne d’outils est le vrai problème
Les trois failles critiques sont déjà corrigées dans les versions du 18 août : les clients TypeScript, Python et Go plafonnent désormais chaque paiement à 1 $ et n’acceptent que les stablecoins en dollars reconnus, comme l’USDC ; le facilitateur TypeScript vérifie le type d’instruction ; le client SIWx vérifie le site nommé. V12 n’a trouvé les failles qu’en relisant le code et en lançant des tests locaux, et ni V12 ni la x402 Foundation n’ont signalé d’attaque réelle.
Le problème n’est pas là. La fondation n’a publié aucun avis de sécurité pour ces trois failles, et ses journaux de modifications listent les corrections sans les qualifier de correctifs de sécurité. Au 23 octobre, npm audit ne remontait aucun avis pour les dernières versions TypeScript antérieures aux correctifs, et PyPI ne listait aucune vulnérabilité pour la dernière version Python antérieure. Un développeur qui s’appuie sur ces contrôles ne reçoit donc aucun signal l’incitant à mettre à niveau.
C’est le cœur du sujet pour un SRE qui déploie des agents autonomes : quand la sécurité dépend d’un SDK de paiement, la confiance dans npm audit ou les avis PyPI ne suffit plus. Il faut lire les journaux de modifications, et surtout définir soi-même une politique de dépense plutôt que d’hériter du défaut du client.
Verdict
Si vous construisez des agents qui paient via x402, mettez à niveau sans attendre. Côté TypeScript, toute version de @x402/svm de 2.0.0 à 2.22.0 omet la vérification du type d’instruction : passez à 2.23.0 ou plus récent. Côté clients, les versions du 18 août ajoutent les plafonds de dépense — mais ne vous en remettez pas au seul défaut. Fixez explicitement un plafond de dépense et une liste de jetons autorisés dans votre application, car un client « sans limite » reste la valeur par défaut historique et la première chose qu’une API hostile tentera d’exploiter.
Si vous êtes un marchand qui s’appuie sur le facilitateur Solana, vérifiez que vous n’acceptez plus les approbations de jetons comme paiement, faute de quoi vous livrerez des ressources payantes sans encaisser. Et pour toute la chaîne : ne traitez pas l’absence d’alerte npm audit ou PyPI comme une preuve d’innocuité — les trois failles critiques sont corrigées, mais aucune n’a jamais été signalée comme sécurité. La leçon dépasse x402 : à mesure que les agents gagnent la capacité de dépenser, la surface de risque migre du « qui peut exécuter du code » vers le « qui peut signer un paiement », et les garde-fous doivent être posés par le développeur, pas hérités du SDK.