Polymarket perd 2,7 millions de dollars après le détournement d'un script DebugBear via une compromission DNS

Le 29 octobre 2026, des pirates ont exploité une vulnérabilité de la chaîne d'approvisionnement sur la plateforme de marché prédictif Polymarket pour voler environ 2,7 millions de dollars dans les portefeuilles des utilisateurs. L'attaque a tiré parti d'un script tiers compromis provenant du fournisseur de surveillance des performances DebugBear, permettant l'exécution de code malveillant dans les navigateurs des traders connectés. Polymarket a depuis lancé des remboursements pour les utilisateurs affectés et suspendu les transactions afin de sécuriser son infrastructure.

Ce qui s'est passé

L'incident a commencé lorsque les attaquants ont compromis les enregistrements DNS de DebugBear via son bureau d'enregistrement de domaine. Cela leur a permis de rediriger les demandes concernant un fichier JavaScript spécifique utilisé par Polymarket vers un serveur sous leur contrôle. Au lieu de servir le script légitime de surveillance réelle des utilisateurs (RUM) qui mesure les vitesses de chargement des pages, les attaquants ont servi une version malveillante adaptée à l'implémentation spécifique de Polymarket. Les chercheurs de Hudson Rock ont identifié le fichier échangé, notant que bien que DebugBear serve des scripts uniques à chaque client, seule la copie de Polymarket a été remplacée dans ce cas.

Une fois le script malveillant chargé dans les navigateurs des utilisateurs, il a activement scanné les détails du compte et les clés API de trading stockées dans la session. Le code n'a pas exfiltré directement les clés privées ou les mots de passe. Il a plutôt manipulé la session authentifiée existante pour passer des ordres non autorisés. Pour les utilisateurs connectés via des portefeuilles crypto, le script a déplacé les positions directement vers des adresses contrôlées par les attaquants. Pour les comptes basés sur l'e-mail, il a vendu des positions à des prix de plus en plus défavorables avant de drainer les fonds résultants. L'analyse blockchain par Ohey a montré que 28,6 millions de tokens POL, valorisés à environ 2,64 millions de dollars, ont été transférés vers un portefeuille pirate entre 17h10 et 18h02 UTC.

Polymarket a détecté l'anomalie et publié une mise à jour de statut à 17h38 UTC. À 18h05 UTC, la plateforme était passée en mode annulation uniquement, avait suspendu toutes les actions des relais et supprimé le script malveillant. La société a vidé tous les caches, réinitialisé les sessions de connexion actives et transmis l'affaire aux forces de l'ordre. Au 30 octobre, Polymarket avait entièrement remboursé 689 des 726 portefeuilles affectés, les 37 restants étant en cours de traitement. La société distribue également un montant supplémentaire de 1,19 million de dollars à environ 5 500 portefeuilles ayant subi des pertes pendant la pause des transactions ou en raison de liquidations de positions, portant la restitution totale à 3,9 millions de dollars.

Comment cela fonctionne

L'attaque reposait sur l'abus de la relation de confiance entre le navigateur, le site web et le signataire du portefeuille de l'utilisateur. Le script malveillant opérait entièrement dans le contexte de l'onglet Polymarket ouvert de la victime. Il accédait aux clés API de trading stockées dans la mémoire du navigateur mais ne pouvait pas les utiliser seules pour exécuter des transactions, car Polymarket exige une signature cryptographique du portefeuille de l'utilisateur pour chaque ordre.

Pour contourner cela, le script interagissait avec les éléments de l'interface Polymarket responsables de la passation des ordres et l'objet signataire qui approuve les transactions. Il automatisait efficacement le processus de signature en déclenchant des requêtes que le fournisseur de portefeuille pourrait présenter à l'utilisateur. Cependant, la vitesse et l'automatisation suggèrent que certaines signatures ont pu être approuvées sans conscience explicite de l'utilisateur, ou que les règles de session du fournisseur de portefeuille permettaient les requêtes groupées. Le script a ensuite transmis ces requêtes signées au relais de Polymarket, qui les a soumises à la blockchain. Cette méthode a permis aux attaquants de déplacer des fonds sans jamais posséder la clé privée ou la phrase de récupération de l'utilisateur.

Détails clés

• Vecteur d'attaque : Des enregistrements DNS compromis chez le bureau d'enregistrement de domaine de DebugBear ont redirigé un script client spécifique vers un serveur malveillant.
• Impact financier : Environ 2,64 millions de dollars en tokens POL ont été volés à 33 portefeuilles en moins d'une heure ; les remboursements totaux s'élèvent à 3,9 millions de dollars.
• Portée de la cible : Les premières conclusions indiquent que l'attaque ne visait que le script DebugBear spécifique de Polymarket, et non l'ensemble de la base clients de DebugBear.
• Méthode technique : Le script réutilisait les clés API de session existantes et déclenchait des signatures de portefeuille pour des transactions non autorisées plutôt que de voler des identifiants.
• Temps de réponse : Polymarket a identifié le problème et suspendu les transactions environ 30 minutes après les premiers transferts non autorisés.
• Statut actuel : DebugBear a conseillé à ses clients de supprimer son code d'intégration, et son adresse CDN n'avait aucun enregistrement DNS au 1er novembre.

Pourquoi c'est important

Cet incident met en évidence le risque critique inhérent au chargement de JavaScript tiers sur des pages gérant des opérations financières sensibles. Même des fournisseurs réputés comme DebugBear peuvent devenir des points d'entrée si leur infrastructure, telle que les enregistrements DNS, est compromise. Pour les développeurs construisant des applications fintech ou crypto, se fier uniquement à la réputation d'un fournisseur est insuffisant. L'attaque démontre qu'une compromission de la chaîne d'approvisionnement peut contourner la sécurité périmétrique traditionnelle car le code malveillant s'exécute avec les mêmes privilèges que l'application elle-même.

De plus, le mécanisme d'abus montre que protéger les clés privées ne suffit pas. Si un attaquant peut manipuler la logique frontend pour déclencher des signatures valides depuis le portefeuille d'un utilisateur, il peut drainer les fonds sans jamais accéder au matériel de clé. Cela déplace l'accent de la sécurité de la simple protection des identifiants vers des vérifications rigoureuses d'intégrité pour tout le code côté client. Cela souligne la nécessité de pratiques de codage défensif limitant ce que les scripts tiers peuvent accéder et faire au sein d'une session authentifiée.

Ce que vous pouvez faire

• Implémentez des hachages d'intégrité des sous-ressources (SRI) pour tous les scripts tiers afin de garantir que le navigateur rejette les fichiers si leur contenu change de manière inattendue.
• Appliquez une politique de sécurité du contenu (CSP) stricte qui limite les domaines pouvant exécuter des scripts et restreint l'exécution de code en ligne.
• Supprimez les scripts tiers inutiles des pages où les utilisateurs effectuent des actions sensibles telles que le trading, la signature ou la saisie de détails de paiement.
• Surveillez les enregistrements DNS de vos fournisseurs tiers et envisagez d'utiliser des versions épinglées de scripts plutôt que des endpoints dynamiques.
• Éduquez les utilisateurs pour qu'ils rejettent toute demande de signature de portefeuille qu'ils n'ont pas explicitement initiée, surtout si elles apparaissent en succession rapide.
• Mettez en bac à sable le code tiers lorsque possible pour limiter son accès au DOM de la page principale et aux objets API sensibles.