Polymarket Breach: Trading Screen Safety Issues

Imaginez ouvrir votre plateforme de prédiction préférée, vérifier vos positions sur un événement politique ou un match, puis découvrir quelques minutes plus tard que tout a été vendu et que l’argent a quitté votre compte. C’est exactement ce qu’ont vécu plusieurs utilisateurs de Polymarket le 29 octobre. Un fournisseur de services web a été compromis, et le code malveillant a agi directement depuis l’écran de trading que les traders utilisaient en toute confiance.

La faille qui a frappé directement l’interface de trading

Le 29 octobre, Polymarket a dû interrompre ses activités internationales pendant une heure environ. Entre 18 h 05 et 19 h 05 UTC, la plateforme est passée en mode annulation uniquement. Les nouvelles ordres étaient bloqués, le relayer était en pause, et les équipes tentaient de comprendre ce qui se passait. Des traders signalaient déjà des pertes importantes. L’un d’eux, connu sous le nom de Car, a affirmé avoir perdu environ 800 000 dollars. Toutes ses positions avaient été liquidées. Un de ses amis aurait perdu 600 000 dollars de plus.

Ce n’était pas une simple erreur de transaction. Les utilisateurs parlaient de ventes forcées et de transferts non autorisés. Certains avaient même séparé leurs appareils pour limiter les risques : un pour le trading, un autre pour le développement, un troisième pour les activités personnelles. Pourtant, le problème venait de l’intérieur même de la page web légitime de Polymarket.

Un script de monitoring détourné

Les chercheurs en sécurité ont rapidement identifié la source. Un script de performance chargé par un fournisseur tiers, DebugBear, contenait du code malveillant. DebugBear propose normalement des outils de mesure de vitesse de chargement et d’expérience utilisateur. Son service de monitoring injecte du JavaScript dans le site du client. Dans ce cas, le fichier servi depuis l’infrastructure de DebugBear cherchait activement le client de trading et le signataire déjà présents dans la session active de l’utilisateur.

Une fois localisés, le code examinait les soldes et les positions. Il tentait ensuite de vendre les contrats ouverts avant de transférer les fonds vers une adresse contrôlée par l’attaquant. Hudson Rock, qui a analysé le fichier, a noté que le script ne cherchait pas à extraire de phrase de récupération, de mot de passe ou de clé privée. Il se contentait de réutiliser les autorisations déjà disponibles dans la session authentifiée. C’est précisément ce qui rend l’attaque si insidieuse.

Le danger n’arrivait pas par un lien suspect. Il se trouvait déjà dans la page que le trader avait ouverte pour gérer son argent.

BleepingComputer a confirmé ces observations. L’équipe a suivi environ 28,6 millions de tokens POL depuis le portefeuille suspect vers trois autres adresses. La valeur de ces mouvements était estimée à près de 2,57 millions de dollars au moment de l’analyse. D’autres observateurs ont avancé des chiffres proches de 2,7 millions. Un compte nommé StarPlatinum a même suivi l’accumulation en temps réel : 412 000 dollars à 17 h 25 UTC, puis 2,02 millions à 17 h 50 UTC. Les premiers mouvements auraient commencé vers 17 h 05, soit avant même que Polymarket n’annonce la restriction de service.

Chronologie d’une heure critique

Polymarket a d’abord placé la plateforme internationale en mode annulation uniquement. Les utilisateurs pouvaient encore annuler leurs ordres ouverts, mais plus rien de nouveau ne passait. À 18 h 37 UTC, la société a annoncé avoir identifié et corrigé le problème. Un fournisseur tiers avait été compromis. Le trading restait temporairement suspendu par précaution. À 18 h 55, un nouveau message indiquait une reprise vers 15 h heure de l’Est. L’incident a été marqué comme résolu à 19 h 05 UTC.

La société a immédiatement promis de rembourser les utilisateurs touchés. Elle a aussi signalé l’affaire aux autorités britanniques, DebugBear étant basé au Royaume-Uni. Pourtant, aucun chiffre officiel de pertes n’a été publié. Aucun détail technique complet n’a été partagé. Les mises à jour publiques se sont contentées de confirmer la compromission du fournisseur et le rétablissement du service.

Le précédent du mois de juin

Ce n’est pas la première fois que Polymarket subit ce type d’incident. Le 25 juin, un autre fournisseur avait déjà été compromis. Un script malveillant était apparu sur le site pour certains utilisateurs. La société avait alors promis des remboursements complets. L’analyste Specter avait estimé les pertes à au moins 2,94 millions de dollars, principalement en PUSD convertis en ETH. AMLBot avait ensuite relevé le chiffre à 3,1 millions.

Quatre mois plus tard, le scénario se répète. Deux incidents distincts, deux fournisseurs différents selon les informations disponibles, mais le même schéma : du code tiers chargé dans la page légitime, capable d’agir au nom de l’utilisateur connecté. Polymarket n’a pas indiqué que les deux attaques étaient liées. Elles restent traitées comme des événements séparés.

Pourquoi l’écran de trading devient le point faible

La plupart des traders pensent que le danger vient d’un site de phishing ou d’une extension malveillante. Ici, le risque était intégré à la page qu’ils visitaient chaque jour. Le navigateur charge le script du fournisseur en même temps que le code de l’application. Une fois exécuté, ce script a accès à tout ce qui se trouve dans le même contexte de page. Les soldes, les positions, le client de trading, le signataire : tout est potentiellement accessible.

Mozilla rappelle dans sa documentation que du JavaScript inclus directement dans une page peut interagir avec les autres scripts et données de cette page. Il n’y a pas d’isolation automatique simplement parce que le code provient d’un autre domaine. Seule une iframe isolée crée une frontière réelle. Un script de monitoring chargé dans l’application principale ne bénéficie pas de cette protection.

Les contrôles techniques existent pourtant. L’intégrité des sous-ressources (Subresource Integrity) permet de vérifier qu’un fichier distant correspond exactement à une empreinte cryptographique définie par le site. Si le fichier change, le navigateur refuse de l’exécuter. La Content Security Policy peut aussi restreindre les sources de scripts autorisées. Mais ces protections ne fonctionnent que si elles sont correctement configurées et maintenues. Polymarket n’a pas précisé si le script de DebugBear était protégé par ces mécanismes.

Autorité de trading et autorité de retrait : deux niveaux différents

Polymarket propose plusieurs types de portefeuilles. Les Deposit Wallets, déployés à partir du 4 mai 2026, et d’anciens systèmes Proxy et Safe. La plateforme permet aussi d’autoriser une clé de session pour le trading. Selon la documentation, une clé de session peut trader pour un Deposit Wallet mais ne peut pas retirer les fonds. C’est une séparation volontaire des pouvoirs.

Pourtant, même une autorisation limitée au trading peut causer des dégâts. Vendre toutes les positions d’un utilisateur change radicalement la composition de son portefeuille. Si les contrats portaient sur un événement encore non résolu, le trader perdait non seulement le contrôle immédiat, mais aussi l’exposition future qu’il souhaitait conserver. Les rapports d’utilisateurs mentionnent précisément ce scénario : positions liquidées, puis fonds déplacés.

Les ordres sur Polymarket sont signés hors chaîne. L’opérateur vérifie la signature, les soldes et les allowances avant de matcher. Le règlement final passe par les contrats sur la blockchain. Une signature valide ne prouve pas que l’utilisateur a volontairement cliqué. Elle prouve seulement que le signataire disponible dans la session a autorisé l’action. C’est exactement ce que le script malveillant a tenté d’exploiter.

La question des remboursements reste ouverte

Polymarket a promis de rendre les utilisateurs touchés « whole », c’est-à-dire de les indemniser intégralement. La déclaration a été répétée après la reprise du trading. Mais aucun détail n’a été donné sur la méthode. Comment valoriser une position vendue de force ? Au prix du moment de la vente ? Au prix actuel ? En restaurant les contrats originaux ?

Un trader qui détenait des contrats Yes ou No sur un événement non encore résolu n’avait pas nécessairement l’intention de les vendre. Le prix de marché au moment de la vente forcée peut être très différent de la valeur future une fois l’événement connu. Restaurer simplement le cash reçu ne revient pas à restaurer la position d’origine. Polymarket n’a pas encore tranché publiquement cette question.

Le support international est joignable via le chat du site et l’adresse support@polymarket.com. L’application américaine dispose de son propre canal. Aucun calendrier de paiement n’a été annoncé. Aucune demande de frais de récupération ni de partage de clés n’a été formulée, ce qui est rassurant, mais l’absence de procédure claire laisse les utilisateurs dans l’attente.

Ce que révèle cette attaque sur la confiance placée dans l’interface

Les plateformes de prédiction et de trading crypto reposent sur un paradoxe. Elles promettent la décentralisation et le contrôle des clés, mais l’expérience quotidienne passe par une interface web complexe. Cette interface charge des dizaines de scripts tiers : analytics, monitoring de performance, outils de support, services de signature. Chaque script supplémentaire élargit la surface d’attaque.

Dans le cas de Polymarket, le script de DebugBear n’avait normalement qu’un rôle de mesure. Une fois compromis, il a pu se comporter comme un agent de trading autonome. Les utilisateurs qui avaient pris des précautions – appareils séparés, liens vérifiés – n’étaient pas protégés, parce que le code malveillant s’exécutait dans le contexte même de la page de confiance.

Cette situation n’est pas unique. Les applications web modernes dépendent massivement de chaînes d’approvisionnement logicielles. Un fournisseur compromis peut affecter des centaines de clients. Pour une plateforme financière, les conséquences sont immédiates et mesurables en millions de dollars.

Les points encore non résolus

Plusieurs questions restent sans réponse claire. Quelle a été la durée exacte d’exposition des utilisateurs ? Le script malveillant a-t-il touché tous les visiteurs ou seulement une partie ? Quels types de portefeuilles ont été réellement affectés ? Les clés de session ont-elles joué un rôle, ou le script a-t-il utilisé le signataire principal de l’application ?

Polymarket a indiqué avoir retiré l’intégration DebugBear. Les métadonnées de build de production contiendraient même une référence à ce retrait. Mais le moment exact de la suppression n’a pas été confirmé. Les estimations de pertes varient encore entre les différentes analyses blockchain. La société n’a publié aucun bilan consolidé.

L’enquête a été transmise aux autorités. Le nom de l’attaquant et le mode d’accès initial au fournisseur restent inconnus du public. On ne sait pas non plus si d’autres clients de DebugBear ont été touchés de manière similaire.

Les leçons pour les traders et les plateformes

Pour les utilisateurs, l’épisode rappelle qu’aucun niveau de prudence personnelle ne peut compenser une faille dans le code chargé par la plateforme elle-même. Séparer les appareils, vérifier les URL, utiliser des hardware wallets : tout cela reste utile, mais insuffisant face à un script exécuté dans le contexte de confiance.

Pour les plateformes, la leçon est plus structurelle. Chaque intégration tierce doit être traitée comme un risque critique. L’intégrité des sous-ressources, les politiques de sécurité de contenu strictes, la minimisation des permissions accordées aux scripts externes et des audits réguliers deviennent des exigences de base. Quand l’interface affiche des soldes et prépare des signatures, le moindre script chargé doit être considéré comme potentiellement dangereux.

La distinction entre autorité de trading et autorité de retrait est une bonne pratique. Elle limite les dégâts. Mais elle ne protège pas contre la liquidation forcée de positions. Un trader peut se retrouver avec un portefeuille entièrement transformé sans jamais avoir approuvé la transaction de manière consciente.

Comment les positions vendues compliquent l’indemnisation

Sur Polymarket, un ensemble complet de contrats Yes et No est adossé à 1 pUSD. Chaque contrat individuel se règle selon le résultat de l’événement. Un trader peut choisir de conserver ses positions jusqu’à la résolution ou de les vendre plus tôt sur le marché secondaire. Quand une vente non autorisée intervient, l’historique d’ordres enregistre à la fois la disparition des contrats et l’arrivée des fonds correspondants.

Si Polymarket se contente de restituer le cash reçu au moment de la vente, le trader perd l’exposition qu’il souhaitait. Si la plateforme restaure les contrats originaux, elle doit gérer le risque de marché entre-temps. Aucune des deux solutions n’est simple. La promesse de remboursement complet reste donc conceptuellement claire, mais opérationnellement complexe.

Les historiques d’ordres et les traces blockchain offrent des éléments de preuve. Pourtant, reconstituer le parcours exact de chaque utilisateur demande du temps. Certains fonds ont pu passer par plusieurs adresses. D’autres positions ont pu être revendues immédiatement. Le travail de réconciliation sera long.

Un schéma qui se répète dans l’écosystème

Les attaques via la chaîne d’approvisionnement logicielle ne sont pas nouvelles. Des projets majeurs ont déjà été touchés par des dépendances compromises ou des comptes de mainteneurs piratés. Dans le cas de Polymarket, le vecteur était un outil de monitoring de performance, un service apparemment anodin. C’est souvent là que se trouve le point d’entrée : un service discret, largement déployé, dont la compromission donne un accès privilégié.

Les plateformes de trading et de prédiction cumulent des risques particuliers. Elles gèrent à la fois des données financières sensibles et des capacités de signature. L’interface web devient un point unique de confiance. Quand ce point est percé, les conséquences sont immédiates pour des milliers d’utilisateurs.

Polymarket a réagi rapidement en suspendant le service et en promettant des remboursements. Cette réactivité limite les dégâts. Elle ne résout pas le problème de fond : la dépendance à des scripts tiers dans un environnement financier critique.

Ce qu’il faut surveiller dans les prochaines semaines

Plusieurs éléments permettront de mesurer la suite de l’affaire. Les conclusions techniques sur les permissions réellement utilisées par le script. Les détails sur la façon dont le fournisseur a été compromis. Un bilan officiel des pertes et du nombre de comptes touchés. Et surtout, les modalités précises de remboursement pour les positions vendues de force.

Les traders concernés auront intérêt à conserver toutes les captures d’écran et les historiques de transactions. Même si la société promet une indemnisation, la reconstitution exacte de chaque portefeuille demandera des preuves solides. Les canaux de support officiels restent le seul point de contact recommandé.

La plateforme américaine n’a pas été mentionnée comme affectée dans les communications du 29 octobre. Seule la version internationale a fait l’objet de restrictions. Cette séparation pourrait limiter l’impact global, mais elle n’efface pas le précédent créé.

Une confiance à reconstruire

L’incident du 29 octobre n’est pas seulement une question de millions de dollars déplacés. Il touche directement le contrat de confiance entre une plateforme et ses utilisateurs. Quand l’écran de trading, l’outil même qui permet de gérer l’argent, devient le vecteur de l’attaque, le sentiment de sécurité s’érode.

Polymarket a déjà traversé un épisode similaire en juin. La répétition, à quatre mois d’intervalle, soulève des interrogations sur les processus de validation des fournisseurs et sur la surveillance continue des scripts chargés. Les utilisateurs, de leur côté, découvrent que même une interface familière et légitime peut cacher un danger temporaire.

Dans un secteur où la confiance est déjà fragile, chaque faille de ce type laisse des traces. Les remboursements, s’ils sont effectués rapidement et de manière transparente, peuvent atténuer le choc. Mais la véritable question reste celle de la solidité des mécanismes de protection autour de l’interface de trading elle-même.

Les prochaines annonces de Polymarket sur les modalités d’indemnisation et sur les mesures techniques prises pour éviter un troisième incident seront déterminantes. En attendant, les traders qui ont vu leurs positions disparaître en quelques minutes savent désormais qu’un simple script de monitoring peut transformer un écran de confiance en outil de liquidation.

La sécurité d’une plateforme ne se limite plus aux smart contracts et aux signatures hors chaîne. Elle inclut désormais chaque ligne de JavaScript chargée dans le navigateur de l’utilisateur. Et c’est peut-être la leçon la plus claire de cette journée du 29 octobre.