Au cœur de l'attaque de chaîne d'approvisionnement côté client de $3M contre Polymarket

En bref : drainer via approbation 1 893 ETH sur Polymarket

• Les contrats étaient intacts : Les smart contracts de Polymarket étaient intacts. La blockchain a fonctionné exactement comme prévu. Le vol s'est produit dans l'onglet du navigateur, via un script fournisseur auquel la plateforme faisait déjà confiance depuis des mois.
• Le vol dans le navigateur : Un fournisseur tiers compromis a injecté un vidangeur de portefeuilles qui a dérobé environ 3 millions de dollars sur moins de 15 portefeuilles, blanchis sous forme d'environ 1 893 ETH via le portefeuille de consolidation 0xe65b1C586757c5510B60F998Eebb14C1eF71E1eD. cside surveille le comportement des scripts et bloque un script de confiance qui se met soudain à demander des approbations de tokens.
• Révoquez les approbations : Si votre dApp ou votre paiement charge du JS tiers, ajoutez une surveillance runtime des scripts ce trimestre. Si vous ne le pouvez pas, révoquez au moins les approbations de portefeuille inutilisées dès aujourd'hui, car c'est ce que chaque enquêteur a conseillé aux utilisateurs de Polymarket.

Peu de temps ? Découvrez le blocage de Magecart et de skimmers dans le navigateur par cside. Elle couvre tout ce qui suit en un seul déploiement.

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.

Indicateurs de compromission (on-chain)

Les enquêteurs on-chain ont retracé les fonds volés jusqu'à un seul portefeuille de consolidation, alimenté par six portefeuilles intermédiaires. Les montants ci-dessous totalisent 1 892,92 ETH, soit le solde consolidé complet. Ces adresses sont contrôlées par l'attaquant et listées comme référence pour les défenseurs ; ce ne sont pas des portefeuilles de victimes.

Portefeuille de consolidation : 0xe65b1C586757c5510B60F998Eebb14C1eF71E1eD

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.

Toute l'attaque s'est déroulée dans la couche d'exécution du navigateur. La couche blockchain et des contrats intelligents n'a jamais été compromise : elle a fonctionné exactement comme prévu, car la signature a été autorisée dans le navigateur :

1. Fournisseur tiers compromis. Une dépendance a été empoisonnée et, selon les termes de Polymarket, servie « pour certains utilisateurs ».
2. Script malveillant injecté dans le frontend de polymarket.com.
3. Interface réelle de Polymarket. Le script a exploité l'UI authentique : l'utilisateur cliquait sur « Connecter le portefeuille », puis le script présentait une demande malveillante d'approbation / de signature ERC-20.
4. L'attaquant balaie le pUSD de la victime une fois l'approbation signée.
5. Transféré de Polygon vers Ethereum, converti en environ 1 893 ETH et blanchi via le portefeuille de consolidation 0xe65b…E1eD.

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 prévenir une attaque de chaîne d'approvisionnement côté client

L'incident Polymarket illustre un schéma répétable. Toute application web qui charge du JavaScript tiers est exposée au même risque. Ces quatre contrôles réduisent le risque dans n'importe quelle stack.

Maintenez un inventaire à jour des scripts. Connaissez chaque dépendance qui s'exécute dans les navigateurs de vos utilisateurs : qui en est propriétaire, à quelles données elle peut accéder et pourquoi elle est là. Il ne s'agit pas d'un audit ponctuel. Les scripts changent. Les fournisseurs ajoutent des sous-dépendances. Du code vérifié et approuvé il y a un an peut charger des comportements très différents aujourd'hui. Le PCI DSS 4.0.1 §6.4.3 exige un inventaire en temps réel pour les pages de paiement précisément parce qu'un script inconnu est un script non surveillé. Commencez par les flux de paiement et les pages d'authentification.

Surveillez ce que les scripts font réellement, pas seulement leur origine. La CSP valide l'origine. Une fois qu'un fournisseur de confiance est compromis, la CSP n'a aucun moyen de détecter que sa balise d'analytics demande maintenant des approbations de portefeuille. Un domaine de confiance n'est pas équivalent à un comportement de confiance. La surveillance au niveau de la couche d'exécution JavaScript, là où les scripts s'exécutent réellement, détecte ce que tout contrôle basé sur l'origine ne peut pas voir : un script qui gérait de l'analytics hier et qui interagit aujourd'hui avec le fournisseur de portefeuille.

Alertez sur le drift de comportement avant qu'une signature soit publiée. Le renseignement sur les menaces est réactif par nature. Un fournisseur compromis ce matin n'apparaîtra sur aucun flux avant que les dégâts ne soient causés. Une détection qui répond au drift de comportement, un script qui contacte de nouveaux domaines externes, accède à de nouvelles API du navigateur ou lit des structures de données qu'il ignorait auparavant, ferme cette fenêtre.

Entraînez-vous au processus de suppression avant d'en avoir besoin. L'équipe de Polymarket a identifié la dépendance compromise, l'a supprimée et s'est engagée à rembourser les utilisateurs affectés. La plupart des équipes n'ont pas pratiqué cette séquence. Savoir quels scripts supprimer et en combien de temps un build propre peut être déployé transforme une compromission de chaîne d'approvisionnement d'une crise de plusieurs jours en un incident maîtrisable.

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 observons ce qu'un script 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 Script. cside fonctionne selon deux modes, le Méthode Script et le Méthode Scan. En Méthode Script, nous observons le comportement de chaque script dans la session en direct de l'utilisateur et nous l'analysons côté serveur sur notre propre infrastructure, puis nous le bloquons dès que le comportement est confirmé comme malveillant, sans avoir besoin d'un proxy. Comme nous observons ce qui s'exécute réellement dans la session, l'astuce du « servir une version propre au scanner » ne sert à rien, et nous détectons 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. 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.