Polymarket subit une deuxième faille de sécurité à plusieurs millions de dollars en quatre mois

Polymarket a repris ses activités le 29 octobre après qu'un prestataire tiers compromis a perturbé la plateforme internationale de marchés de prédiction. C'est la deuxième faille de sécurité à plusieurs millions de dollars subie par Polymarket en quatre mois. Le registre officiel d'incidents de la plateforme situe le début des restrictions de négociation à 18 h 05 UTC et leur levée à 19 h 05 UTC. Polymarket affirme avoir corrigé le problème et prévenu les autorités. La société promet une indemnisation intégrale des utilisateurs touchés. Bubblemaps, cabinet d'analyse blockchain, estime que la faille du 29 octobre a touché plus de 700 utilisateurs de Polymarket et compromis environ 3,46 millions de dollars d'actifs. Les attaquants ont converti près de 2,7 millions de dollars en POL avant de sortir les fonds. Quelque 750 000 dollars restaient sur Polymarket au moment de l'évaluation. Le 25 juin, Polymarket avait révélé qu'un fournisseur compromis avait permis l'injection d'un script malveillant. La dépendance concernée a été supprimée et un remboursement intégral promis. Source Defense a chiffré les pertes de l'attaque de juin à environ 3 millions de dollars. Le vecteur : un tag marketing chargeant une bibliothèque d'identité externe, que l'attaquant a remplacée par un drainer conçu pour Polymarket. Selon les chercheurs, la charge de juin ciblait les portefeuilles de plus de 100 000 dollars et sollicitait à répétition une autorisation numérique. Une autorisation validée transitait par le relayer de Polymarket, qui soumet les actions signées. L'analyse d'octobre de Hudson Rock décrit un code récupéré depuis une URL associée à DebugBear, à la recherche du client de négociation actif et du signataire au sein d'une session ouverte. Le signataire est le composant qui demande l'autorisation cryptographique. Hudson Rock note que le comportement programmé du script variait selon le type de compte : une branche demandait le transfert de jetons de position, une autre une vente suivie du transfert du produit. La société a également identifié des métadonnées de build de production attestant la suppression du script de surveillance DebugBear. L'analyse statique de Hudson Rock ne prouve pas que le code a été exécuté, qu'il a obtenu des signatures à l'insu des utilisateurs ou qu'il a dérobé des clés privées. Elle n'établit pas non plus de chaîne complète entre victimes et bénéficiaires, et les métadonnées de suppression ne datent pas précisément la fin de l'exposition. La dépendance marketing de juin et le script lié à la surveillance d'octobre offrent deux voies d'accès distinctes à une interface financière sensible. Le mécanisme de juin reposait, selon les rapports, sur des autorisations validées ; le code d'octobre cherchait des outils de négociation et demandait des signatures. Remplacer un fournisseur compromis ne suffit pas à traiter le problème de fond : la présence de code malveillant dans les fonctions financières du site. La répétition des incidents interroge sur les pouvoirs financiers que du code externe peut exercer via le navigateur d'un trader. La documentation navigateur de MDN rappelle qu'un script tiers chargé directement dans une page accède aux autres scripts et aux données de cette page ; l'héberger ailleurs n'y change rien, tandis qu'un contenu cross-origin placé dans une frame séparée relève d'une frontière de sécurité différente. Réduire le code externe, limiter les demandes de signature et contrôler les fichiers téléchargés couvrent des étapes différentes de la chaîne d'attaque. Supprimer les intégrations inutiles des pages de négociation et de signature diminue le code externe admis dans ces environnements. Auditer l'accès du signataire et identifier les actions exigeant une confirmation fraîche de l'utilisateur restreint les demandes que le code peut formuler après avoir obtenu l'accès. L'intégrité des sous-ressources (SRI) permet au navigateur de comparer les scripts téléchargés à une empreinte cryptographique attendue et de rejeter les fichiers modifiés ; elle protège aussi une ressource correctement épinglée hébergée sur un domaine de confiance. Un post-mortem détaillé — période d'exposition, comptes touchés, circuits d'autorisation — aiderait à évaluer le risque résiduel. La question de savoir si une nouvelle intégration compromise pourrait transformer un accès à l'interface de négociation en autorisation financière exploitable reste ouverte.