Polymarket et le script d'un prestataire : ce qu'en retiennent les porteurs de risque cyber

Thème de la semaine du 24 au 31 octobre 2026 · par cybercoverinsurance

Le 29 octobre 2026, pendant environ une heure, le site de Polymarket a chargé dans les sessions de ses utilisateurs un script d'un prestataire qui n'était plus l'original. Le script servait à mesurer les performances des pages. Le code substitué a utilisé le client de trading du site lui-même pour transférer des fonds de centaines de comptes vers un portefeuille unique. Les estimations indépendantes font état d'environ 2,7 millions de dollars.

Le montant est faible au regard d'autres événements de la même semaine. Le cas compte pour une autre raison. Le point d'entrée n'était ni un système de l'assuré ni un prestataire critique, mais un outil de supervision que presque aucun questionnaire de souscription ne mentionne. Pour qui porte le risque cyber, la question est de savoir combien de prestataires exécutent du code dans les pages les plus sensibles de leurs assurés, et qui les contrôle.

Ce que l'on sait

L'incident. Polymarket a indiqué qu'un prestataire tiers « a été compromis », que l'affaire a été signalée aux forces de l'ordre et que les utilisateurs touchés seront remboursés. Polymarket n'a donné ni le nom du prestataire ni le montant dérobé (The Record). La société de threat intelligence Hudson Rock a identifié le prestataire : DebugBear, société britannique de supervision des performances web, dont le script de real user monitoring était intégré à polymarket.com. DebugBear a confirmé être touchée par un « incident de sécurité en cours » et a demandé à ses clients de retirer son code de leurs sites (ICOBench).

La chronologie. Selon la reconstitution d'Ohey, le script malveillant a été servi dans les sessions authentifiées à partir d'environ 16 h 54 UTC le 29 octobre. Les premiers fonds sont arrivés sur le portefeuille de destination à 17 h 10 UTC. Polymarket a publié une version du site sans le script à 17 h 59 UTC. DebugBear a annoncé l'incident à 18 h 00 UTC (Ohey). Polymarket a placé la plateforme en mode annulation d'ordres uniquement à 18 h 05 UTC et a rouvert le trading à 19 h 00 UTC (ICOBench). La plateforme touchée est la plateforme internationale (The Record).

Le fonctionnement du code. Hudson Rock a analysé le script. Le code lisait dans le navigateur les données du compte, repérait le client de trading déjà chargé dans la page, vérifiait les soldes et, au-dessus d'un seuil minimal, transférait les positions ou les vendait pour transférer ensuite le produit. Les signatures étaient demandées via le système de signature déjà actif dans la session et envoyées au service de relais de Polymarket. Les auteurs n'ont trouvé aucune routine exportant des clés privées ou des phrases de récupération (Hudson Rock). Ohey relève que toutes les adresses contactées par le script, à l'exception de celles de DebugBear, étaient déjà autorisées par la Content Security Policy de Polymarket.

Les chiffres. Il s'agit d'estimations de tiers, non de données de l'entreprise. Bitquery indique environ 2,73 millions de dollars provenant de 737 comptes entre 17 h 10 et 18 h 10 UTC. GoPlus indique environ 2,71 millions provenant de 731 adresses. La perte médiane par victime est de 171 dollars (ICOBench). Polymarket n'a pas publié de total.

Ce que l'on ne sait pas. La manière dont les attaquants ont atteint l'infrastructure de distribution de DebugBear n'a pas été expliquée (Safestate). On ne sait pas combien d'autres sites chargeaient le même script. Hudson Rock n'a trouvé aucune preuve d'une compromission plus large touchant d'autres clients de DebugBear (The Record). Personne n'a attribué l'attaque.

Le prestataire que personne ne mentionne

Un script de supervision a les mêmes pouvoirs que le code du site. Un navigateur ne distingue pas le code écrit par l'assuré de celui chargé depuis un prestataire. Une fois dans la page, le script tiers lit ce que lit le site et peut demander ce que le site peut demander. Dans le cas Polymarket, il n'a pas été nécessaire de voler des identifiants : le script a utilisé la session déjà ouverte par l'utilisateur.

Les questionnaires regardent ailleurs. Les questions sur la supply chain portent en général sur les prestataires informatiques, cloud et logiciels infogérés. Les outils d'analyse d'audience, tag managers, chats, widgets d'avis et outils de supervision des performances restent en dehors, car ils sont vus comme du marketing ou des outils annexes. C'est précisément la catégorie la moins contrôlée et la plus présente sur les pages de connexion, de paiement et de confirmation.

Un standard existe déjà pour s'en inspirer. Pour les pages de paiement par carte, PCI DSS 4.0 exige un inventaire de tous les scripts avec la justification de chacun, une méthode pour les autoriser et une autre pour garantir leur intégrité (exigence 6.4.3). Il exige aussi un mécanisme qui alerte en cas de modification non autorisée de la page telle que la reçoit le navigateur, au moins tous les sept jours (exigence 11.6.1). Les deux sont obligatoires depuis le 31 mars 2025 (PageCrawl). Polymarket ne traite pas de cartes, mais la logique vaut pour toute page où un utilisateur autorise un transfert de valeur.

Quelle police répond

Le dommage est celui des clients, le remboursement est un choix de l'assuré. Les fonds dérobés appartenaient aux utilisateurs. Polymarket s'est engagée à les rembourser. Pour qui porte le risque, la distinction compte. Les polices cyber couvrent en général une responsabilité établie envers des tiers ou des réclamations, pas les paiements volontaires effectués avant toute réclamation et sans l'accord de l'assureur. Un remboursement spontané, même judicieux pour la réputation, peut rester à la charge de l'assuré si la police ne prévoit pas de garantie spécifique.

La garantie fraude dépend de qui détenait les fonds. Les garanties de fraude informatique des polices fraude supposent généralement une perte d'argent ou de biens de l'assuré, ou détenus pour le compte de tiers. Ici, les fonds se trouvaient dans des portefeuilles des utilisateurs, avec des signatures demandées dans leur propre session. Beaucoup de polices fraude excluent par ailleurs les cryptomonnaies ou ne les couvrent que par des extensions dédiées. L'expert devra établir si Polymarket détenait ces fonds, et sous quelle forme.

Le prestataire a une responsabilité, le contrat la plafonne. DebugBear peut être mise en cause par ses clients. La couverture de référence est la responsabilité civile professionnelle technologique (tech E&O) du prestataire, si elle existe. Mais les contrats SaaS de ce type plafonnent souvent la responsabilité au montant des abonnements annuels. Le recours subrogatoire de l'assureur de Polymarket risque de peser peu.

L'interruption a été brève. Le trading a été suspendu environ une heure. Les franchises en temps des garanties pertes d'exploitation sont généralement de plusieurs heures. Ici, le coût réel tient à la réponse à incident, à l'investigation numérique, aux communications avec les utilisateurs et aux remboursements, pas à l'arrêt.

Cumul : un script, de nombreux sites

Le même fichier peut atteindre des milliers de pages. Un script servi depuis le réseau de diffusion d'un prestataire est chargé par tous les sites qui l'intègrent. Dans le cas DebugBear, les chercheurs n'ont pas trouvé le code malveillant chez d'autres clients, et le code était écrit pour Polymarket. Mais la même position, avec un code générique, aurait pu toucher tous les clients du prestataire au même moment.

C'est un scénario de sinistre à cartographier. Pour un portefeuille, la question n'est pas seulement de savoir quels fournisseurs cloud les assurés partagent. C'est aussi de savoir quels scripts tiers apparaissent en même temps sur les pages de connexion et de paiement de nombreux assurés. Tag managers, outils d'analyse d'audience et plateformes de consentement sont communs à un très grand nombre de sites. Un événement chez l'un de ces prestataires produirait des sinistres corrélés de fraude, de violation de données personnelles et de responsabilité envers les clients.

La donnée est observable de l'extérieur. Contrairement à beaucoup de dépendances internes, les scripts chargés par une page publique sont visibles par quiconque l'ouvre. Un scan externe des pages de connexion et de paiement des proposants peut montrer quels prestataires reviennent dans le portefeuille, avant même le questionnaire.

Contrôles et temps de réaction

La Content Security Policy ne suffit pas seule. Polymarket avait une politique, mais le script a utilisé des adresses déjà autorisées, c'est-à-dire celles du site lui-même (Ohey). Une politique limite l'endroit où le code peut envoyer des données, pas ce qu'il peut faire dans la page.

L'intégrité des fichiers est le contrôle le plus direct. Subresource Integrity bloque un script dont le contenu ne correspond plus à l'empreinte attendue. Hudson Rock la cite parmi les mesures, avec le retrait des scripts tiers inutiles des pages de trading et de signature. La limite est pratique : les prestataires mettent souvent à jour leurs scripts, et l'empreinte doit être mise à jour par un processus contrôlé.

Une heure a suffi. Environ 50 minutes se sont écoulées entre l'arrivée des premiers fonds et le retrait du script (Ohey). La réaction est intervenue en moins d'une heure et n'a pourtant pas évité la perte. Pour des transactions automatiques et irréversibles, ce qui compte, ce sont les contrôles qui agissent avant la signature : limites par session, confirmations supplémentaires pour les opérations inhabituelles, blocage des transferts vers de nouvelles destinations.

Ce qu'il faut apporter aux renouvellements

Ces questions valent pour tout assuré disposant de pages de connexion, de paiement ou d'autorisation de transferts.

Impact pour les assureursMoyen

Le sinistre isolé est resté limité, mais le même vecteur chez un prestataire très répandu produirait des sinistres corrélés dans de nombreux portefeuilles.

Côté portefeuille, le travail utile est une cartographie des fournisseurs de scripts récurrents sur les pages sensibles des assurés. Si trois ou quatre fournisseurs apparaissent dans une grande partie du portefeuille, c'est un cumul à traiter comme celui des grands fournisseurs cloud, avec des scénarios et des limites dédiés.

Sources

• The Record – Polymarket confirme l'attaque contre un prestataire tiers
• ICOBench – estimations des pertes, nombre de comptes et suspension du trading
• Ohey – chronologie de l'attaque et rôle de la Content Security Policy
• Hudson Rock – analyse du code malveillant et recommandations
• Safestate – questions encore ouvertes sur la compromission de DebugBear
• PageCrawl – exigences PCI DSS 4.0 6.4.3 et 11.6.1 sur les scripts des pages de paiement