Le 2026-06-25, la plateforme de marchés de prédiction Polymarket a confirmé que des attaquants avaient volé environ 3 millions de dollars à un petit nombre d'utilisateurs. L'enquêteur on-chain Specter, qui a signalé le vol en premier, a retracé environ 2,94 millions de dollars dérobés sur au moins 11 portefeuilles ; la société d'analyse blockchain Bubblemaps a chiffré le total à moins de 15 comptes et a publié les adresses concernées. Polymarket a rapidement contenu l'incident, supprimé la dépendance en cause et s'est engagé à rembourser intégralement chaque utilisateur affecté.
Pour quiconque exploite un site web par lequel transitent de l'argent ou des données sensibles, le détail qui compte est l'endroit où l'attaque s'est produite. Les smart contracts de Polymarket n'ont jamais été compromis. La blockchain a fonctionné exactement comme prévu. Le vol s'est produit dans le navigateur, à travers un script tiers auquel la plateforme faisait confiance. C'est un cas d'école d'attaque de chaîne d'approvisionnement côté client, la même classe d'attaque qui frappe chaque semaine les pages de paiement e-commerce, les pages de connexion fintech et les tableaux de bord SaaS.
La mécanique compte, car elle explique pourquoi tant d'équipes sont exposées au même risque.
Ce qui s'est passé
Dans son propre communiqué, Polymarket a déclaré avoir « découvert qu'un fournisseur tiers avait été compromis, injectant un script malveillant dans notre frontend pour certains utilisateurs », et avoir contenu l'incident et supprimé la dépendance affectée. À ce jour, ni Polymarket ni les médias indépendants n'ont identifié le fournisseur ou la dépendance compromise.
La cible était pUSD, le stablecoin de Polymarket adossé à l'USDC et le principal collatéral de trading de la plateforme. Quand les utilisateurs affectés ont connecté leurs portefeuilles, le code injecté les a incités à signer ou approuver des transactions qui transféraient discrètement des fonds vers l'attaquant. La société de sécurité PeckShield a rapporté que le pUSD volé a été transféré de Polygon vers Ethereum et échangé contre environ 1 893 ETH, que les enquêteurs ont retracés jusqu'à une seule adresse de consolidation. Plusieurs sociétés ont classé l'événement comme une compromission de la chaîne d'approvisionnement combinée à une campagne de phishing menée à travers l'interface même de la plateforme.
La mécanique est simple, et elle s'applique à presque n'importe quel site web moderne :
- L'attaquant n'a jamais eu besoin de pénétrer dans les serveurs ni dans les smart contracts de Polymarket.
- Il a compromis un fournisseur de confiance dont le code avait déjà l'autorisation de s'exécuter sur le site.
- Une fois ce code exécuté dans le frontend en direct, il paraissait identique au code légitime aux yeux des personnes qui utilisaient le site.
Un utilisateur regardant l'interface normale n'avait aucun moyen pratique de savoir que le script gérant sa transaction avait changé. C'est la caractéristique qui définit cette classe d'attaque, et c'est pourquoi elle est si difficile à détecter de l'extérieur.
L'angle technique : un vidangeur de portefeuilles livré par la chaîne d'approvisionnement
La plupart des articles s'arrêtent à « attaque de chaîne d'approvisionnement ». Le mécanisme est plus précis, et c'est ce qui rend cet incident digne d'étude.
Un skimmer Magecart classique est passif. Il lit ce que la victime saisit dans un formulaire de paiement et le copie vers le serveur de l'attaquant. Cette attaque n'avait aucun formulaire à voler, alors le script injecté est devenu actif et s'en est pris à la signature elle-même.
D'après l'analyse on-chain, quand un utilisateur affecté connectait son portefeuille, le script lui présentait une demande malveillante d'approbation ou de signature via l'interface authentique de Polymarket. L'approuver donnait à l'attaquant la capacité de déplacer le pUSD de la victime. C'est la même technique de phishing d'approbations sur laquelle s'appuient les vidangeurs de portefeuilles : obtenir que le détenteur signe une approbation ERC-20 ou un permit de tokens, puis balayer le solde vers une adresse contrôlée par l'attaquant. Le signe le plus clair est la remédiation donnée par tous les enquêteurs, qui était de révoquer les approbations de tokens. On ne révoque des approbations que lorsque les approbations étaient l'arme.
Voici ce qui est différent dans ce cas. Les vidangeurs de portefeuilles atteignent d'habitude les victimes via de faux sites d'airdrop, des publicités malveillantes, des domaines typosquattés ou des liens sociaux détournés. Tous dépendent de vous attirer dans un endroit faux, donc le conseil habituel fonctionne : vérifiez l'URL, utilisez le site officiel, cherchez le cadenas. Rien de tout cela n'a aidé ici. Le vidangeur s'est exécuté sur le vrai polymarket.com, dans une session où l'utilisateur avait déjà connecté son portefeuille et avait toutes les raisons de faire confiance à l'invite suivante. L'injection dans la chaîne d'approvisionnement a transformé le frontend légitime en page de phishing.
Ce schéma a un précédent clair et nommé. En décembre 2023, des attaquants ont hameçonné le compte npm d'un ancien employé de Ledger et publié des versions malveillantes de @ledgerhq/connect-kit, la bibliothèque open source que de nombreuses dApps utilisent pour connecter les portefeuilles matériels Ledger. Les versions empoisonnées ont injecté un vidangeur de portefeuilles dans le frontend de chaque site qui chargeait la bibliothèque, dont SushiSwap, Zapper et Revoke.cash, et ont emporté environ 600 000 dollars en quelques heures. Une seule dépendance open source détournée a vidé les utilisateurs de nombreux sites à la fois, sans aucune URL factice. La dépendance compromise de Polymarket n'a pas été nommée, mais le plan est le même.
Les propres mots de Polymarket portent le détail qui compte le plus pour les défenseurs : le script a été injecté « pour certains utilisateurs ». Le payload était conditionnel. C'est la même propriété qui permet à ces attaques d'échapper à un scanner qui parcourt depuis un centre de données, et c'est pourquoi un contrôle qui vérifie seulement l'origine d'un script ne peut pas aider une fois l'origine de confiance.
Où cette attaque s'est réellement produite
Ranger cela dans la catégorie « encore un piratage crypto » masque la partie qui devrait préoccuper toute équipe web. La couche blockchain s'est comportée correctement. Les smart contracts n'ont pas été exploités. Il n'y a eu ni bug de reentrancy, ni flash loan, ni manipulation d'oracle. L'attaque a vécu entièrement dans le runtime du navigateur, la couche entre votre serveur et l'écran de votre utilisateur, où le JavaScript tiers s'exécute avec les mêmes privilèges que votre propre code.
Cette couche est l'une des surfaces les moins surveillées des applications web modernes. Les équipes répètent la règle « ne jamais faire confiance au côté client », puis chargent couramment des dizaines de requêtes tierces dans ce côté client : analytics, gestionnaires de balises, widgets de chat, pixels marketing et SDKs. Chacun d'eux est une dépendance, et chaque dépendance est un point d'entrée potentiel. L'attaquant de Polymarket a utilisé une relation fournisseur qui était déjà de confiance, parce que le fournisseur à l'autre bout avait été compromis.
Nous avons déjà documenté ce schéma. La compromission du SDK Web AppsFlyer a suivi le même plan : les attaquants ont détourné un SDK marketing de confiance et servi un payload malveillant à des milliers de sites dont les propriétaires ignoraient que leurs scripts avaient changé. Nous avons aussi suivi des extensions de navigateur malveillantes usurpant Microsoft Clarity pour écraser des tokens de parrainage et détourner des revenus. Des payloads différents, la même cause racine : du code tiers de confiance qui devient hostile, s'exécute dans le navigateur et reste invisible pour les défenses traditionnelles.
Pourquoi les défenses standard ne détectent pas cette classe d'attaque
Si vous vous demandez pourquoi les contrôles de sécurité habituels n'arrêtent pas cela, la réponse est structurelle. La plupart des outils sur lesquels les équipes s'appuient ne peuvent tout simplement pas voir cette attaque.
- La sécurité côté serveur et réseau surveille votre propre infrastructure. Le code malveillant ne l'a jamais touchée. Le fournisseur a été compromis en amont, et le payload s'est exécuté sur l'appareil de l'utilisateur.
- La Content Security Policy (CSP) autorise quels domaines peuvent servir des scripts, mais elle valide l'origine, pas le comportement. Si un fournisseur de confiance et autorisé se met à servir du code malveillant, la CSP le laisse passer. Elle n'a aucune idée de savoir si le script lit un champ de formulaire ou demande au portefeuille une approbation de tokens. Pour aller plus loin, voyez pourquoi la CSP seule n'arrête pas les attaques côté client.
- Les scanners statiques parcourent votre site à la recherche de scripts malveillants connus. Les attaquants plus sophistiqués détectent le scanner et lui servent une version propre tout en livrant le vrai payload aux utilisateurs réels. Le script de Polymarket s'est exécuté « pour certains utilisateurs », ce qui est exactement ce type de livraison conditionnelle, et un scanner est la chose la plus facile à exclure.
Le comportement qui aurait dû ressortir est précis : un script tiers qui n'avait jamais touché le fournisseur de portefeuille se mettant soudain à interagir avec lui et à demander aux utilisateurs d'approuver des transferts de tokens. C'est observable dans le runtime JavaScript, là où le script s'exécute réellement. C'est invisible pour un contrôle qui vérifie seulement d'où vient le script.
Un schéma à l'échelle du web
Prenez du recul et la tendance est claire. DefiLlama a enregistré le deuxième trimestre 2026 comme le pire trimestre d'incidents de sécurité crypto qu'il ait jamais documenté, avec environ 74,9 millions de dollars perdus sur 29 exploits rien qu'en juin. L'histoire qui définit la sécurité web en 2026 n'est plus le smart contract bogué ni le serveur non corrigé. C'est la dépendance de confiance qui tourne mal, et le runtime du navigateur où ce défaut se joue.
Les attaquants se diversifient parce que les points d'entrée plus anciens deviennent plus difficiles à ouvrir. À mesure que les défenses au niveau du protocole et du serveur mûrissent, le côté client reste la cible la plus tendre. Il est facile à atteindre et rarement surveillé en temps réel. L'attaque de chaîne d'approvisionnement polyfill[.]io, qui a touché des centaines de milliers de sites via une seule dépendance de confiance, est la même histoire à une bien plus grande échelle.
Comment cside détecte cette classe d'attaque
cside a été conçu précisément pour la surface qu'a utilisée cette attaque. Voici comment elle apparaîtrait à travers notre moteur de détection.
Le comportement, pas seulement l'origine. Nous ne vérifions pas seulement d'où vient un script. Nous observons ce qu'il fait dans le runtime : manipulation du DOM, event listeners, à quelles données il accède et où il les envoie. Le script d'un fournisseur de confiance qui se met soudain à recourir au fournisseur de portefeuille, à demander une approbation de tokens ou à contacter un domaine fraîchement enregistré est exactement le type d'anomalie que nous faisons remonter.
Détection de drift. Les scripts ne restent pas statiques. Une dépendance qui faisait de l'analytics la semaine dernière et qui se met cette semaine à toucher des API de portefeuille et un nouveau domaine déclenche une alerte. Notre IA génère une explication en langage clair de ce qui a changé et pourquoi c'est important, pour que vous n'ayez pas besoin d'un chercheur pour lire un diff de hashs.
Mode Gatekeeper. Notre moteur en edge peut se placer entre les tiers non fiables et vos utilisateurs, en servant le script via un conduit que nous contrôlons, pour les scripts que vous choisissez. Nous conservons une copie de ce qui a réellement été livré, ce qui déjoue l'astuce du « servir une version propre au scanner », et il capture les payloads qui ne se déclenchent que pour des utilisateurs, des géographies ou des sessions spécifiques, le même ciblage « pour certains utilisateurs » observé ici.
Blocage en temps réel, pas seulement des rapports. Les scanners signalent. La CSP bloque avec des données limitées. cside peut bloquer un script selon son comportement observé avant qu'il ne vide un portefeuille ou ne skimme une carte. Un outil qui ne vous informe d'une brèche qu'après coup vous laisse en réaction.
La réponse de Polymarket, contenir l'incident, supprimer la dépendance et rembourser intégralement les utilisateurs affectés, est ce à quoi ressemble une réponse solide après une attaque. L'opportunité pour toute autre plateforme est de faire en sorte qu'il n'y ait jamais d'« après ». La surveillance de l'intégrité du frontend en temps réel n'est pas encore standard sur le web, et des incidents comme celui-ci sont la raison pour laquelle elle devrait l'être.
Polymarket a été frappé côté client, là où les attaques sont les plus faciles à cacher et les plus difficiles à détecter. Si du JavaScript tiers s'exécute sur votre site, et c'est le cas, cette surface est exposée que vous la surveilliez ou non.
Les chiffres et l'attribution ci-dessus reflètent les premiers rapports de Specter, PeckShield et Bubblemaps et sont exacts au 2026-06-26.
Vous voulez voir ce qui s'exécute réellement dans les navigateurs de vos utilisateurs ? Commencez gratuitement ou réservez une démo pour parler avec notre équipe.
