MEXC Account Hack How A User Lost 340K After Recovery

Have you ever recovered an account, changed the password, swapped the authenticator, sat through a withdrawal lock, and still felt the floor drop out from under you? That is the shape of the story circulating around a MEXC account hack in late September 2026. One user, writing under the name Shuang Fei, says roughly $340,000 left the account in a tight window after the exchange had already frozen the profile, restored the original email, and handed control back. The numbers cited are blunt: 322,110 USDT and about 9.13 million ONE, pulled between 04:12 and 04:25 Beijing time on September 27. I have covered exchange disputes long enough to know that first posts are messy. This one is messy in a specific way. The fight is not only about stolen coins. It is about an API key that, according to the user, was created while an attacker held the account and later appeared to survive a freeze that official docs say should kill every associated key.

What Actually Happened In The MEXC Account Dispute

Start with the morning of September 25. Shuang Fei says an email arrived at 03:10 Beijing time. The message claimed someone had applied to change the linked mailbox and strip Google Authenticator from the account. Ten minutes later, the request was approved. That speed is the first thing that makes people sit up. Security resets are supposed to feel heavy. They are supposed to drag. Ten minutes is a blink.

The user insists the identification photo and the verification video were not genuine materials. In later messages, support apparently said the files had initially met internal requirements. Then risk systems flagged the file set, the account was frozen, and the original email was put back. If that sequence is accurate, you get a strange sandwich: first approval, then suspicion, then a freeze, then a restoration that still left a technical loose end.

MEXC confirmed the account was stolen, froze it, and helped me recover it, yet missed the API the attacker left behind. Twenty-four hours after the withdrawal restriction ended, the assets were emptied in minutes.

Once the attacker had a foothold, the password was reset and a new authenticator was bound. Login records shared in the thread pointed to an IP tied to Jakarta. At 05:05:42, an API was created. The user says the exchange only confirmed that key after the money was already gone. That delay, if real, is the kind of detail that turns a theft into a process failure. People can accept a break-in. They struggle with a break-in that keeps a spare door open after the locksmith has been through the house.

The Reset Email That Started The Clock

Account recovery on large venues usually asks for three layers: knowledge of the account, identity documents, and a short video of a person holding an ID. That package is meant to stop casual impersonation. It is not foolproof. Deepfakes have gotten cheaper. Stolen document scans sit in old data dumps. A rushed reviewer can miss a tell. I am not claiming that is what happened here. I am saying the user’s allegation sits inside a known industry weakness. Video KYC is a speed bump, not a vault door.

Public documentation from the venue describes the same checklist: account details, identity papers, a clip of the holder with the document. The user argues those materials were not theirs. Support, in screenshots later shared, suggested the first pass looked acceptable. Then a second pass found risk. That two-step pattern is common. Front-line queues clear volume. Risk teams clean up after. The gap between those desks is where attackers live.

Perhaps the most interesting aspect is timing. Approval in ten minutes. Freeze later the same morning, around 10:55. Hours in between. Hours are enough to reset credentials, mint an API, and set withdrawal permissions. Hours are also enough for a victim to notice an email and start shouting into a ticket. Both things can be true at once.

How Control Changed Hands After The Freeze

After the freeze, Shuang Fei says recovery stretched into the next day. The attacker’s authenticator was removed. The password changed again. A new authenticator was linked. The last of those steps completed at 03:45:07 on September 26. That timestamp matters because of the 24-hour withdrawal brake that follows certain security edits. Change the email. Change Google Authenticator. The venue’s own pages say crypto and fiat withdrawals sit in a penalty box for a day.

So the story has a clean-looking safety feature. Then it has a messy exception. A separate account guide states that freezing a profile disables trading and login and makes all API keys associated with the account invalid. The user asked the obvious question in public. Did that key die when the freeze hit? Did it wake up when the account came back? Those are not rhetorical flourishes. They are engineering questions. Exchanges rarely answer engineering questions in a press note.

I’ve found that users treat API panels as a back office they never visit. Keys get created for a bot, forgotten, left with withdrawal rights because a tutorial said “enable everything so it works.” Attackers love that neglect. In this case the alleged key was not even the user’s leftover toy. It was said to be minted after the takeover, while the mailbox was already pointed somewhere else, which would explain a missing alert.

The 27 Minutes After The Lock Lifted

On September 27 at 04:12:45, about 27 minutes after the 24-hour restriction ended, a first outgoing transfer of 1 USDT moved. That tiny probe is a classic pattern. Test the pipe. If it clears, open the valve. Five more withdrawals followed inside roughly 13 minutes. By 04:25 the pile was gone: 322,110 USDT and 9,133,999 ONE, valued by the user near $340,000.

No fresh login showed in the history during that burst, according to the same thread. If you take that claim at face value, the session that moved the money did not look like a person typing in a browser. It looked like a machine calling an endpoint. That is exactly what an API is for. It is also exactly why withdrawal-capable keys scare security people more than a stolen password. A password needs a login page. A key can sit in a script and wait for a lock to expire.

Monitoring desks later repeated the user’s version. They did not independently prove the method in the short notes that circulated. That distinction matters. Repeating a claim is not the same as reconstructing a chain of custody on-chain and in server logs. Still, the absence of a new interactive login during the drain is the detail that keeps this story alive. People can argue about video KYC quality all day. They have a harder time waving away a withdrawal with no human session attached.

What The Exchange Said, And What It Did Not Say

Customer support later told the public it had contacted the user and “successfully reached an agreement.” The matter was called fully resolved. Terms were withheld on privacy grounds. Fair enough as a legal posture. Frustrating as a market posture. Traders want to know whether the coins came back, whether an API was the pipe, and whether those assets were traced. None of that was confirmed in the short statement.

An earlier public line, before the settlement note, said an initial investigation had finished and “corresponding solutions” were offered. That phrase is corporate fog. It can mean a goodwill credit. It can mean a partial make-good. It can mean a process tweak and a coupon. Without numbers, readers fill the gap with whatever they already believe about centralized venues.

In my experience, privacy is a real constraint and also a convenient shield. Both can operate in the same sentence. A user may want silence after a payout. A firm may want silence before a payout is even defined. Outsiders cannot tell which version they are looking at. So the responsible way to write this is simple. Report the agreement. Report the missing terms. Do not invent a refund that nobody confirmed.

Why API Withdrawals Sit At The Center Of The Argument

Years ago the venue said withdrawal whitelists would not be on by default for API withdrawals. Money could leave to any address unless a user flipped the extra switch. The advice was familiar: turn the whitelist on, never paste keys into chats, treat a secret like cash on a table. Current pages still separate “normal” withdrawals that demand email, mobile, or authenticator checks from settings that can allow transfers under specified conditions without repeating two-factor every time.

That design is not unique. Bots need to move collateral without a human tapping a phone at 3 a.m. Market makers need speed. The cost of speed is a channel that does not always ask the same questions a browser session asks. If an attacker mints a key with withdrawal scope, the later recovery of a password may not matter. The script does not care who owns the login form now.

• Default-off whitelists widen the blast radius of a stolen key.
• Freeze policies that invalidate keys only help if invalidation is permanent and audited.
• Users rarely see API creation events if the alert mailbox has already been swapped.
• Withdrawal locks on UI changes may not bind every machine channel the same way.
• Missing login rows during a drain point investigators toward automation, not a typed session.

Shuang Fei asked for four pieces of forensic bread. The IP that created the API. The permissions on that key. Whether the key actually went dead during the freeze. Which channel fired the six withdrawals. Those asks are reasonable. They are also the kind of log dump legal teams hate to publish. Still, a venue that markets protection funds and recovery stories eventually has to explain the plumbing, or people will explain it for them in the worst possible tone.

The Freeze Rule Versus The Living Key

Read the freeze language again in plain English. Freeze the account. Trading stops. Login stops. Associated API keys become invalid. If that sentence is literal, an attacker key created at 05:05 should have been a brick by late morning on the 25th. If withdrawals still left through that key on the 27th, either the sentence is not literal, or a new key appeared later, or a different channel was used and the API story is incomplete.

I keep circling that fork because it is the only part of the narrative that is testable. Video authenticity is a judgment call. Jakarta IPs can be VPNs. Settlement terms can stay private. A key’s status in a database is a boolean. Valid or not. Bound to withdrawal or not. Fired at 04:12 or not. Someone inside the firm already knows. The public does not.

There is a sloppy middle possibility too. A freeze marks keys invalid in the UI while a cache or a matching engine still honors a signed request for a while. Systems drift. I have seen worse in other stacks. I am not saying that happened. I am saying “the docs said X” is not the same as “the production cluster did X under load after a restore.” Restores are messy. Restores reattach objects. Restores sometimes reattach the wrong objects.

What Users Should Assume After A Takeover

If you ever claw an account back, do not treat the green checkmark as the end of the job. Treat it as the start of a hunt. Assume a second channel exists until you prove it does not. That sounds paranoid. Good. Paranoia is cheaper than a 13-minute drain.

1. Open the API panel and delete every key, including ones you do not recognize.
2. Create a fresh key only if you truly need a bot, and deny withdrawal permission by default.
3. Turn on an address whitelist before you even think about automation.
4. Rotate the password and authenticator again after the freeze lifts, not only during it.
5. Move size off the venue until login history, device list, and key list look boring.
6. Ask support, in writing, to confirm that all prior keys were revoked at the server, not just hidden in the interface.
7. Watch the first hour after a withdrawal lock expires like it is a live event, because for attackers it is.

None of that would have been fun at 4 a.m. in Beijing. All of it is cheaper than arguing about a settlement you cannot quote. The user in this case says the attacker key was not visible in the security-operation history they could see. If that is accurate, the checklist above still helps, because deletion is a blunt instrument. You do not need a pretty audit trail to smash every secret in the drawer.

Custodial Risk Is Not A Slogan

People repeat “not your keys, not your coins” until it becomes wallpaper. Then they leave six figures on an exchange because the order book is deeper there, or the pair they want does not exist on a hardware wallet workflow. I do it too, in smaller size. Honesty first. The point is not purity. The point is sizing. A takeover plus an API is a single story. A takeover plus an API plus a 24-hour lock that an automated call can simply wait out is a design story. Design stories scale. They do not stay unique to one handle on a social app.

This episode also sits near older friction at the same venue around frozen balances and later returns. I will not drag those older files into a courtroom they do not belong in. I will say the pattern readers care about is consistency. If a firm can unwind a messy freeze for one well-known trader, the next user will ask why a $340K drain needs privacy language and no public mechanics. That question is not harassment. It is how markets price operational trust.

The firm has talked up protection measures, including a large guardian-style fund expansion earlier in 2026. Funds are useful after a loss. They do not replace a key lifecycle that is boring, logged, and irreversible when a freeze lands. Marketing a vault is easy. Showing the bolt work is harder. Readers can tell the difference even when they cannot read Java in a backend repo.

The Human Texture Of A Fast Theft

There is a particular nausea that hits when the account looks like yours again and the balance does not. You did the homework. You sent the video. You waited out the lock. You refreshed the page at 04:12 and watched a 1 USDT test leave like a knock on the door. Then the rest followed. I have not lived this exact night. I have lived versions of it in smaller numbers, and the body does the same thing. Hands go cold. You open the same ticket for the twentieth time. You start writing a thread because support queues feel like a well.

That is why the public write-up exists. It is not only advocacy. It is a demand for a timeline that matches the product copy. If keys die on freeze, say so with logs. If they can be reactivated on restore, print that in the help center in language a tired person can understand at dawn. Ambiguity is where the $340K feeling lives. Ambiguity is also where copycats study.

Did this API become invalid at that time? Did it become active again after the account was restored?

– Question posed by the affected user

Those two sentences should be on a whiteboard in every exchange security room. Not because one user asked them. Because every restore is a merge conflict between “we locked the thief out” and “we brought the real owner back,” and merge conflicts drop objects on the floor.

Practical Hardening Beyond This One Case

Whitelists belong on before you fund an account, not after a scare. Withdrawal-capable APIs belong off unless a strategy dies without them. Email used for security events should not be the same inbox you have reused for a decade of breaches. Authenticator apps should live on a device that does not share a pocket with the phone that receives the reset mail, if you can stand the inconvenience. Inconvenience is a feature. Attackers budget for your convenience.

Device lists need a monthly glance. So do session tables. So do API rows. Make it a dull ritual, like checking a smoke alarm. If a venue lets you set a spending cap on automated withdrawals, use a number that would annoy you if it vanished but would not change your year. If it does not offer a cap, treat that as information. Product gaps are risk labels even when the landing page is glossy.

A simple personal rule after any recovery:
  1. Kill every key.
  2. Whitelist first, fund second.
  3. Wait out the lock on a small balance, not the whole stack.
  4. Move residual size only after a quiet 24 hours with no mystery sessions.

Would that rule have saved every coin in this report? Nobody outside the log cluster can say. It would have reduced the surface. Reducing surface is the only lever most of us actually hold. We do not write the freeze service. We do write our own withdrawal permissions.

What Remains Unsettled On The Record

Let me be plain about unknowns. We do not have public confirmation that the user was reimbursed. We do not have public confirmation that an API initiated the six transfers. We do not have the destination story for the USDT and the ONE. We do not have the IP that minted the key, beyond the Jakarta login color around the takeover window. We do not have a vendor-style postmortem. We have a user timeline, a settlement sentence, and a documentation clash that still itches.

That itch is the news. Not the dollar figure, loud as it is. Plenty of larger drains happen and vanish into mixer folklore. This one sticks because the victim was already inside a recovery flow. The house said it was locked. Then the back door, if the account of events holds, waited 27 minutes after the official timer and finished the job.

Should readers treat the venue as uniquely broken? No. Should they treat API defaults and freeze semantics as optional reading? Also no. The boring pages in a help center are where the next night like this is either prevented or scheduled. I would rather be accused of repeating myself on whitelists than of shrugging at a 13-minute empty.

A Closing Read For Anyone Still Holding Size On An Exchange

Keep what you must keep for active trades. Sweep the rest. After any security email you did not request, assume compromise until the API list is empty and support has answered in a ticket you can screenshot. Watch the minute the withdrawal lock ends. That minute is not ceremonial. In this telling, it was operational.

And if a firm says a dispute is fully resolved while saying nothing about the pipe that moved the coins, file that under incomplete. Privacy can be valid. Completeness is still a public good when the same buttons sit on millions of screens. The user asked whether a key died in a freeze and lived after a restore. Until that question has a technical answer, every recovery story on that stack will carry an asterisk. That is not drama. That is how you read a system that can empty $340K without a new login row.

One last personal note, because these pieces get cold if you only recite clocks. I still think most exchange staff want the honest owner whole. I also think product debt around keys, alerts, and restore paths is where good intentions go to sleep. Wake those paths up. Print the lifecycle. Make freeze mean dead secrets, not sleeping secrets. Then a night like September 27 becomes a near miss instead of a thread that has to explain, again, how the money left after the account was already “safe.”