Le compte d'intelligence sur les menaces blockchain Dark Web Informer a révélé cet événement le lendemain sur X. Polymarket a réagi le jour même en affirmant que les données concernées « étaient déjà accessibles via une API publique » et en qualifiant l'événement de « fonctionnalité » plutôt que de fuite. Toutefois, la déclaration officielle n'a pas directement abordé les configurations d'API erronées et les détails d'exploitation de vulnérabilités listés par le pirate.
Le 27 avril, l'attaquant sous pseudonyme « xorcat » a téléchargé sur un forum de criminalité numérique un fichier compressé : un fichier JSON de 8,3 Mo, qui se décompresse en environ 750 Mo, contenant plus de 300 000 enregistrements extraits de Polymarket, cinq scripts d'exploitation de vulnérabilités (PoC) en cours d'utilisation, ainsi qu'un rapport technique.
Réponse du jour de Polymarket. Mais cette réponse n'est pas une apologie ni une investigation classique de gestion de crise, plutôt une réplique presque provocante. Le compte officiel de la plateforme a publié sur X une remarque ironique indiquant que tous les contenus concernés sont accessibles via des points d'accès publics et des données sur chaîne, les qualifiant de « fonctionnalité, pas de vulnérabilité ».
L'événement se transforme en affaire de Rōjinmon : les pirates affirment qu'il s'agit d'une attaque consistant à publier des données sans notification préalable, en pointant spécifiquement plusieurs mauvaises configurations d'API ; la plateforme affirme que tous les contenus étaient déjà publics et qu'aucune information privée n'a été divulguée.
Vecteur d'attaque : « une série de portes non verrouillées »
Selon la description publiée par xorcat sur le forum, l'attaque n'a pas dépendu d'une seule vulnérabilité complexe, mais ressemblait plutôt à une série de portes non verrouillées franchies les unes après les autres. Selon un retour d'expérience de média de cybersécurité The CyberSec Guru, l'attaque a principalement exploité trois types de problèmes : des points de terminaison API non publiés, une contournement de pagination de l'API de trading CLOB (Central Limit Order Book), et une mauvaise configuration CORS (Cross-Origin Resource Sharing).
Le rapport public indique que plusieurs points de terminaison de Polymarket ne nécessitent apparemment aucune authentification. Par exemple, le point de terminaison des commentaires permet une énumération par force brute des profils utilisateurs complets ; le point de terminaison des rapports expose les données d'activité des utilisateurs ; le point de terminaison des abonnés permet à n'importe qui de cartographier l'ensemble du réseau social d'une adresse portefeuille sans se connecter.
Que contiennent plus de 300 000 enregistrements ?
Les publications du forum xorcat ainsi que les rétrospectives de The CyberSec Guru et The Crypto Times montrent que le jeu de données fuité est organisé en trois grandes catégories : utilisateurs, marchés et outils d'attaque (voir la carte de données ci-dessous).
Les 10 000 profils d'utilisateurs côté client contiennent le nom, le pseudonyme, la bio, l'avatar, l'adresse du portefeuille agent et l'adresse du portefeuille sous-jacent. Les 9 000 profils d'abonnés permettent de reconstituer le graphe de relations sociales. Les 4 111 données de commentaires sont toutes associées à des profils d'utilisateurs. Les 1 000 enregistrements de signalements impliquent 58 adresses Ethereum distinctes. Les champs d'ID utilisateur internes tels que createdBy et updatedBy sont également dispersés un peu partout, reconstituant indirectement une partie du profil du compte de la plateforme.
Le côté marché couvre 48 536 marchés provenant du système Polymarket Gamma (avec métadonnées complètes, ID de condition, ID de jeton), plus de 250 000 marchés CLOB actifs (avec adresse du contrat FPMM), 292 événements avec les noms d’utilisateur internes et les adresses de portefeuille des soumetteurs et des arbitres, ainsi que 100 configurations de récompenses avec l’adresse du contrat USDC et le taux de paiement quotidien.
Les adresses de portefeuille sont anonymes sur la chaîne, mais leur anonymat s’effondre dès lors qu’elles sont associées à un nom, un profil ou une photo de profil. Tel est le point de controverse que la réponse de Polymarket n’a pas adressé :
Le fait qu'une donnée soit « publique » et le fait qu'elle protège toujours l'identité de l'utilisateur après agrégation sont deux questions distinctes.
« C’est une fonction, pas une faille » : la réfutation de Polymarket
La réponse publiée par Polymarket le 28 avril sur X ne comprend qu'un seul tweet. La plateforme commence par l'émoticône « 😂 », remet en question le terme « compromis », puis réfute point par point : les données chainées sont par nature auditables publiquement, aucune donnée n'a été « divulguée », les mêmes informations étaient déjà accessibles gratuitement via l'API publique, sans nécessité d'achat payant. L'ensemble de la déclaration se conclut par la qualification : « Il s'agit d'une fonctionnalité, pas d'une faille. »
The Crypto Times souligne que la réponse de Polymarket n'aborde pas directement les accusations techniques spécifiques formulées par le pirate, telles que la mauvaise configuration de l'API, la mauvaise configuration de CORS, les points de terminaison non divulgués et l'absence de limites de débit. La plateforme a fortement réagi sur le point le plus facile à contester — « les données étaient-elles publiques » — mais est restée silencieuse sur la question de sécurité plus fondamentale : « l'attaquant a extrait et regroupé en masse des données via des chemins non prévus ».
Xorcat a également déclaré n'avoir pas notifié Polymarket à l'avance, arguant que la plateforme ne disposait pas de programme de récompense pour les vulnérabilités. Ce point n'a pas été vérifié par un tiers, mais s'il est exact, il révèle un manque potentiel dans la gouvernance proactive de la sécurité de Polymarket : l'absence d'un canal officiel de divulgation responsable pousse les attaquants à publier directement les failles au lieu de les signaler en interne.
Ce n'est pas la première fois que Polymarket est confronté à des problèmes de sécurité.
Revenons à la chronologie : entre août et septembre 2024, plusieurs utilisateurs ayant connecté leur compte Google à Polymarket ont signalé le vol de leurs USDC ; les attaquants ont exploité une fonction proxy du SDK de Magic Labs pour transférer les soldes des utilisateurs vers des adresses de phishing. Le service client de Polymarket a confirmé d’ici la fin septembre au moins cinq attaques similaires.
En novembre 2025, des pirates ont exploité la section commentaires de Polymarket pour publier des liens d'hameçonnage ; après clic, ces liens ont installé des scripts malveillants sur les appareils des utilisateurs, entraînant des pertes totales supérieures à 500 000 dollars américains.
En décembre 2025, une nouvelle vague de comptes a été piratée. Polymarket a confirmé l'événement sur Discord, en l'attribuant à « une vulnérabilité dans un service d'authentification tiers ». Les discussions sur les réseaux sociaux pointent généralement les utilisateurs ayant utilisé la connexion par e-mail de Magic Labs, mais la plateforme n'a pas nommé publiquement le service concerné ni révélé le nombre exact d'utilisateurs affectés ni l'étendue des pertes.
Après chaque événement, la plateforme a réagi à des niveaux variés : en blâmant des fournisseurs tiers, en reconnaissant les problèmes et en promettant de contacter les utilisateurs affectés. Cet événement xorcat constitue la première fois où la réponse complète s'appuie sur l'argument « ces données étaient publiques ». Sur le plan historique, cette réponse ressemble davantage à une lutte pour définir la nature de l'événement qu'à une réponse classique à un incident de sécurité.
Au moment de la rédaction, Polymarket n'a pas fourni de clarification sur la correction des vulnérabilités techniques révélées par xorcat, et le script PoC sur le forum reste téléchargeable par quiconque.
Auteur : Claude, Shenchao TechFlow