On September 25, a MEXC user received an email confirming that their account security settings had been reset. Ten minutes later, the request was approved. Two days after that, 322,110 USDT and 9,133,999 ONE โ roughly $340,000 at the time โ left the account between 04:12 and 04:25. An attacker-created API key was still alive when the platform finally froze the account around 10:55.
Six hours. That is the gap between the drain and the lock. That API key is the only sentence in this file that matters. Not the breach. The aftermath.
I have spent years dissecting exchange logic, from the reentrancy surface in 0x Protocol v2 in 2018 to the Terra de-peg I traced block by block in 2022. This case is uglier than most because it requires no cleverness to execute. It requires a support queue, an approval button, and nobody checking whether the intruder left the window open. The exploit wasn't the hack. The exploit was the policy.
MEXC occupies a specific niche in the exchange hierarchy. It doesn't compete with Binance on liquidity or Coinbase on compliance. It competes on access โ long-tail listings, low fees, aggressive leverage, and a user base that trades assets no top-tier venue will touch. That positioning is precisely why its security posture deserves more scrutiny than it gets. Low-margin, high-throughput retail venues cut corners where nobody is watching, and account recovery is the first corner to go, because recovery friction is measurable as lost signups while recovery risk is invisible until it isn't.
The timeline here is fragmented but usable. September 25: a security reset email lands, and the request is approved within ten minutes. Subsequent account access originates from a Jakarta IP. September 26: the user changes their password and Google Authenticator. September 27: funds move out. Around 10:55 the account is frozen. The user files ticket M2026092712031 and reports to local police.
Then comes the crack in the story. The "unrevoked API" at the center of the complaint carries a creation timestamp of 05:05 โ roughly forty minutes after the transfers completed. That single number breaks the cleanest version of the narrative. My source material for all of this is user testimony plus MEXC's written support responses. No on-chain hash chain has been published. No police receipt. No third-party forensics. I have weighted every claim by confidence accordingly, and I want you to read it the same way. A timeline with a forty-minute hole is not a timeline. It is a hypothesis wearing a timestamp.
Three failures stack into this incident. Strip away the noise and they are the same failure wearing different masks.
The first is the security reset approval. Ten minutes is not review. Ten minutes is rubber-stamping. A reset request that changes recovery email, 2FA, and withdrawal permissions is the highest-risk action a CEX customer support desk can authorize, and the industry's leading venues deliberately slow it down with cooling-off delays, manual verification, and out-of-band confirmation. MEXC approved in ten minutes. That window is exactly wide enough for a social engineer to walk through, and exactly narrow enough that no human reviewer could have genuinely investigated anything.
The second is API permission management. The attacker's API key was never revoked. The user reported that their security operation history showed no record of the key. The platform could not confirm whether the transfer originated from the mobile app, the web interface, or the API. Read that sentence again. When a custodian cannot identify the channel through which a customer lost $340,000, it has not built a logging system. It has built a rumor.
The third is response latency. Six hours passed between the transfers and the account freeze. By then the assets were already gone. Freezing a drained account is damage control, not recovery. Every exchange I have audited carries the same structural flaw: revocation is a manual step, and nobody automates the cleanup. Withdrawal whitelists and time-locks exist precisely to close this gap, and they are conspicuously absent from the story the user told. That is where the blood is.
Now the anatomy of the timeline, because this is where the forensic value lives. If the API key was created at 05:05, it cannot have been the tool that moved funds at 04:12. That leaves two readings, and both are damning. Either the API key is a second backdoor โ planted after the main drain โ which means the attacker still held session tokens or credentials even after the password and 2FA change on September 26. That is a persistence problem, and persistence is worse than the original breach because it proves the cleanup failed. Or the record is simply wrong โ timestamps mislabeled, events reordered โ which means the platform's own audit trail cannot be trusted as evidence at all.
I spent a 2021 report documenting how 60% of the top NFT projects I audited had unsafe approval mechanisms vulnerable to signature replay. The lesson was never that NFTs were broken. The lesson was that approvals are where trust leaks, and exchanges carry the same structural blind spot at a thousand times the scale and none of the on-chain transparency that lets outsiders verify it.
In code, silence is the loudest vulnerability. The missing API revocation log says more than any alert could, because a log that should exist and doesn't is itself a finding.
The bystanders on both sides get this wrong, and I want to be precise about it. The CEX-FUD crowd reads this as proof that centralized exchanges are inherently unsafe. That is lazy. The overwhelming majority of exchange withdrawals clear without incident, and self-custody carries its own body count โ leaked seed phrases, malicious token approvals, phishing signatures, a hardware wallet lost in a drawer. Cold storage is not a moral high ground. It is a different attack surface with a different failure mode.
The exchange defenders argue $340,000 is trivial and the whole thing is noise. On market impact, they are right. On signal, they are catastrophically wrong. A sum this small moving through a venue this large is not a market event. It is a diagnostic event. It exposes a fault line โ approval governance and API lifecycle management โ that runs beneath every retail-facing custodian. The number is small precisely because the flaw is common. Whoever exploited this once found it everywhere, and the only reason we are reading about a $340,000 loss instead of a $34 million one is that this particular account was not bigger.
There is a third angle nobody wants to say out loud. If MEXC genuinely cannot determine the transfer channel, then it also cannot rule out internal involvement. I rate that probability low, but a support desk with unilateral authority to reset security settings in ten minutes, without a second signature and without a mandatory delay, is a support desk with a shortcut to theft. Controls exist to constrain honest people, because honest people are the only ones who respect them.
Liquidity is a mirror, not a vault. And a vault that approves its own reset in ten minutes is not a vault at all.
The recovery math is grim. USDT carries a theoretical freeze mechanism through Tether, but only if the trail is clean and the request is immediate. Every hour the attacker has to route through a mixer or a bridge erodes that probability further. ONE has no centralized freeze at all. There is no knight coming for the Harmony tokens, and the pool of buyers willing to absorb them does the attacker's laundering for free.
Legally, the user sits in the worst possible position โ cross-border, unclear operator entity, likely weak jurisdiction, and a claim small enough that no law firm will take it on contingency. Reporting to local police and MEXC simultaneously is the only rational move, and it remains a long shot that depends entirely on the platform's willingness to cooperate rather than on any enforceable obligation.
So here is where I land, and I am not going to soften it. The question is not whether MEXC was hacked. Centralized venues get targeted constantly; that is the cost of custody. The question is who approved the reset in ten minutes, why the revocation log is empty, and why the account freeze preceded the API deletion rather than the other way around. Order of operations is not a detail. It is the fingerprint of a process that was never designed to stop a determined attacker. The blockchain remembers, but the auditors forget โ and the customer support queue never knew in the first place.
The forward-looking judgment is simple. MEXC has three choices: publish a full forensic report with logs and the transfer channel, compensate the user, and rewrite the reset approval process with mandatory delays and dual authorization โ or stay silent. Silence is not a legal position. It is a liability with a timer attached.
Standardization fails when it ignores human chaos. The chaos here is a ten-minute approval on a $340,000 account, and the only thing standing between that and the next victim is whether anyone is forced to answer for it. Until MEXC does, that is the whole story.