Polymarket : un script de supervision tiers détourné a vidé des portefeuilles, 3,9 millions de dollars remboursés

Le 29 octobre 2026, un script de mesure de performance fourni par un prestataire et chargé sur polymarket.com a été remplacé par du code malveillant. Il s’est servi des sessions ouvertes des utilisateurs pour vendre leurs positions et sortir les fonds. Polymarket annonce 3,9 millions de dollars de remboursements et a durci le contrôle de ses scripts tiers.

Ce qui s’est passé

Dans un rapport d’incident publié le 30 octobre 2026, la plateforme de paris prédictifs Polymarket indique avoir repéré, le 29 octobre à 17 h 38 UTC, une activité non autorisée sur des portefeuilles d’utilisateurs. Son propre code n’était pas en cause : un prestataire dont le script de mesure de performance était chargé sur polymarket.com avait été compromis, et l’attaquant a remplacé ce script par une version ciblant les utilisateurs de Polymarket. Chez une partie des personnes qui avaient le site ouvert pendant une courte fenêtre, cet après-midi-là, le script a exploité la session active pour vendre des positions et transférer les fonds hors de leurs portefeuilles.

Polymarket rembourse 3,9 millions de dollars au total : 2,7 millions au titre du vol et 1,2 million pour les pertes liées à la suspension des échanges. À la publication du rapport, 95 % des portefeuilles touchés avaient été intégralement remboursés. L’entreprise ne précise pas le nombre de victimes et a saisi les forces de l’ordre.

Comment les attaquants sont entrés

Le site faisait confiance au domaine du prestataire : les navigateurs exécutaient donc tout ce qu’il servait. Selon l’analyse de Hudson Rock, la politique de sécurité du contenu (CSP) du site autorisait ce domaine ; le script piégé lisait les données d’authentification stockées dans le navigateur, repérait le client de trading dans la page, puis demandait des signatures et soumettait des transferts vers une adresse contrôlée par l’attaquant. D’après The Record, le prestataire estime que ses premières constatations désignent une compromission passée par son bureau d’enregistrement de noms de domaine.

Que faire maintenant

1. Recensez les scripts externes de vos sites, par exemple avec curl -s https://www.example.com/ | grep -oE 'src=[^ >]+', et supprimez ceux dont personne n’a besoin, en commençant par les pages de connexion, de paiement et d’espace client.
2. Figez et vérifiez ceux qui restent : hébergez vous-même une version fixe, ou ajoutez l’intégrité des sous-ressources (SRI) sur les fichiers qui ne changent pas (empreinte obtenue avec openssl dgst -sha384 -binary fichier.js | openssl base64 -A) : un fichier modifié sera alors refusé.
3. Resserrez la CSP : listes script-src et connect-src précises, avec remontée des violations. Autoriser un domaine ne contrôle pas ce qu’il distribue.
4. Surveillez les modifications : calculez régulièrement l’empreinte des fichiers tiers et alertez au moindre changement.
5. Préparez la riposte : sachez retirer un script et invalider toutes les sessions en quelques minutes, comme l’a fait Polymarket.
6. Protégez vos propres domaines : double authentification et verrouillage (registrar lock) sur vos comptes chez le bureau d’enregistrement.

Notre avis

Un script chargé depuis un autre domaine s’exécute avec les mêmes droits que votre propre code, dans les sessions de vos clients. Une balise d’analyse ou de supervision passe rarement pour un élément critique ; ici, elle a suffi à vider des comptes. Moins de scripts tiers, des versions figées et un contrôle d’intégrité coûtent peu au regard d’un remboursement en millions.

Sources

• Polymarket Status — Post-mortem of the 29 October 2026 incident
• The Record — Polymarket pledges to give $3.9 million back to victims after site compromise
• The Record — Polymarket confirms cyberattack involving third party
• Hudson Rock (Infostealers) — Polymarket breach alert: wallet-draining code found in a third-party script

Comment nous choisissons, vérifions et rédigeons nos analyses →