Polymarket : un script DebugBear piraté vole 2,7 M$

Polymarket, la plateforme de paris prédictifs en cryptomonnaie, a confirmé le 29 octobre 2026 le vol de 2,7 millions de dollars auprès de 726 portefeuilles d'utilisateurs connectés à son site. L'attaque n'est pas passée par les serveurs de Polymarket, mais par un script tiers fourni par DebugBear, une société d'outils de mesure de performance web, dont les enregistrements DNS ont été détournés via son bureau d'enregistrement de noms de domaine. L'incident a duré moins d'une heure avant que Polymarket ne retire le script et ne suspende les transactions ; la quasi-totalité des fonds a depuis été remboursée.

Comment Polymarket a-t-il été piraté via DebugBear ?

DebugBear fournit un outil de mesure de performance de page (Real User Monitoring) que des sites tiers, dont Polymarket, chargent directement depuis ses serveurs. Selon The Hacker News, les attaquants ont compromis les enregistrements DNS de DebugBear par l'intermédiaire de son registraire, et non en pénétrant ses propres serveurs : à 18h13 UTC, un serveur différent répondait déjà pour les adresses de DebugBear, alors que le fichier malveillant restait encore en ligne. DebugBear indique que ses premières constatations désignent une attaque ciblée contre le site d'un seul client, plutôt qu'une compromission généralisée de ses systèmes, et précise que son enquête se poursuit.

Le script modifié s'exécutait directement dans la page Polymarket, dans le contexte d'un utilisateur déjà connecté. Selon l'analyse du fichier réalisée, sans l'exécuter, par les chercheurs de Hudson Rock, le code lisait les informations de compte stockées dans le navigateur, dont les clés d'API de trading, repérait le code de passation d'ordre de Polymarket ainsi que le composant chargé de faire signer les transactions, puis utilisait cette signature pour transférer les positions ou les solder à des prix dégradés avant d'en envoyer le produit vers un portefeuille contrôlé par l'attaquant. Les chercheurs n'ont trouvé aucun code transmettant mots de passe, phrases de récupération ou clés privées vers un serveur distant : l'attaque a exploité la session active de la victime, pas un vol d'identifiants classique.

À retenir : ce n'est pas Polymarket qui a été directement piraté, mais un prestataire tiers dont le script était chargé sans isolation particulière sur une page où des utilisateurs connectés pouvaient faire signer des transactions financières.

Chronologie et montants volés

Polymarket évalue la perte totale à 2,7 millions de dollars sur 726 portefeuilles concernés. Les registres de la blockchain Polygon montrent environ 2,64 millions de dollars en jetons POL reçus par le portefeuille de l'attaquant en moins d'une heure, un chiffre qui ne couvre pas les positions de paris volées séparément. Dès le 30 octobre, selon le statut officiel de Polymarket, 689 des 726 portefeuilles touchés avaient été intégralement remboursés, les 37 restants étant traités au fur et à mesure de leur vérification. La plateforme verse en outre environ 1,19 million de dollars à près de 5 500 portefeuilles ayant subi une perte pendant la pause de trading, portant le total des sommes rendues à 3,9 millions de dollars.

Comment se protéger de ce type d'attaque ?

1. Pour les sites qui font signer des transactions ou des paiements : limiter au strict minimum les scripts tiers chargés sur les pages où un utilisateur est connecté et peut signer une action, et préférer un chargement depuis votre propre infrastructure pour tout composant sensible.
2. Mettre en place l'intégrité des sous-ressources (Subresource Integrity, SRI) sur les scripts tiers restants, pour que le navigateur refuse d'exécuter un fichier modifié sans que le hachage attendu ne soit mis à jour.
3. Durcir la Content Security Policy (CSP) pour restreindre précisément les domaines autorisés à charger du code exécutable, comme Polymarket indique vouloir le faire en réintroduisant ses scripts tiers avec des garde-fous renforcés.
4. Surveiller les changements DNS de vos prestataires critiques et de votre propre registraire : l'activation d'une authentification forte et d'un verrouillage de transfert chez le registraire réduit ce vecteur, déjà observé sur d'autres incidents de chaîne d'approvisionnement logicielle.
5. Pour les traders et utilisateurs : refuser toute demande de signature de transaction inattendue, même sur un site habituel, et revoir régulièrement les sessions actives et les autorisations accordées à des applications tierces.
6. Ce type de compromission d'un composant tiers de confiance rappelle la logique de la faille SlugFest ayant menacé l'écosystème npm : le point faible n'est pas toujours le site visé, mais un maillon de sa chaîne de dépendances.

L'avis du CSIRT

Pour une organisation qui charge des scripts tiers sur des pages authentifiées, qu'il s'agisse de mesure d'audience, de performance ou de support client, la priorité immédiate est de faire l'inventaire de ces dépendances externes et de vérifier lesquelles s'exécutent sur des pages où un utilisateur peut initier une action sensible (paiement, signature, changement de compte). Un script de mesure de performance n'a normalement aucune raison d'accéder à la logique métier de la page : son isolement, via une CSP stricte ou un chargement en sandbox, doit être traité comme une exigence de sécurité, pas seulement de performance.

La détection ne repose pas ici sur une signature de malware classique, puisque le code s'exécute dans le navigateur de la victime et non sur l'infrastructure de l'organisation visée. Les signaux à surveiller sont plutôt comportementaux : des transactions ou des demandes de signature inhabituelles émises en rafale sur une courte période, une activité provenant d'un script tiers dont le contenu a changé sans publication annoncée côté fournisseur, ou une résolution DNS d'un prestataire qui change brusquement de serveur.

Le piège le plus fréquent après un tel incident est de se limiter au retrait du script fautif. Cela stoppe l'attaque en cours, mais ne garantit rien sur les sessions déjà actives au moment de la compromission : elles doivent être invalidées, comme l'a fait Polymarket en réinitialisant toutes les sessions de connexion, et les autorisations de signature déjà accordées à des applications tierces méritent d'être revues une par une plutôt que supposées saines.

Points clés

• Le 29 octobre 2026, un script tiers de DebugBear chargé par Polymarket a été modifié après le détournement des DNS de DebugBear via son registraire, et non via une intrusion sur les serveurs de DebugBear ou de Polymarket.
• Le code a exploité la session active d'utilisateurs connectés pour transférer ou solder leurs positions, sans voler mots de passe ni clés privées.
• La perte s'élève à 2,7 millions de dollars sur 726 portefeuilles ; Polymarket a remboursé la quasi-totalité des fonds dès le lendemain, pour un total de 3,9 millions de dollars reversés en comptant les pertes liées à la pause de trading.
• L'incident illustre un risque de chaîne d'approvisionnement logicielle : un script tiers non sensible en apparence (mesure de performance) peut devenir un vecteur critique sur une page où des utilisateurs signent des transactions.
• Les mesures efficaces combinent intégrité des sous-ressources (SRI), Content Security Policy stricte, surveillance des changements DNS côté prestataires, et invalidation systématique des sessions après un tel incident.

Cet épisode rappelle d'autres vols massifs de cryptoactifs récents, comme le vol de 6,3 milliards de dollars chez Binance, même si les vecteurs d'attaque diffèrent sensiblement d'un cas à l'autre.

Sources

• The Hacker News : Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script
• Hudson Rock (Infostealers) : analyse du code de vidage de portefeuille
• Historique du statut officiel de Polymarket