31 failles de sécurité découvertes chez 15 facilitateurs de paiement x402 : aucun système n’a résisté — y compris Coinbase

• Shopping gratuit – Le marchand fournit un service après une vérification hors chaîne réussie, mais le règlement sur la chaîne échoue ensuite (ou une signature invalide/de montant nul est acceptée). L'acheteur obtient le produit sans payer. Les chercheurs ont directement validé deux chemins de shopping gratuit et en ont classé dix autres comme à haut risque.
• Vol d'actifs – Un attaquant prend le contrôle des actifs détenus par le facilitateur, par exemple en trompant le facilitateur pour qu'il approuve des transferts de tokens arbitraires.
• Déni de service – La relecture de paiement, la réutilisation de signature ou des charges utiles malveillantes entraînent le plantage du facilitateur ou le refus de transactions légitimes.
• Abus de gaz – Les attaquants forcent le facilitateur à payer pour des déploiements coûteux de contrats intelligents ou des opérations répétées sur la chaîne, transformant le règlement en un puits de coûts illimité pour le sponsor .

La faille la plus grave : le chemin ERC-6492

Le chemin d'attaque le plus grave impliquait ERC-6492, un standard de signature Ethereum pour les portefeuilles de contrats intelligents qui peuvent ne pas encore être déployés. Les chercheurs ont découvert que des métadonnées malveillantes pouvaient amener un facilitateur à financer et à soumettre une transaction d'approbation de token arbitraire au lieu du paiement attendu . Les chercheurs n'ont pas eux-mêmes déplacé les fonds du facilitateur, mais ont classé la faille comme un chemin direct vers le vol d'actifs, car un attaquant pourrait utiliser cette autorité pour approuver des transferts d'actifs contrôlés par le facilitateur.

Risque côté marchand : les kits de serveur de référence Coinbase

Les sept kits de serveur de référence officiels de Coinbase examinés par les chercheurs manquaient de mécanismes explicites pour annuler les actions entreprises après une vérification réussie . Dans les versions du kit Flask de Coinbase jusqu'à la version 0.2.1, les ressources protégées pouvaient être libérées après vérification, que le règlement ultérieur ait réussi ou non. Cela signifie qu'un marchand utilisant ces kits pourrait remettre un service irréversible — par exemple, une réponse API ou un bien numérique — alors que le paiement ne se finalise jamais sur la chaîne.

Concentration du marché et frais réseau

L'étude a analysé plus de 119 millions de transactions x402 sur Base et Solana entre le 1er octobre et le 26 décembre 2025 . Les facilitateurs ont collectivement dépensé environ 202 000 $ en frais réseau, dont environ 5 800 $ pour des transactions sur Base qui ont finalement été annulées ou ont échoué — démontrant l'asymétrie économique où un facilitateur supporte les coûts de la blockchain même lorsqu'un paiement n'aboutit jamais . La mesure sur la chaîne a en outre quantifié une centralisation significative des facilitateurs, le facilitateur Base de Coinbase dominant l'écosystème en volume de transactions pendant la période d'étude.

État des correctifs (en février 2026)

Les chercheurs ont divulgué de manière responsable toutes les découvertes aux parties concernées . Coinbase, PayAI et Mogami ont reconnu les problèmes et adopté des mesures d'atténuation, notamment en corrigeant 6 vulnérabilités en février 2026 . L'article note que Coinbase a apporté des modifications spécifiques en réponse à la divulgation. L'état des correctifs des autres facilitateurs n'a pas été précisé dans les sources disponibles.

Recommandations des chercheurs

• Pour les facilitateurs : Appliquer les huit règles de sécurité couvrant l'exactitude de l'autorisation et la sécurité d'exécution ; ne jamais accepter un échec de règlement comme raison de fournir un service ; mettre en œuvre la déduplication des signatures (suivi des nonces) ; rejeter les paiements de montant nul ; générer des reçus signés cryptographiquement liant txHash de paiement → point de terminaison de service → hachage de réponse pour la résolution des litiges .
• Pour les marchands : Ne jamais libérer de services irréversibles immédiatement après la seule vérification hors chaîne ; exiger une confirmation de règlement sur la chaîne avant la livraison ; auditer tout kit de serveur de référence pour s'assurer qu'un échec de règlement déclenche une réponse 402, et non une livraison de service .
• Pour l'écosystème : Adopter des invariants de sécurité standardisés, des tests automatisés en boîte noire (l'article présente X402SCOPE à cette fin) et des couches de responsabilité partagées pour réduire le rayon d'explosion d'une faille unique d'un facilitateur .