Piratage Mexc : 340 000 Dollars Volés Via Une Api

On croit souvent qu’un compte d’exchange, une fois « récupéré », est de nouveau un coffre. L’affaire relaté ce 28 septembre 2026 raconte exactement l’inverse. Un utilisateur, Shuang Fei, affirme que 322 110 USDT et plus de neuf millions de tokens ONE ont quitté son compte MEXC en treize minutes, pour une valeur d’environ 340 000 dollars. L’exchange a ensuite déclaré avoir « trouvé un accord » et considérer le dossier « pleinement résolu ». Les termes, eux, n’ont pas été publiés. Entre un reset d’e-mail contesté, un gel de compte, une restriction de retrait de vingt-quatre heures et une API créée par l’attaquant, le récit laisse une question qui ne cesse de revenir : comment l’argent a-t-il pu sortir alors que, sur le papier, les clés API associées à un compte gelé doivent être invalidées ?

Ce Que Révèle L’Affaire Du Compte MEXC

Le dossier n’est pas un simple fait divers de plateforme. Il met en tension trois couches que les traders confondent trop souvent : l’identité du compte, les sessions de connexion, et les permissions machine que représente une clé API. Quand ces trois couches ne sont pas synchronisées, un utilisateur peut croire avoir repris la main alors qu’un canal parallèle reste ouvert. C’est précisément le scénario que décrit la victime.

MEXC n’a pas confirmé publiquement que les retraits ont été déclenchés par cette API. L’exchange n’a pas non plus précisé si l’utilisateur a été indemnisé. Il s’est borné à invoquer la vie privée. Ce silence, juridiquement défendable, nourrit pourtant une lecture plus large : dans l’industrie des plateformes centralisées, la communication de crise reste souvent plus courte que la chaîne technique qui a permis le vol.

Une chronologie serrée, presque chirurgicale

Selon le récit publié par Shuang Fei, tout commence tôt le 25 septembre. À 03 h 10, heure de Pékin, un e-mail annonce qu’une demande a été déposée pour changer l’adresse liée au compte et retirer Google Authenticator. Dix minutes plus tard, la demande est validée. L’utilisateur affirme n’avoir jamais fourni la photo d’identité ni la vidéo de vérification. Il estime que les pièces présentées n’étaient pas les siennes.

Une fois le compte sous contrôle adverse, le mot de passe change. Un nouvel authentificateur est associé. Les journaux de connexion indiquent une adresse IP rattachée à Jakarta. À 05 h 05 et 42 secondes, une API est créée. L’utilisateur dit n’avoir appris l’existence de cette clé qu’après le départ des fonds. Ce détail n’est pas anecdotique : une API peut opérer sans nouvelle session visible dans l’historique de login, exactement comme le décrit la victime pour la matinée du 27.

Le 25, vers 10 h 55, MEXC gèle le compte après avoir détecté un risque lors d’une revue. L’e-mail d’origine est rétabli. Le 26, Shuang Fei retire l’authentificateur de l’attaquant, change encore le mot de passe et relie un nouvel appareil. La dernière opération de sécurité se termine à 03 h 45 le 26. La documentation de la plateforme prévoit alors un blocage des retraits crypto et fiat pendant vingt-quatre heures après certains changements sensibles.

Le 27, à 04 h 12 et 45 secondes, soit environ vingt-sept minutes après la fin de ce verrou, un premier transfert d’1 USDT part. Cinq autres sorties suivent. Au total : 322 110 USDT et 9 133 999 ONE. Aucune nouvelle connexion n’apparaît dans l’historique au moment des mouvements, selon l’utilisateur. CertiK et Lookonchain ont repris ces allégations sans prétendre avoir démontré eux-mêmes le vecteur exact.

Le point de friction : une API censée mourir avec le gel

Un guide interne de MEXC, cité dans les échanges publics, indique qu’un compte gelé désactive trading et connexion, et rend invalides toutes les clés API associées. Shuang Fei pose donc la question la plus embarrassante du dossier : cette API est-elle devenue caduque au moment du gel ? Est-elle « revenue à la vie » après restauration ? L’exchange n’a pas répondu publiquement sur ce point technique.

MEXC a confirmé que mon compte avait été volé, l’a gelé, m’a aidé à le récupérer — et a laissé de côté l’API laissée par l’attaquant. Vingt-sept minutes après la fin de la restriction de 24 heures, 340 000 dollars d’actifs ont été vidés.

Shuang Fei, récit public du 28 septembre 2026

Cette phrase, largement reprise, résume le sentiment d’inachèvement. Récupérer un compte ne consiste pas seulement à changer un mot de passe. Cela consiste à auditer tous les jetons d’accès : sessions web, applications mobiles, clés API, adresses de retrait autorisées, webhooks, sous-comptes, éventuels dispositifs de trading automatisé. Omettre une seule de ces portes, c’est laisser un double des clés sous le paillasson.

Pourquoi les API d’exchange sont un angle mort

Une clé API n’est pas un login. C’est une paire d’identifiants machine, souvent accompagnée de permissions granulaires : lecture seule, trading, transfert interne, retrait. Sur de nombreuses plateformes, une API correctement permissionnée peut initier un retrait sans qu’un humain ouvre le site. Si la whitelist d’adresses n’est pas activée, la destination peut être n’importe quel wallet.

MEXC avait indiqué dès 2023 que les listes blanches de retrait pour API n’étaient pas activées par défaut. L’utilisateur devait les allumer lui-même. La documentation actuelle distingue aussi les retraits « normaux », qui peuvent exiger e-mail, mobile ou Google Authenticator, et certains réglages permettant des sorties sous conditions sans répétition du second facteur. Dans un scénario d’account takeover, l’attaquant qui crée l’API après avoir changé l’e-mail peut aussi faire en sorte que le titulaire légitime ne reçoive aucune alerte.

C’est exactement ce que décrit Shuang Fei : l’API n’apparaissait pas dans l’historique des opérations de sécurité auquel il avait accès, et aucune notification n’est arrivée parce que la boîte mail du compte n’était déjà plus la sienne au moment de la création. Demander l’IP de création, le périmètre de permissions, le canal des six retraits et le statut de la clé pendant le gel n’est donc pas de la curiosité. C’est le minimum d’une enquête contradictoire.

Ce que MEXC a dit — et ce qu’il n’a pas dit

Après une première enquête, l’exchange aurait proposé « des solutions correspondantes », selon des relais antérieurs. Puis le support a indiqué avoir contacté l’utilisateur et « réussi à parvenir à un accord ». Le dossier serait « pleinement résolu ». Aucun montant, aucune admission de faille, aucune confirmation de remboursement. La vie privée sert d’écran. Elle protège aussi, par ricochet, la plateforme d’un précédent chiffré.

Ce mode de communication n’est pas unique à MEXC. Beaucoup d’exchanges tranchent les litiges individuels par transaction confidentielle. Pour le marché, le résultat est ambivalent : la victime peut obtenir une issue, mais la leçon collective reste floue. Les autres clients ne savent pas s’il fallait craindre une faille produit, une erreur humaine de revue KYC, un oubli opérationnel après gel, ou une combinaison des trois.

Un reset de sécurité n’est pas un détail administratif

Changer l’e-mail lié et retirer Google Authenticator, c’est changer les fondations du compte. La documentation actuelle de MEXC prévoit que l’utilisateur puisse devoir fournir des informations de compte, des documents d’identité et une vidéo le montrant avec sa pièce. Dans l’affaire, l’exchange aurait d’abord estimé que le dossier « répondait aux exigences », avant de détecter un risque lors d’une revue ultérieure. Ce décalage entre validation initiale et alerte tardive est le cœur du premier échec.

Les attaques d’account takeover sur exchanges suivent souvent le même schéma : social engineering, fuite de données personnelles, deepfake vidéo, ou reprise d’une session déjà compromise. Ici, l’utilisateur insiste sur le caractère non authentique des documents. Qu’il s’agisse d’une usurpation documentaire sophistiquée ou d’une revue trop rapide, le résultat est identique : dix minutes ont suffi pour basculer le contrôle.

Une fois ce basculement obtenu, l’attaquant n’a pas besoin de rester connecté en permanence. Il lui suffit de poser une API, éventuellement avec droit de retrait, puis de disparaître de l’interface. Le titulaire légitime revient, « nettoie » ce qu’il voit — mot de passe, authentificateur — et croit le chapitre clos. Le canal machine, lui, attend la fin du lock de 24 heures.

Le verrou de 24 heures, utile mais insuffisant

Les délais de sécurité après modification d’e-mail ou d’authentificateur existent pour une raison simple : donner au titulaire légitime le temps de réagir. Dans ce dossier, le verrou a fonctionné… jusqu’à son expiration. Vingt-sept minutes plus tard, les sorties commencent par un micro-transfert d’1 USDT, classique test de canal, puis l’essentiel part.

Un verrou temporel ne remplace pas un inventaire d’accès. Tant que la plateforme ne force pas, après un takeover avéré, la révocation explicite et journalisée de toutes les API, le calendrier de 24 heures n’est qu’une fenêtre. L’attaquant n’a qu’à attendre. C’est froid, mais c’est rationnel.

On peut même soutenir que le premier transfert d’1 USDT aurait dû, à lui seul, déclencher une alerte de second niveau : montant atypique, rythme serré, absence de session interactive, historique de gel récent. Les systèmes de surveillance comportementale des exchanges modernes sont censés croiser ces signaux. S’ils l’ont fait, le public n’en a pas la trace. S’ils ne l’ont pas fait, c’est un autre angle mort.

Le précédent des fonds gelés et la communication MEXC

L’épisode s’inscrit dans une mémoire déjà chargée. En 2025, MEXC avait restitué des fonds après un autre conflit très médiatisé, impliquant le trader The White Whale et environ 3,15 millions de dollars gelés. En mai 2026, la plateforme a mis en avant l’expansion prévue d’un Guardian Fund à 500 millions de dollars. Ces signaux de « protection utilisateur » coexistent désormais avec un nouveau dossier où la résolution se dit complète, mais reste opaque.

Pour un exchange, promettre un fonds de garantie et régler un litige en privé ne sont pas contradictoires. Cela dessine toutefois une doctrine : on communique fort sur les dispositifs généraux, on communique peu sur les cas individuels. Les clients sophistiqués le savent. Les autres découvrent la règle au moment où leur solde bascule.

Comment lire les relais CertiK et Lookonchain

CertiK a relayé le récit de l’utilisateur, y compris l’allégation d’une API encore disponible et liée aux retraits. Le service a pris soin de ne pas présenter cette version comme une attribution forensique indépendante. Lookonchain a souligné l’absence de nouvelle activité de login pendant la fenêtre des sorties. Ces deux relais comptent, non parce qu’ils « prouvent » le mode opératoire, mais parce qu’ils transforment un thread personnel en objet de place de marché.

Dans la crypto, la première bataille après un vol n’est pas seulement technique. Elle est narrative. Celui qui fixe le cadre — takeover, API orpheline, lock expiré — oriente la lecture des tiers. MEXC, en répondant par la formule de l’accord confidentiel, laisse ce cadre largement intact.

Ce que les traders devraient vérifier dès ce soir

On peut tirer de l’affaire une check-list prosaïque, sans attendre que l’exchange publie un post-mortem. Elle ne remplace pas un audit interne. Elle réduit toutefois la surface laissée à un attaquant qui n’aurait que quelques minutes d’accès.

• Inventaire des API : lister, dater, restreindre, supprimer tout ce qui n’est pas indispensable.
• Whitelist de retrait : l’activer, même si la plateforme ne l’impose pas par défaut.
• Permissions minimales : lecture ou trading sans retrait dès que c’est possible.
• Alertes hors bande : une adresse e-mail et un numéro que l’attaquant ne peut pas tous deux basculer en dix minutes.
• Journal de sécurité : vérifier qu’une création d’API y apparaît réellement, et signaler le contraire.
• Après un gel : exiger la confirmation écrite que toutes les clés ont été révoquées, pas seulement « invalidées » en théorie.

Ces gestes paraissent évidents. Ils ne le sont pas dans la pratique quotidienne. Beaucoup de traders créent une API pour un bot, un tableur ou un agrégateur, puis l’oublient pendant des mois. L’oubli devient une porte. L’affaire MEXC n’invente pas cette porte. Elle rappelle qu’elle peut rester ouverte après que l’on a changé la serrure visible.

KYC vidéo, deepfakes et course à l’armement

Si les documents et la vidéo du reset n’étaient pas ceux du titulaire, le dossier rejoint une tendance plus large : la fraude d’identité assistée par outils génératifs. Les équipes de conformité des exchanges doivent désormais départager, parfois en quelques minutes, une vidéo authentique d’une synthèse convaincante. Dire cela n’excuse personne. Cela décrit une contrainte réelle.

Une revue trop souple ouvre la porte au takeover. Une revue trop lente bloque le client légitime qui a perdu son téléphone. Les plateformes oscillent entre ces deux erreurs. Ici, la première validation aurait été trop accommodante, la seconde revue plus tardive. Entre les deux, l’attaquant a eu le temps de poser son infrastructure : mot de passe, authentificateur, API.

À moyen terme, les exchanges qui s’en sortiront le mieux ne seront pas seulement ceux qui promettent un fonds de 500 millions. Ce seront ceux qui traitent un reset d’e-mail comme un événement de sécurité de premier rang : double validation asynchrone, délai incompressible plus long, révocation automatique de toutes les API, notification sur tous les canaux encore sains, et revue humaine renforcée dès qu’un changement d’e-mail coïncide avec une création de clé.

Custody centralisée : la confiance reste un produit

Laisser 340 000 dollars sur un exchange, c’est déléguer à la fois la garde et le contrôle d’accès. Le slogan « not your keys, not your coins » n’est pas une morale. C’est une description de responsabilité. Quand la plateforme se trompe, ou quand sa procédure laisse un résidu d’accès, le client découvre qu’il n’était pas copropriétaire d’un protocole. Il était créancier d’un service.

Cela ne signifie pas que tout le monde doit tout retirer demain matin. Les marchés, le listing, les paires, la liquidité, les cartes, le trading intra-journée rendent les comptes d’exchange utiles. Cela signifie que le solde de long terme et le solde opérationnel ne devraient plus cohabiter sans friction. Un compte de trading avec peu d’API et une whitelist n’est pas la même chose qu’un coffre-fort improvisé.

Un compte récupéré n’est pas un compte assaini tant que chaque clé machine n’a pas été explicitement tuée.

Principe opérationnel que ce dossier rend visible

La formule est sèche. Elle a le mérite d’être actionnable. Après n’importe quel incident — e-mail suspect, connexion à Jakarta ou ailleurs, reset non reconnu — la première tâche n’est pas de « se rassurer parce que le support a gelé ». La première tâche est de demander la liste exhaustive des accès encore valides, horodatée, et de la faire invalider une à une.

Pourquoi l’absence de login ne rassure personne

Beaucoup d’utilisateurs consultent l’historique de connexion comme on consulte un journal de bord. Pas de nouvelle ligne, pas d’intrus. Les API cassent cette intuition. Une requête signée n’est pas une session navigateur. Elle peut n’apparaître que dans des journaux d’API que le client ne voit pas, ou voit mal. D’où l’insistance de Shuang Fei : pas de login frais pendant les retraits, donc un autre canal.

Si MEXC confirme un jour que le canal était bien l’API, le dossier deviendra un cas d’école pour les équipes produit. Si l’exchange révèle un autre vecteur — script interne, faille de session, confusion de sous-compte — le récit public devra être corrigé. Pour l’instant, le vide officiel laisse la version de l’utilisateur occuper tout l’espace.

L’enjeu des tokens ONE et de la valorisation

Le montant avancé, environ 340 000 dollars, agrège 322 110 USDT, relativement stables, et 9 133 999 ONE, dont la valeur fluctue. Cette composition n’est pas neutre. Un stablecoin sorti vers un mixer ou un pont devient vite difficile à suivre. Un altcoin massivement déplacé peut laisser une trace on-chain plus lisible, mais aussi se fragmenter via des swaps. Les observatoires ont relayé les faits ; ils n’ont pas, dans les premiers comptes rendus, publié une cartographie complète des destinataires.

Pour la victime, la distinction USDT / ONE compte moins que la somme. Pour une enquête, elle compte beaucoup. Les six transactions en treize minutes ressemblent à une exfiltration accélérée, pas à une erreur de saisie. Le test d’1 USDT en tête de file renforce cette lecture.

Ce que « affaire résolue » veut dire, concrètement

Dans le langage du support, « accord » peut signifier remboursement intégral, geste commercial partiel, crédits de frais, clause de non-divulgation, ou simple clôture administrative. Sans chiffre, le public ne peut pas départager ces hypothèses. C’est frustrant, et c’est voulu.

On peut comprendre qu’un exchange refuse d’exposer la vie financière d’un client. On peut aussi noter que cette prudence coïncide avec un intérêt réputationnel. Une indemnisation discrète éteint un incendie. Une indemnisation publique crée un tarif. Les plateformes connaissent ce calcul depuis les premiers grands hacks de l’histoire crypto.

Reste un point de méthode : même confidentiel, un accord ne dispense pas l’exchange de corriger le process si le process a failli. Les clients n’ont aucun moyen de vérifier cette correction, sauf si la documentation change — par exemple si les API sont désormais révoquées de force après tout gel, ou si la whitelist de retrait API devient obligatoire. Sur ce terrain, le communiqué de septembre 2026 n’avance rien.

Une lecture plus large pour le secteur

Les semaines récentes ont aussi été marquées par d’autres chocs de plateforme, dont un incident Bitget largement commenté. Chaque affaire a sa mécanique. Ensemble, elles rappellent une banalité que le bull market fait oublier : la surface d’attaque d’un exchange n’est pas seulement le cold wallet. C’est aussi le parcours de récupération de compte, le centre d’appel, le pipeline KYC, le cycle de vie des API et la qualité des alertes.

Les régulateurs regardent de plus en plus ces détails opérationnels, pas seulement les réserves. Un reset validé en dix minutes, une API invisible pour l’utilisateur, un lock qui expire pile avant l’exfiltration : voilà le type de séquence que l’on retrouve dans les questionnaires de supervision, qu’il s’agisse de licences asiatiques, de fenêtres britanniques ou de débats américains. L’affaire MEXC, même « résolue », nourrira ces dossiers plus sûrement qu’un communiqué d’une phrase.

Ce que l’utilisateur demande encore, malgré l’accord

Dans son fil, Shuang Fei réclame des éléments précis : IP de création de l’API, permissions, sort de la clé pendant le gel, canal des six retraits. Un accord financier, s’il existe, n’annule pas ces questions. Il les déplace. Elles intéressent désormais moins le solde d’une personne que la robustesse d’un produit utilisé par des millions de comptes.

On peut parier que certains de ces éléments resteront internes. On peut aussi souhaiter, sans naïveté, qu’une version assainie apparaisse dans les guides de sécurité : après un gel, les API ne « devraient » pas seulement être invalides ; elles devraient être détruites, listées, et confirmées mortes dans l’interface client. La différence entre « invalide » et « détruite » n’est pas sémantique. C’est précisément la zone grise du récit.

Pour ne pas refermer le sujet trop vite

L’histoire d’un compte vidé en treize minutes se raconte facilement. Elle se comprend moins bien. Entre le 25 et le 27 septembre, plusieurs systèmes ont dû s’enchaîner : validation d’un reset, création d’une clé, gel, restauration, expiration d’un lock, sorties. À chaque étape, une décision humaine ou logicielle a basculé d’un côté ou de l’autre. Le public n’a aujourd’hui que la version de la victime, quelques captures, des relais d’observateurs, et une phrase de support.

C’est déjà assez pour agir de son côté : réduire les permissions, allumer les listes blanches, cesser de traiter l’historique de login comme une preuve d’absence d’intrus, et considérer tout reset d’e-mail comme un événement majeur. Ce n’est pas encore assez pour clore le chapitre industriel. Tant que l’on ignore si l’API a survécu au gel, le mot « résolu » décrit un litige. Il ne décrit pas une architecture.

Les exchanges aiment parler de fonds gardiens, de cartes, de cashback, d’innovations de paiement. Ces produits existent. Ils ne dispensent pas de répondre à une question plus ancienne, et plus rude : quand un attaquant a posé une clé machine dans un compte, qui est responsable de s’assurer qu’elle est vraiment morte ? Dans l’affaire MEXC du 27 septembre 2026, cette question reste, pour l’instant, plus nette que les réponses.