La violation du 29 octobre de Polymarket a atteint les traders via un fournisseur de site web compromis. Les chercheurs ont trouvé du code qui tentait d'utiliser des comptes connectés pour vendre des positions et déplacer des actifs, exposant la confiance que les traders placent dans l'écran qu'ils utilisent pour gérer leur argent.
Résumé
- Polymarket a confirmé qu'un fournisseur avait été compromis et a rétabli le trading international après une interruption d'une heure.
- Les chercheurs ont lié l'incident à un script de surveillance des performances chargé par le site web.
- Le code récupéré cherchait à accéder au client de trading et au signataire au sein d'une session active.
- Une autre violation chez un fournisseur en juin avait déjà suscité une promesse de remboursement intégral.
- Le dernier engagement de remboursement n'explique pas encore comment les positions vendues seront évaluées.
Un trader utilisant le nom Car a déclaré qu'environ 800 000 $ avaient disparu de son compte Polymarket et que toutes ses positions avaient été vendues. Il a dit qu'il continuait à trader sur un appareil séparé et évitait les liens inconnus.
D'autres traders signalaient des pertes alors que Polymarket restreignait son échange international le 29 octobre. L'entreprise a ensuite confirmé qu'un fournisseur tiers avait été compromis et a promis de rembourser les clients affectés.
Le compte technique émergent pointe vers un logiciel chargé à l'intérieur du véritable site de trading. Les chercheurs en sécurité ont trouvé un script de surveillance qui tentait d'atteindre les outils qu'un trader connecté utilise pour passer des ordres et autoriser des actions de portefeuille.
Pour ces utilisateurs, le danger pouvait arriver par la page qu'ils avaient déjà ouverte pour trader. L'enquête concerne le logiciel fonctionnant à l'intérieur de cette page et les autorisations de compte auxquelles il pouvait accéder.
L'avis d'incident de Polymarket enregistre une interruption de 18h05 à 19h05 UTC. L'entreprise a déclaré avoir corrigé le problème et avoir transmis l'incident aux forces de l'ordre, mais n'a pas publié son enquête complète ni un total final des pertes.
La violation est survenue 4 mois après qu'un autre fournisseur compromis a introduit du code malveillant sur le site web. Polymarket avait également promis des remboursements après cet incident.
Les traders ont signalé des positions vendues avant que Polymarket n'arrête le trading
Un trader utilisant le nom Car a déclaré que son compte avait été vidé d'environ 800 000 $ et qu'un ami avait perdu 600 000 $ de plus. Il a dit que toutes ses positions avaient été vendues.
Dans des publications décrivant l'incident, Car a déclaré qu'il séparait son activité personnelle, le développement de logiciels et le trading sur différents appareils. Il soupçonnait un problème avec le site web de la plateforme parce que d'autres utilisateurs semblaient également avoir été affectés.
Son compte décrivait des pertes subies lors de l'utilisation du service de trading, plutôt qu'un transfert qu'il aurait délibérément approuvé. La déclaration ultérieure de Polymarket a confirmé qu'un fournisseur avait été compromis, bien qu'elle n'ait pas publié de conclusions sur son compte individuel.
Un autre compte, StarPlatinum, a suivi un portefeuille destinataire suspect et a estimé qu'il avait accumulé 2,68 millions de dollars. Le compte a déclaré que le solde avait augmenté pendant environ une heure de retraits.
La chronologie de l'observateur plaçait les premiers reçus vers 17h05 UTC, avant que l'entreprise ne publie sa restriction de service initiale. Il affirmait que le portefeuille détenait 412 000 $ à 17h25 UTC et 2,02 millions de dollars à 17h50 UTC.
Comme crypto.news l'a précédemment rapporté, les premiers signalements de pertes incluaient des allégations selon lesquelles des fonds avaient transité par l'infrastructure de portefeuille de dépôt de Polymarket. Ces descriptions provenaient de traders et d'observateurs de la blockchain alors que l'entreprise enquêtait encore.
L'entreprise a ensuite déclaré avoir corrigé le problème et qu'elle rembourserait les utilisateurs affectés. Elle n'a pas confirmé les montants individuels des pertes ni adopté l'estimation de l'observateur comme sa comptabilité finale.
Une capture d'écran diffusée pendant l'incident montrait une demande de signature de portefeuille associée au domaine Polymarket. Elle affichait un champ de données DepositWallet et l'identifiant de chaîne de Polygon, mais ne montrait pas de transaction complétée ni les détails complets nécessaires pour reconstituer l'activité d'un compte individuel.
Les rapports des utilisateurs incluaient à la fois des actifs transférés hors des comptes et des positions vendues avant que leurs propriétaires n'aient l'intention de les clôturer. Polymarket n'a pas précisé si chaque utilisateur affecté avait subi les deux.
Polymarket a rétabli son service après une interruption d'une heure
Polymarket a d'abord placé la plateforme d'échange en mode annulation uniquement et suspendu les actions du relayer pendant que son équipe enquêtait. Cette restriction permettait aux utilisateurs d'annuler les ordres existants tandis que les nouveaux ordres et les transactions cessaient d'être traités.
À 18h37 UTC, l'entreprise a déclaré avoir identifié et corrigé le problème affectant sa plateforme internationale. Elle a indiqué qu'un fournisseur tiers avait été compromis et que les échanges restaient temporairement suspendus par précaution.
La page de statut a publié une autre mise à jour à 18h55 UTC, indiquant que les échanges reprendraient vers 15 heures, heure de l'Est. L'incident a été marqué comme résolu à 19h05 UTC, soit 15h05, heure d'été de l'Est.
Le message de rétablissement de l'entreprise a réitéré son engagement à rembourser les traders affectés. L'avis n'annonçait pas que tous les remboursements avaient déjà été versés au moment de la reprise des échanges.
Le relayer de Polymarket fait partie de l'infrastructure utilisée pour soumettre des actions de portefeuille signées à la blockchain. La suspension de ces actions accompagnait les restrictions imposées à son carnet d'ordres pendant l'enquête.
Sa documentation sur les échanges décrit un système dans lequel les utilisateurs créent des ordres signés, un opérateur met en relation acheteurs et vendeurs, et des contrats règlent les transactions on-chain. L'avis d'incident d'octobre identifiait l'API Predictions Trading, communément appelée le CLOB, parmi les services affectés.
L'entreprise a continué à publier des mises à jour via son service de statut public au fur et à mesure de l'évolution de la réponse. L'accès aux comptes, les données de marché et l'exécution des ordres y sont répertoriés séparément.
La restriction annoncée le 29 octobre concernait la plateforme internationale. Polymarket n'a pas désigné sa plateforme d'échange américaine distincte comme un lieu affecté dans l'avis d'incident.
Le service a repris alors que l'enquête sur les transactions non autorisées se poursuivait. Les mises à jour publiques n'ont pas nommé d'attaquant ni décrit comment le fournisseur avait été initialement compromis.
Polymarket a signalé l'incident aux autorités du Royaume-Uni, selon sa déclaration et les reportages ultérieurs. DebugBear est basé au Royaume-Uni.
Les enquêteurs ont lié la violation à un script de surveillance
Les produits de DebugBear aident les opérateurs de sites web à mesurer la vitesse de chargement et d'autres aspects de l'expérience des visiteurs. Son service de surveillance des utilisateurs réels utilise du JavaScript intégré dans le site web d'un client.
Le fournisseur a reconnu un incident de sécurité en cours et a conseillé aux clients utilisant ce produit de supprimer son code d'intégration. Reuters a identifié DebugBear comme le fournisseur impliqué dans l'incident Polymarket, citant une personne proche du dossier.
L'avis de statut de Polymarket faisait référence à un fournisseur tiers sans le nommer. L'entreprise a déclaré que le problème avait été corrigé mais n'a pas publié de rapport technique complet avec cette annonce.
La société de sécurité Hudson Rock a examiné un fichier JavaScript servi depuis l'infrastructure de DebugBear. Dans son enquête, les chercheurs ont indiqué que le fichier recherchait dans l'application en cours d'exécution de Polymarket le client de trading et le signataire utilisés par un compte connecté.
La société a déclaré que le code inspectait les soldes et les positions avant de tenter de transférer de la valeur vers un destinataire configuré. Elle a trouvé différents chemins pour transférer les jetons de position et vendre les positions avant de tenter de transférer le produit.
Hudson Rock a indiqué que le code cherchait à réutiliser l'accès disponible au sein d'une session authentifiée. Son examen n'a pas identifié de routine qui envoyait une phrase de récupération, un mot de passe ou une clé privée au point de terminaison de rapport du script.
Les chercheurs ont trouvé une référence à la suppression de l'intégration DebugBear dans les métadonnées de build de production de Polymarket. Ils ont déclaré que cette entrée corroborait la suppression de l'intégration, tout en laissant non résolue la période exacte d'exposition des utilisateurs.
BleepingComputer a examiné séparément une copie du script et décrit des tentatives d'utilisation des sessions de trading existantes pour passer des ordres et transférer des actifs. Son examen de la blockchain a suivi environ 28,6 millions de POL depuis le destinataire suspecté vers trois portefeuilles supplémentaires.
La publication a évalué ce mouvement à environ 2,57 millions de dollars au moment de son examen. Hudson Rock a cité un instantané distinct du solde du destinataire proche de 2,19 millions de dollars, tandis que d'autres observateurs ont rapporté des totaux proches de 2,7 millions de dollars.
Polymarket n'a pas réconcilié ces estimations dans un état des pertes de l'entreprise. Les rapports ont utilisé différentes observations et moments de valorisation au cours d'une enquête encore en cours.
Aucune des mises à jour publiques de l'entreprise n'a identifié la personne contrôlant le portefeuille destinataire. La compromission du fournisseur, les rapports de trading non autorisé et les transferts subséquents restent les sujets de l'enquête transmise aux forces de l'ordre.
La promesse de remboursement inclut les traders dont les positions ont été vendues
Polymarket a déclaré que les utilisateurs affectés seraient indemnisés et a réitéré qu'elle remboursait intégralement les traders après le retour du service. La déclaration n'a pas fixé de délai pour soumettre des réclamations ni exigé que chaque client retire ses fonds dans une période particulière.
L'entreprise n'a pas publié de politique de remboursement détaillée pour l'incident d'octobre. Elle n'a pas encore indiqué si les paiements seront automatiques dans tous les cas ou si certains utilisateurs devront fournir des informations sur une activité contestée.
Le rapport de Car selon lequel ses positions ont été vendues soulève une question au-delà d'un solde de portefeuille manquant. Un trader peut détenir des contrats sur un événement qui ne s'est pas encore produit, les vendre avant la résolution ou les conserver jusqu'à ce que le résultat soit déterminé.
La documentation sur les positions de Polymarket décrit les avoirs Oui et Non séparément du collatéral utilisé pour les acheter. Un ensemble complet est garanti par 1 pUSD, tandis que le paiement final d'un résultat individuel dépend du résultat enregistré.
Les règles de la plateforme permettent aux traders de vendre des positions avant la résolution. Lorsqu'une vente non autorisée se produit, l'historique de trading du compte peut enregistrer à la fois les contrats retirés et les produits reçus avant tout retrait ultérieur.
Polymarket n'a pas précisé si elle restaurera les contrats vendus, indemnisera les clients en utilisant un prix de marché particulier ou appliquera une autre méthode. Sa promesse publique couvre les traders affectés sans préciser comment chaque type d'activité de compte sera traité.
La documentation sur les ordres de la plateforme enregistre les étapes entre la soumission d'un ordre et la confirmation d'une transaction réglée. Les ordres peuvent rester ouverts, être appariés avec un autre trader, expirer ou ne pas être réglés.
L'entreprise peut s'appuyer à la fois sur les registres de trading et de blockchain lors de l'examen d'une activité contestée. Les rapports des utilisateurs concernant des ventes non désirées portent sur l'historique des ordres, tandis que les transferts hors du portefeuille laissent un enregistrement de transaction distinct.
Aucun calendrier de paiement à l'échelle de l'entreprise n'est apparu dans l'avis de rétablissement. La déclaration de l'entreprise n'a pas demandé aux clients de payer des frais de récupération ni de divulguer des identifiants de récupération de portefeuille pour obtenir un remboursement.
La violation de juin a conduit à une promesse antérieure de remboursements complets
La promesse de remboursement antérieure de l'entreprise a suivi une estimation de l'analyste blockchain Specter selon laquelle au moins 11 portefeuilles avaient perdu environ 2,94 millions de dollars. L'analyste a décrit des utilisateurs détenant des PUSD dont les actifs ont ensuite été convertis en ETH.
Specter a qualifié l'incident d'hameçonnage via l'interface affectée. La divulgation de l'entreprise a identifié un fournisseur compromis comme la voie par laquelle le script avait atteint certains utilisateurs.
AMLBot a ensuite porté les pertes estimées de juin à 3,1 millions de dollars. Son compte du 27 juin a décrit des PUSD pris sur Polygon, convertis via Relay, pontés vers Ethereum et échangés contre des ETH.
L'engagement de Polymarket en juin était de rembourser intégralement les utilisateurs affectés. La déclaration d'octobre de l'entreprise a formulé une nouvelle promesse de remboursement concernant le dernier incident.
L'entreprise n'a pas déclaré que les deux violations impliquaient le même fournisseur ou attaquant. La divulgation de juin et l'enquête d'octobre concernent toutes deux des logiciels externes utilisés par la plateforme, mais elles décrivent des événements distincts à quatre mois d'intervalle.
L'incident précédent s'est produit alors que Polymarket étendait l'utilisation de PUSD à travers son infrastructure de trading. Sa déclaration de juin concernait les utilisateurs affectés par le script malveillant, sans annoncer la suspension de chaque marché proposé sous la marque Polymarket.
La réponse d'octobre incluait à nouveau la suppression ou la correction de l'intégration compromise et la restriction de l'activité pendant que l'équipe enquêtait. Les détails techniques et les totaux de victimes publiés dans chaque cas ont suivi des calendriers différents.
Les rapports de juin n'ont pas fourni de compte transaction par transaction montrant l'achèvement de chaque remboursement. L'avis le plus récent de Polymarket ne publie pas non plus de liste des remboursements d'octobre effectués.
Les chercheurs ont examiné le logiciel s'exécutant à l'intérieur de la page de trading
L'enquête s'est concentrée sur le code chargé par un site web que les utilisateurs connaissaient déjà. Le compte rendu de Hudson Rock décrivait des tentatives de localiser le client de trading au sein de l'application en cours d'exécution, plutôt qu'une instruction demandant aux utilisateurs de se rendre sur une plateforme d'échange portant une marque distincte.
La documentation des navigateurs maintenue par Mozilla explique que le JavaScript inclus directement dans une page peut accéder à d'autres scripts et données au sein de cette page. Un script de surveillance chargé de cette manière s'exécute avec un accès différent de celui du contenu isolé dans un cadre séparé.
Les opérateurs de sites web utilisent de telles intégrations pour l'analyse, le signalement d'erreurs et la mesure des performances. DebugBear décrit son produit de surveillance des utilisateurs réels comme collectant des informations sur la façon dont les visiteurs font l'expérience d'un site web.
L'interface de trading de Polymarket effectue un ensemble de tâches différent, notamment l'affichage des positions, la préparation des ordres et l'interaction avec un signataire. Les chercheurs ont déclaré que le fichier récupéré contenait une logique dirigée vers ces fonctions de trading.
La documentation sur les portefeuilles de Polymarket décrit plusieurs types de comptes, notamment les Deposit Wallets et les portefeuilles hérités Proxy et Safe. Sa documentation attribue les Deposit Wallets aux comptes déployés le 4 mai 2026 ou après cette date.
La plateforme permet au propriétaire d'un portefeuille d'autoriser un signataire distinct pour une activité de trading spécifiée. Sa documentation bêta sur les clés de session indique qu'une telle clé peut trader pour un Deposit Wallet mais ne peut pas retirer ses fonds.
L'entreprise n'a pas identifié les clés de session comme la cause de la violation d'octobre. Le compte rendu des chercheurs décrit des tentatives d'utiliser le client et le signataire déjà disponibles dans l'application.
Le guide des ordres de Polymarket indique que les utilisateurs signent des messages structurés contenant l'identifiant de résultat de la transaction, le côté, le prix, la taille et d'autres conditions. L'opérateur valide les signatures, les soldes et les autorisations avant de faire correspondre un ordre.
Les transactions appariées passent ensuite aux contrats de règlement, la plateforme enregistrant si l'exécution a été confirmée ou a échoué. L'avis de statut d'octobre n'a pas signalé de défaillance du consensus Polygon ni annoncé que chaque contrat de règlement avait été compromis.
La réponse publique de l'entreprise a jusqu'à présent identifié la compromission du fournisseur et promis une compensation sans publier un compte rendu complet de chaque chemin de signature et de transfert.
Les protections du navigateur dépendent du code auquel le site web fait confiance
Un site web peut charger le logiciel d'un fournisseur sans envoyer le visiteur à une autre adresse. Le navigateur récupère le fichier dans le cadre de l'ouverture de la page, aux côtés du code applicatif de la plateforme d'échange elle-même.
La documentation du navigateur de Mozilla explique qu'un script intégré directement dans une page peut fonctionner avec l'accès de la page. Le rôle commercial du fournisseur en tant que moniteur de performance n'impose pas en soi une restriction du navigateur qui confine son code à la mesure des temps de chargement.
Le contenu placé dans un cadre isolé séparément a des limites différentes. Un script inclus dans l'application de trading n'acquiert pas cette isolation simplement parce qu'une autre entreprise le fournit.
L'enquête d'octobre place cette distinction à l'intérieur d'une application financière. La page de Polymarket affiche les soldes et les positions tout en se connectant à des services qui préparent les ordres et demandent des signatures.
L'entreprise n'a pas publié d'inventaire complet du code externe autorisé à s'exécuter dans cet environnement. Sa déclaration sur l'incident identifie une compromission du fournisseur sans décrire l'examen des autorisations qui a précédé l'intégration.
Les navigateurs fournissent des contrôles destinés à limiter cette exposition. La documentation sur l'Intégrité des sous-ressources de Mozilla décrit une méthode pour vérifier un script téléchargé par rapport à une empreinte cryptographique spécifiée par le site web.
Si le fichier téléchargé diffère de l'empreinte attendue, le navigateur refuse de l'exécuter. Un fournisseur modifiant le fichier nécessiterait donc que le site web approuve la nouvelle version avant qu'elle puisse s'exécuter sous ce contrôle.
La protection dépend du déploiement par le site web pour la ressource concernée. L'avis de Polymarket ne précise pas si l'intégration affectée utilisait un tel contrôle ni ne publie de conclusions sur les raisons pour lesquelles le code récupéré a été accepté.
Les recommandations sur la Politique de sécurité du contenu de Mozilla décrivent un autre ensemble de contrôles sur les scripts exécutables. Une politique peut restreindre les sources ou autoriser un code particulier à l'aide de nonces et de hachages.
L'autorisation pour l'hôte d'un fournisseur ne vérifie pas en soi chaque fichier que cet hôte sert. Un hôte peut rester le même tandis que le contenu qui en est livré change.
Ces contrôles opèrent avant ou au moment où le code s'exécute dans le navigateur. Ils servent un objectif différent de la surveillance des échanges qui examine les ordres après qu'un client de trading les a soumis.
L'autorité de trading et l'autorité de retrait ont des limites différentes
La documentation de Polymarket décrit les efforts visant à limiter ce qu'un signataire délégué peut faire. Son système bêta de clés de session permet au propriétaire d'un portefeuille d'autoriser une clé distincte pour le trading dans des limites spécifiées.
La documentation indique qu'une clé de session ne peut pas retirer de fonds. Ses permissions peuvent couvrir le carnet d'ordres central, les transactions combinées ou les plateformes de trading prises en charge, et le propriétaire accorde l'autorisation pour une période définie.
Une permission de trading permet encore une activité qui modifie un portefeuille. La distinction importe pour les clients signalant des positions vendues sans leur consentement, même avant que tout produit ne quitte le portefeuille.
Polymarket n'a pas identifié le système bêta de clés de session comme le point d'entrée en octobre. Les chercheurs ont décrit des tentatives pour localiser le client actif et le signataire disponibles pour l'application, tandis que l'entreprise n'a pas encore expliqué quelles permissions ont été utilisées avec succès dans chaque compte affecté.
Le guide du cycle de vie des ordres de la plateforme décrit des ordres signés hors chaîne avant qu'un opérateur ne les valide et ne les apparie. Les contrôles couvrent la signature, les soldes de compte et les autorisations, entre autres conditions.
Le règlement s'effectue ensuite par des contrats blockchain. Les enregistrements distinguent un ordre apparié d'un ordre dont le règlement a été confirmé ou a échoué.
Une signature valide fait partie de ce processus, mais elle n'établit pas que la personne regardant l'écran voulait la transaction. L'attaque signalée cherchait à utiliser l'autorisation disponible via l'application qui prépare ces requêtes.
Les conclusions publiques n'établissent pas que tous les types de portefeuilles permettaient une signature silencieuse ni que chaque action tentée a réussi. Polymarket prend en charge plusieurs configurations de portefeuilles, et son enquête interne n'a pas encore associé les comptes affectés à ces configurations.
L'incident de juin de l'entreprise avait déjà exposé une dépendance similaire au code de sites web externes. Sa précédente faille frontend impliquait un script malveillant livré à certains visiteurs via une dépendance compromise.
La réponse d'octobre a de nouveau nécessité une action au niveau de la plateforme : une restriction de trading, la suspension des actions du relayer et un correctif pour l'intégration affectée. Les appareils de trading distincts des clients ne leur donnaient pas le contrôle sur le logiciel que le site web choisissait de charger.
Les remboursements doivent traiter les transactions ainsi que les liquidités manquantes
Polymarket a promis de dédommager intégralement les utilisateurs affectés, mais son avis de statut n'explique pas comment elle évaluera les positions clôturées sans l'approbation de leurs propriétaires. Restaurer un solde de trésorerie et restaurer une position ouverte sur un événement peuvent produire des avoirs de compte différents.
Un trader dont les contrats ont été vendus pouvait avoir l'intention de les conserver jusqu'à la résolution d'un résultat électoral ou d'un autre événement. Les registres de vente montrent ce que les contrats ont rapporté à ce moment-là, tandis que leur valeur marchande ultérieure peut changer avant le remboursement.
L'entreprise n'a pas précisé si elle remplacera les contrats, utilisera le prix immédiatement avant la vente contestée ou appliquera une autre méthode d'évaluation. Elle n'a pas annoncé que les utilisateurs doivent attendre la résolution des événements sous-jacents.
Les registres de trading et l'historique du portefeuille de Polymarket fournissent des parties distinctes de ce compte. L'historique des ordres enregistre les changements de positions, tandis que les registres de la blockchain peuvent montrer les transferts ultérieurs de garanties ou de jetons.
Le solde d'un portefeuille destinataire ne peut à lui seul identifier la perte de chaque client. Les réclamations individuelles peuvent impliquer une série de transactions, de transferts et de mouvements ultérieurs via d'autres adresses.
L'enquête antérieure de juin a suivi les actifs depuis Polygon via un pont et jusqu'à l'ETH sur Ethereum. Son estimation révisée des pertes a augmenté après l'annonce initiale de remboursement, à mesure que les analystes traçaient davantage d'activité.
Polymarket n'a pas publié de date limite de réclamation pour octobre ni de calendrier de paiements. Son service d'assistance international reste distinct de la bourse américaine, que l'avis d'incident n'a pas identifiée comme affectée.
La plateforme a rétabli le trading à 19h05 UTC le 29 octobre. Son avis public enregistre l'incident de service comme résolu tout en conservant l'engagement d'indemniser les clients affectés.
Points à surveiller
Constats techniques : Quelles autorisations de compte le script a effectivement utilisées, et quels types de portefeuilles ont été affectés.
Contrôles des fournisseurs : Les conclusions de l'entreprise sur la manière dont un logiciel externe a atteint l'application de trading.
Comptabilisation des pertes : Un total de l'entreprise qui concilie les comptes affectés et les transactions non autorisées.
Conditions de remboursement : Comment Polymarket évalue les positions vendues et quand les clients reçoivent une indemnisation.
FAQ
Que s'est-il passé sur Polymarket le 29 octobre ?
Polymarket a déclaré qu'un fournisseur tiers avait été compromis et avait temporairement restreint sa plateforme internationale. Les échanges ont repris après un incident de service d'une heure.
Combien les traders ont-ils perdu ?
Un observateur a estimé 2,68 millions de dollars, et d'autres rapports de traçage ont produit des chiffres proches de 2,7 millions de dollars. Polymarket n'a pas annoncé de perte totale finale ni confirmé le nombre de comptes affectés.
Polymarket a-t-il promis de rembourser les utilisateurs ?
Oui. L'entreprise a déclaré que les traders affectés par l'incident du 29 octobre seraient indemnisés et a réitéré son engagement de remboursement lors de la reprise des échanges.
Qu'ont rapporté les traders affectés ?
Un trader utilisant le nom Car a déclaré qu'environ 800 000 dollars avaient été pris et que toutes ses positions avaient été vendues. Il a indiqué qu'un ami avait perdu 600 000 dollars supplémentaires, bien que Polymarket n'ait pas confirmé ces déclarations individuelles.
Quel fournisseur a été lié à la violation ?
Des reportages et des chercheurs en sécurité ont lié l'incident au script de surveillance de DebugBear. La déclaration de statut du 29 octobre de Polymarket a confirmé un fournisseur compromis sans le nommer.
S'agissait-il de la même violation que celle de juin ?
Non. La divulgation du 25 juin concernait un incident distinct chez un fournisseur, avec des pertes ensuite estimées à 3,1 millions de dollars. L'entreprise n'a pas annoncé d'attaquant ou de fournisseur commun entre les deux affaires.
L'avis indiquait-il que Polymarket US était affecté ?
Non. L'avis d'incident du 29 octobre mentionne la plateforme internationale, tandis que la bourse américaine fonctionne séparément.
Qu'advient-il des positions vendues sans l'approbation du propriétaire ?
Polymarket n'a pas publié de méthode d'indemnisation pour les positions vendues dans sa déclaration du 29 octobre. Son engagement est d'indemniser les traders affectés. Il s'agit d'une analyse éducative, et non d'un conseil en investissement.
