MEXC Refunds $340,000: The Attacker's API Key Survived the Account Freeze

An attacker drained roughly $340,000 from the account of a user of the crypto exchange MEXC, even though the account had already been flagged as compromised, frozen and handed back to its owner. The route in was an API key the attacker had created during the takeover and which the exchange failed to revoke when it restored the account. MEXC admitted exactly that in public on September 28 and 29, 2026, and says it has reimbursed the loss in full.

This is not an exchange hack in the usual sense. No exchange wallet was emptied and no contract flaw was exploited. A single account was affected, and the way in ran through an interface most users never look at. Anyone holding coins on a trading platform will recognise three points in this sequence that can look exactly the same inside their own account.

What happened in the MEXC user's account between September 24 and 27

The account of events comes from the affected user himself, who posts on X as @shuangfei8, and has been picked up independently by several trade publications. His account was taken over on September 24, 2026. MEXC spotted the access, froze the account and helped the user recover the original email address and the authenticator app. Up to that point the exchange reacted fast and in the right direction.

During the takeover, however, the attacker had done a second thing. According to Crypto Economy, he created an API key with withdrawal rights on September 24 at 21:05:42, 83 seconds after his second login to the account. That key stayed live when the account was released back to its owner.

After a security-related intervention on an account, crypto exchanges usually impose a 24-hour withdrawal freeze. That window expired. Twenty-seven minutes later the outflows began. According to the user, 322,110 USDT and 9,133,999 ONE left the account, together worth roughly $340,000, in six transactions to two addresses and within 13 minutes.

Reports differ slightly on timing because they quote different time zones. TechFlow puts the window at 04:12 to 04:25 Beijing time on September 27; The Crypto Times dates the outflow to September 26. Both describe the same window, once in East Asian local time and once converted. The difference changes nothing about the sequence.

API keys with withdrawal rights: why they need neither Google Authenticator nor the email code

An API key is a set of credentials that lets a program talk to the exchange on an account holder's behalf without logging in the way a human does. It consists of a public part and a secret part and carries a fixed list of permissions: read only, trade, or withdraw as well.

The decisive point in this case sits in the design. Two-factor authentication with an authenticator app and the confirmation email are controls for the human login path. A machine cannot read a six-digit code out of an app, so the interface does not ask for one. Whoever holds a key with withdrawal rights needs neither the password nor the authenticator nor access to the email inbox.

That is why restoring the account did not end the attack. Email and authenticator were recovered, and neither mattered for the actual outflow. A trading bot, a portfolio tracker and an attacker technically use the same door.

The practical consequence: changing your password and setting up two-factor authentication again does not yet secure your account. Only revoking every key closes this second route. How differently providers are set up on login protection is something we have written down in our overview of two-factor authentication at the crypto exchange.

The 24-hour withdrawal freeze and its gap

A freeze after a security incident is meant to buy time, on the assumption that anyone with illegitimate access loses it within a day because the owner changes the password and the exchange clears up. That assumption only holds if the clean-up is complete.

In the MEXC case the freeze worked as intended and blocked every withdrawal for 24 hours. Then the window expired, and the key left behind was still valid. The 27 minutes between the end of the freeze and the first transaction suggest the timing was not hit by chance but waited for.

For you that means a withdrawal freeze is a window of time, not a repair. Whatever is not dealt with inside that window keeps working afterwards. And the account holder sees nothing of an existing interface unless he explicitly opens the key management page.

Account takeover through identity verification: the user's account of events

How the attacker got into the account in the first place is the most contested part of the story, and caution is in order here. According to the affected user, whose version TechFlow reports at length, the account's security settings were reset through the identity verification route, using forged identity documents. Neither the password nor an active session had been compromised, he says.

That version comes from the injured party. MEXC has not commented publicly on this point in detail and says the investigation is ongoing. So far, only what the company has itself established counts as confirmed: that the account was taken over, that it was frozen and restored, and that a key left behind made the outflow possible.

Whichever route is eventually confirmed, one question follows that every user can answer for their own account: which routes exist at my exchange for resetting two-factor authentication, and how tightly is that route secured? The reset path is the weakest point of any account, because by design it unhooks every other layer of protection.

What MEXC chief Vugar Usi Zade said on X

On September 28, 2026, Vugar Usi Zade, chief executive of MEXC, addressed the case on X and described the sequence from the company's point of view. Customer support had spotted the takeover quickly and frozen the account, he said, after which MEXC helped the user get the email address and authenticator back.

On the decisive point he wrote, as reported by The Crypto Times: “Unfortunately, an API key that remained on the account allowed the attacker to transfer the funds before the issue could be fully contained.”

The investigation is not closed, he said, but one thing is clear: “We do not believe the user should have to bear the consequences of this incident.” MEXC has put its own team on the case and compensated the affected user in full.

The road to that point is notable. As late as September 28, Crypto Economy reported a settlement with the user on undisclosed terms, and customer support had earlier told the account holder it could not determine whether the withdrawals came from the app, from the browser or through an interface. Only the chief executive's statement named the route. Anyone conducting a dispute like this should expect the first answer from customer support not to be the final version.

Compensation without a legal claim: the difference between goodwill and liability

That the user got his money back is good news with a catch. The refund was a company decision, not the enforcement of a claim. Phrases such as “user-first” are a commitment, not contract language.

The difference matters when a case ends badly. Goodwill depends on the attention a case attracts. This one ran visibly for days on X and in the trade press, with timestamps, transaction details and a sequence anyone could follow. An account holding 3,000 euros with no audience does not have that leverage.

A claim, by contrast, hangs on the law the provider is subject to. And it is precisely here that trading venues differ considerably for European users.

MiCA and the crypto exchange's liability for lost client assets

Since the EU regulation on markets in crypto-assets took effect, custody and trading services may only be provided in the European Union by authorised firms. Authorisation comes with an obligation that is rarely read in everyday life and becomes decisive in cases exactly like this one: an authorised custodian is liable to its clients for the loss of crypto-assets or of means of access where the incident is attributable to it. Keeping client holdings segregated from the firm's own assets and maintaining a documented custody policy belong to the same set of duties.

This liability is not automatic and does not cover every loss. It presupposes that the provider is authorised and that the incident falls within its area of responsibility. A seed phrase a user types into a fake wallet page himself is not covered. A means of access that the exchange leaves in place after a detected break-in sits closer to the provider's area of responsibility.

Whether your trading venue falls under these duties is not stated in its advertising but in the supervisor's register. Germany's BaFin lists the crypto-asset service providers authorised there in a public overview, and the European supervisory authority ESMA keeps the register for the whole economic area.

Reverse solicitation: what an unlicensed exchange's status means for European users

Many large trading venues with a wide range of smaller tokens hold no authorisation in the EU. Officially these providers do not market in the Union, but they do accept clients who come to them of their own initiative. That route is called reverse solicitation, and it is meant as a narrow exception, not as a business model.

For you as a user the status has tangible consequences. Without EU authorisation there is no supervisor you can turn to, no complaints body in your language, no enforceable claim out of the European set of duties, and in a dispute a place of jurisdiction far away. What remains is the provider's goodwill.

That is not a recommendation to avoid or to use such venues. It is the condition under which you decide how much sits there. Anyone trading there because the pair exists nowhere else can cap the amount and withdraw after the trade.

API keys in your own account: permissions, IP binding and expiry dates

Key management sits under account or security settings at most exchanges and is called API management. Every active key is listed there with its permissions, often with the date of creation and of last use. That list is exactly the place that would have made the difference in the MEXC case.

Three settings decide how much damage a key gone astray can do. Withdrawal rights are the first: without that permission a key can trade and read but cannot move anything off the exchange. The second is binding to fixed IP addresses, which lets a key work only from known machines. The third is an expiry date, which many platforms now enforce so that forgotten keys die on their own.

A fourth point is pure hygiene: one key per application, with a recognisable name. Anyone using one key for three programs cannot revoke it on suspicion without switching everything off. Anyone keeping three named keys instead removes the one in question in seconds.

Tax software, portfolio tracker and trading bot: which permissions a key actually needs

In the vast majority of cases the program you connect needs considerably less than it asks for. A tax program or a portfolio tracker reads trade history and holdings and gets by with read-only rights. There is no substantive reason why software that calculates gains should be able to move coins.

A trading bot needs trading rights, because it places orders. It too needs no withdrawal rights. Anyone granting both together has created a route of access that can do everything he can do, permanently and without a second factor.

Which permissions common tax tools actually request, and how they differ, is something you can look up in our overview of crypto tax software and portfolio trackers before you create your next key.

One last note on connections you have long forgotten: a tracker you tried once two years ago still holds its key today. Legacy items like that are immediately recognisable in the list, because their date of last use is far in the past.

Two-factor authentication and the limits of its protection

Two-factor authentication remains right and important. The protection bites on the login path, and that is the most common attack route of all. An app such as an authenticator is clearly superior to SMS here, because a mobile number can be taken over.

What two-factor authentication does not cover are machine routes of access and the reset path. It bypasses both by design, not through a flaw. Security on a trading platform therefore consists of three layers: login protection, key management, and the question of how much sits there at all.

The third layer is the only one entirely in your own hands.

Exchange balances and self-custody: the split after this case

Coins on an exchange are a claim against a company. Coins in your own wallet are a key in your hand. The MEXC case does not fundamentally shift that old trade-off, but it does show an attack surface that does not exist with self-custody. A hardware wallet has no interface an attacker could have unlocked through customer support.

In exchange, self-custody shifts the risk onto you. Lost recovery words are final, and there is no chief executive to authorise a goodwill payment. The split commonly used in practice: what you actively trade stays on the trading venue, what you want to hold for longer sits in your own custody.

For European investors there is a tax point on top. Moving your own coins from the exchange into your own wallet is not a sale and, on the usual reading, triggers no tax, because no change of ownership takes place. You do have to carry the acquisition data, and with it the holding period, yourself, because after the transfer no platform knows the original purchase date any more. Anyone using a tool for that should export the history before closing an account.

API keys at the crypto exchange: your next three steps

1. At every exchange where you hold an account, open API management and remove every key you cannot immediately match to a running application. On the ones that remain, take away withdrawal rights and bind them to your IP address. Which venues are under European supervision at all can be found in our list of regulated crypto exchanges.
2. Decide what amount may sit on a trading venue, and withdraw the rest. A useful guide is the amount whose total loss would not throw you off course. For the part meant to sit longer, a device with its own key is the next step; the differences are set out in the hardware wallet comparison.
3. Look at how two-factor authentication can be reset at your exchange, and switch on every notification available for it. An email about a newly created interface is the only warning that would have arrived in time in this case. If you then withdraw from the trading venue, the software wallet comparison helps with choosing where to send it.

The MEXC case ended lightly because a company paid that did not have to. That is the weakest of all safeguards. The strong version consists of a short list of active keys, a capped balance on the trading venue, and an exchange whose supervisor you can name.

The company's full confirmation including quotes from its chief executive can be read at The Crypto Times.

(As of September 29, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)