La plateforme de marchés prédictifs Polymarket a été victime d’une attaque informatique ayant permis à des pirates de détourner les positions et les fonds de plusieurs utilisateurs connectés à son site web. L’incident, survenu le 29 octobre 2026, repose sur la compromission d’un script JavaScript externe chargé par la plateforme pour améliorer la vitesse de chargement de ses pages.
Au lieu d’exploiter directement une faille dans les contrats intelligents de Polymarket, les attaquants ont compromis un composant logiciel tiers exécuté dans le navigateur des utilisateurs. Le code malveillant a pu interagir avec les sessions de certains traders et déclencher des opérations non autorisées, entraînant la vente de leurs positions et le transfert de leurs fonds vers des portefeuilles contrôlés par les pirates.
Polymarket a annoncé qu’environ 2,7 millions de dollars seraient remboursés à 726 portefeuilles affectés. Les données enregistrées sur la blockchain indiquent, quant à elles, qu’environ 2,64 millions de dollars en cryptomonnaies ont effectivement été transférés.
Cet incident illustre les risques liés à la dépendance des plateformes Web3 envers des scripts externes, même lorsque ceux-ci sont intégrés pour des fonctions apparemment secondaires comme l’optimisation des performances.
Comment le script malveillant a-t-il fonctionné ?
Le code frauduleux a été distribué à travers le script de surveillance des performances fourni par DebugBear, une entreprise qui propose des outils de mesure de la vitesse de chargement des sites web.
Son produit Real User Monitoring (RUM) utilise un fichier JavaScript intégré aux pages des clients pour mesurer les performances réelles depuis les navigateurs des visiteurs. Polymarket chargeait ce composant sur son site international.
Les pirates ont remplacé le script légitime par une version malveillante. Comme ce fichier était exécuté directement dans les pages de Polymarket, il bénéficiait du contexte de la session ouverte par les utilisateurs.
Les chercheurs de Hudson Rock ont récupéré et analysé le fichier compromis sans l’exécuter. Leur examen a révélé plusieurs capacités particulièrement dangereuses :
- Lire certaines informations de session conservées dans le navigateur.
- Repérer les comptes Polymarket déjà connectés.
- Accéder aux composants de l’application chargés de réaliser les opérations de trading.
- Identifier les mécanismes de signature utilisés pour autoriser les transactions.
- Déclencher des opérations visant à vendre ou transférer les positions des utilisateurs.
Le script ne se contentait donc pas de collecter des données de navigation. Il cherchait à détourner les fonctionnalités de trading auxquelles l’utilisateur avait déjà accès.
Deux méthodes de détournement selon le type de compte
Les chercheurs ont identifié deux chemins d’attaque, selon la méthode utilisée pour se connecter à Polymarket.
Pour les comptes connectés avec un portefeuille crypto, le code tentait de transférer directement les positions de trading vers un portefeuille contrôlé par les pirates.
Pour les comptes utilisant une connexion par e-mail, le script cherchait à vendre les positions à des prix progressivement moins avantageux, puis à transférer les fonds obtenus.
Cette distinction est importante : l’attaque ne reposait pas simplement sur le vol d’une phrase de récupération ou d’une clé privée. Hudson Rock n’a pas identifié, dans le fichier analysé, de mécanisme destiné à transmettre les mots de passe, les phrases de récupération ou les clés privées à un serveur distant.
Le code tentait plutôt de réutiliser les composants déjà présents dans l’application pour effectuer des opérations au nom des utilisateurs.
Il faut également préciser qu’une demande de signature ne signifie pas automatiquement qu’une transaction a été approuvée sans intervention de l’utilisateur. Le portefeuille connecté peut encore afficher une demande de validation, appliquer ses propres règles ou refuser l’opération.
Les détails techniques de cette analyse sont présentés dans le rapport de Hudson Rock sur le script malveillant utilisé contre les traders. The Hacker News
DebugBear : un détournement des enregistrements DNS à l’origine de l’incident
L’enquête a également mis en évidence une compromission des enregistrements DNS associés à DebugBear.
Le 29 octobre, l’entreprise a reconnu être touchée par un incident de sécurité et a demandé aux clients utilisant son produit RUM de supprimer le code d’intégration de leurs sites web.
Selon les premières conclusions communiquées par DebugBear, les attaquants ont compromis ses enregistrements DNS en passant par son bureau d’enregistrement de domaine. Cette manipulation aurait permis de rediriger les requêtes vers une infrastructure contrôlée par les pirates, qui distribuait alors le script malveillant.
Les chercheurs d’Ohey ont observé qu’un serveur différent répondait aux adresses web de DebugBear pendant la période de l’attaque. Avant cet incident, le script légitime était distribué depuis Google Cloud Storage.
DebugBear a indiqué que ses premières investigations suggéraient une attaque ciblant le site web d’un client particulier. L’entreprise n’avait pas identifié de preuve d’une intrusion dans ses propres systèmes au moment de sa communication. L’enquête restait toutefois en cours.
Il est donc important de ne pas confondre la compromission des enregistrements DNS avec une compromission confirmée de l’ensemble de l’infrastructure interne de DebugBear.
Cette distinction ne réduit pas la gravité de l’incident : le détournement du domaine a suffi à distribuer un fichier malveillant à des visiteurs d’un site financier utilisant son service.
Les éléments techniques sont notamment détaillés dans l’article de BleepingComputer consacré au script malveillant et au détournement des sessions Polymarket. BleepingComputer+1
2,64 millions de dollars transférés en moins d’une heure
Les transactions enregistrées sur la blockchain permettent de mieux mesurer l’ampleur de l’attaque.
Selon le suivi réalisé par Ohey et les analyses relayées par The Hacker News, le portefeuille identifié comme appartenant aux attaquants a reçu ses premiers fonds vers 17 h 10 UTC, le 29 octobre. Les derniers transferts de positions identifiés sont intervenus vers 18 h 02 UTC.
En moins d’une heure, les pirates ont ainsi récupéré environ 28,6 millions de jetons POL, ainsi que des positions provenant de plusieurs dizaines de portefeuilles.
À 18 h 19 UTC, la valeur des seuls jetons POL était estimée à environ 2,64 millions de dollars. Ce montant ne représente pas nécessairement la totalité de la valeur des positions détournées.
Il faut donc distinguer trois chiffres :
| Montant | Signification |
|---|---|
| Environ 2,64 millions de dollars | Valeur estimée des jetons POL transférés, selon les données blockchain citées |
| Environ 2,7 millions de dollars | Montant annoncé par Polymarket pour rembourser les portefeuilles affectés |
| Environ 3,9 millions de dollars | Montant total annoncé pour les remboursements et les compensations supplémentaires |
Les fonds ont ensuite été transférés vers trois autres adresses, ce qui complique leur suivi et leur éventuelle récupération.
Ces données montrent que la somme remboursée par Polymarket ne doit pas être présentée comme une mesure exacte des seuls actifs effectivement volés. Elle inclut également des compensations liées aux conséquences de l’incident.
Polymarket suspend les opérations et rembourse les utilisateurs
Dès la détection de l’activité frauduleuse, Polymarket a pris plusieurs mesures pour empêcher les pertes supplémentaires.
La plateforme a notamment :
- Retiré le script tiers compromis de son site.
- Vidé les caches afin d’éviter la distribution d’une ancienne version malveillante.
- Suspendu temporairement les opérations de trading.
- Mis en pause les actions de son relayer, le service chargé de soumettre certaines transactions.
- Réinitialisé les sessions de connexion actives.
- Transmis le dossier aux autorités compétentes.
La plateforme a indiqué que le problème avait été contenu en moins d’une heure et que les opérations avaient ensuite repris.
726 portefeuilles concernés par les remboursements
Polymarket a annoncé le remboursement intégral des portefeuilles identifiés comme affectés.
Dans sa communication du 30 octobre, la plateforme indiquait que 689 portefeuilles sur 726 avaient déjà été remboursés. Les 37 autres devaient recevoir leur paiement après vérification.
L’entreprise a également décidé d’indemniser des utilisateurs qui avaient subi des pertes pendant la suspension des transactions. Ces compensations concernent notamment les positions qui ont perdu de la valeur pendant l’interruption ou celles qui ont été vendues dans des conditions défavorables.
Au total, Polymarket prévoit de restituer environ 3,9 millions de dollars, dont 2,7 millions liés aux portefeuilles affectés et environ 1,2 million de dollars de compensations supplémentaires.
La plateforme précise que les utilisateurs éligibles n’ont pas besoin de déposer une réclamation pour recevoir automatiquement leur remboursement. Les modalités et l’évolution des remboursements sont publiées dans son rapport officiel sur l’incident de sécurité du 29 octobre. Status+1
Quelles mesures pour éviter une attaque similaire ?
L’incident de Polymarket montre qu’un site web peut être compromis indirectement, même lorsque son application principale et ses contrats intelligents ne sont pas directement touchés.
Les entreprises qui intègrent des scripts externes dans leurs pages doivent donc considérer ces composants comme des éléments sensibles de leur infrastructure.
1. Limiter les scripts tiers sur les pages sensibles
Les scripts de mesure d’audience, de publicité, de support ou d’optimisation des performances ne devraient pas être chargés sans nécessité sur les pages permettant d’effectuer des transactions financières.
Moins une page manipule de composants externes, moins elle présente de possibilités de détournement par un fournisseur compromis.
2. Mettre en place Subresource Integrity (SRI)
La technologie Subresource Integrity (SRI) permet au navigateur de vérifier que le contenu d’un fichier externe correspond à une empreinte cryptographique attendue.
Si le fichier est modifié sans que l’empreinte soit mise à jour, le navigateur peut refuser de le charger.
Cette protection est particulièrement utile pour les scripts JavaScript hébergés sur des infrastructures tierces. Elle doit toutefois être correctement mise en œuvre et adaptée aux fichiers dont le contenu est susceptible de changer.
3. Renforcer la Content Security Policy
Une politique de sécurité du contenu (CSP) permet de limiter les sources depuis lesquelles une page peut charger des scripts et d’encadrer certaines opérations exécutées dans le navigateur.
Elle ne garantit pas à elle seule qu’un script provenant d’un domaine autorisé est légitime. Un domaine de confiance compromis peut toujours distribuer un fichier malveillant si les contrôles ne vérifient pas son intégrité.
4. Isoler les composants externes
Le sandboxing permet de limiter les capacités d’un composant tiers et de réduire son accès aux données ou aux fonctionnalités sensibles de l’application.
Les plateformes financières doivent notamment éviter qu’un simple outil de mesure des performances puisse interagir librement avec les composants chargés de signer ou d’exécuter des transactions.
5. Sensibiliser les utilisateurs aux demandes de signature
Les traders doivent rester attentifs aux demandes de signature inattendues, même lorsqu’ils sont connectés à un site légitime.
Avant de valider une opération, il est important de vérifier son contenu, sa destination et les autorisations demandées. Une demande de signature inhabituelle doit être refusée.
Conclusion
Le piratage de Polymarket démontre qu’une attaque contre un fournisseur tiers peut avoir des conséquences financières directes pour les utilisateurs d’une plateforme de cryptomonnaies.
En détournant un script de surveillance des performances associé à DebugBear, les attaquants ont pu exploiter les sessions actives de certains traders, vendre leurs positions et transférer leurs actifs vers des portefeuilles frauduleux. Environ 2,64 millions de dollars en cryptomonnaies ont été transférés, tandis que Polymarket annonce près de 2,7 millions de dollars de remboursements pour 726 portefeuilles affectés.
La décision de rembourser les utilisateurs et de renforcer les contrôles sur les scripts externes constitue une réponse importante. Mais l’incident révèle surtout une faiblesse structurelle : un composant tiers exécuté dans le navigateur peut disposer d’un accès suffisamment important pour compromettre une opération financière.
Pour les plateformes Web3, la sécurité ne doit donc pas se limiter aux contrats intelligents et aux portefeuilles. Elle doit aussi englober les scripts JavaScript, les fournisseurs externes, les mécanismes DNS et tous les composants capables d’interagir avec les sessions des utilisateurs.
SOURCE : The Hackers News
