En bref : l'attaque par script contre Polymarket en octobre
- Un autre prestataire compromis : Le 2026-10-29, un script de suivi des performances remplacé a utilisé des sessions actives de Polymarket pour vendre des positions et déplacer des fonds.
- Le précédent de juin : Polymarket a révélé une attaque similaire contre la chaîne d'approvisionnement de son frontend le 2026-06-25. cside a analysé le vol signalé d'environ 3 millions de dollars.
- Remboursements : Polymarket a annoncé 3,9 millions de dollars de remboursements pour octobre, dont 1,2 million pour les pertes liées à la suspension des échanges.
Peu de temps ? Découvrez la sécurité côté client de cside pour la surveillance des scripts et la protection à l'exécution dans le navigateur.
Un script de suivi des performances est devenu un accès aux fonds des utilisateurs. Quatre mois après la compromission de son frontend en juin, Polymarket a subi une nouvelle attaque impliquant des scripts tiers.
Le 2026-10-29, un script compromis d'un prestataire a utilisé des sessions actives de Polymarket pour vendre des positions et déplacer des fonds depuis les portefeuilles touchés. Dans sa mise à jour du 2026-10-30, Polymarket a fixé le remboursement total à 3,9 millions de dollars, dont 1,2 million pour les pertes liées à la suspension des échanges. Le rapport d'incident de Polymarket décrit la réponse et les remboursements.
Pour les équipes qui exploitent des applications financières, ce problème récurrent mérite leur attention : le JavaScript tiers fait partie de leur périmètre de sécurité.
Ce qui s'est passé le 2026-10-29
Polymarket a expliqué qu'un attaquant avait remplacé le script de suivi des performances d'un prestataire par du code ciblant ses utilisateurs. L'entreprise a retiré le script et vidé les caches. Elle a aussi suspendu les échanges et son relayer, puis réinitialisé toutes les sessions de connexion actives. Son rapport a décrit davantage de contrôles d'intégrité, de surveillance, de versions figées, d'isolation et une Content Security Policy plus restrictive.
Les montants des remboursements demandent de la précision. Les 3,9 millions de dollars annoncés par Polymarket incluent des indemnisations au-delà des fonds dérobés. Présenter cette somme entière comme de l'argent volé exagérerait le vol signalé. Source
Comment le code de suivi a accédé aux fonctions de trading
L'enquête technique de Hudson Rock a identifié du JavaScript malveillant servi depuis une URL DebugBear associée à l'intégration de suivi des utilisateurs réels de Polymarket.
Le code malveillant lisait le contexte du compte stocké dans le navigateur et parcourait les structures internes de React pour trouver le client de trading et le signataire de l'application. Ses branches tentaient soit de transférer les tokens de positions, soit de vendre les positions puis de transférer le produit des ventes. Il demandait des signatures et tentait d'envoyer les opérations via le relayer de Polymarket.
Un outil de performance tentait d'exercer une autorité financière dans la page.
L'analyse de Hudson Rock n'a pas établi que chaque demande de signature aboutissait silencieusement. Les confirmations du portefeuille, les règles de session et l'exécution des transactions restent déterminantes. Les chercheurs n'ont pas non plus identifié de routine exfiltrant des clés privées ou des phrases de récupération. L'approche observée consistait à réutiliser l'autorité disponible dans l'application authentifiée. Source
Polymarket avait subi une attaque similaire en juin
Nous avons analysé la précédente attaque contre la chaîne d'approvisionnement côté client de Polymarket après sa révélation le 2026-06-25. Un prestataire tiers compromis avait injecté du code malveillant dans le frontend, avec un vol signalé d'environ 3 millions de dollars.
Notre analyse de juin décrivait un mécanisme de phishing d'approbations via l'interface authentique de Polymarket. L'enquête d'octobre décrit un code malveillant cherchant le client de trading et le signataire dans une session existante.
| Incident | Mécanisme signalé | Impact financier signalé |
|---|---|---|
| 2026-06-25 | Un prestataire compromis injecte du code dans le frontend associé à des demandes malveillantes d'approbation ou de signature | Environ 3 millions de dollars volés, selon notre précédente analyse |
| 2026-10-29 | Un script de suivi remplacé abuse de sessions actives ; les chercheurs identifient une logique de trading et de signature | Polymarket annonce 3,9 millions de dollars de remboursements, dont des indemnisations liées à la suspension |
Le point commun est l'accès de scripts tiers à un processus financier sensible. Cette similitude ne prouve pas qu'il s'agit du même attaquant, du même prestataire ou de la même méthode de compromission initiale.
Ce que les équipes applicatives doivent changer
Lors d'une revue de sécurité, la question pratique est de savoir si une intégration de suivi peut accéder à des capacités dépassant largement son rôle prévu.
Commencez par réduire l'exécution de scripts tiers sur les pages authentifiées de trading et de signature. Exigez une justification métier claire pour chaque intégration, un responsable et une procédure de retrait. Examinez la frontière d'accès aux signatures et décidez quelles actions exigent une nouvelle confirmation explicite.
Pour les dépendances qui peuvent être figées, utilisez Subresource Integrity. SRI permet au navigateur de comparer un fichier téléchargé à une empreinte cryptographique attendue et de le rejeter en cas de différence. Les déploiements entre origines nécessitent une prise en charge adaptée de CORS et un processus contrôlé de mises à jour approuvées.
Conservez aussi le contenu des scripts livrés aux utilisateurs. Une enquête a besoin de preuves de ce qui s'est exécuté, du moment où le contenu a changé et des sessions qui ont pu le recevoir.
Ce qu'apporte cside
cside fournit une visibilité sur l'exécution dans le navigateur, un inventaire des scripts, un historique de leur contenu et la détection de comportements malveillants. Ces capacités aident les équipes à enquêter sur les modifications du code exécuté dans les sessions clients. Découvrez la sécurité côté client de cside.
Les incidents de juin et d'octobre rendent la priorité concrète : examiner le code autorisé à s'exécuter auprès des processus les plus sensibles, limiter son autorité et vérifier en continu ce qui parvient aux utilisateurs.
