MEXC says $340,000 account-takeover dispute is resolved, but API questions remain

A user says an attacker withdrew about $340,000 from a MEXC account after the exchange had frozen it and helped restore access. The exchange later said it reached an agreement with the user and considers the matter resolved. It hasn't disclosed the settlement terms.

The public record doesn't establish that the exchange itself was hacked. It describes an individual account takeover that allegedly began with an unauthorized security reset. Nor has the exchange publicly confirmed that an API key initiated the withdrawals.

That leaves a narrow but serious technical question: what happened to the API credential reportedly created while the attacker controlled the account?

The takeover began with a security reset

Shuang Fei, the affected user, said the first warning arrived at 03:10 Beijing time on September 25. An email reported a request to change the account's linked address and remove Google Authenticator. The request was approved ten minutes later.

The user denied submitting it and said the identity photo and verification video weren't genuine materials supplied by the account holder. According to screenshots shared in the user's thread, support later said the submitted material initially passed review. A later check detected risk, prompting the exchange to freeze the account and restore the original email.

During the hours in between, the attacker allegedly reset the password, logged in through an IP address associated with Jakarta, linked another authenticator, and changed the password again. The user says an API credential was created at 05:05:42, shortly after the second recorded login.

These details come from the user and the screenshots attached to the public thread. MEXC hasn't published an incident report confirming the precise takeover method, the submitted verification material, or the API's permissions.

Claims elsewhere that an AI-generated face swap bypassed KYC go beyond the evidence made public by the user. The thread says the materials weren't supplied by the account holder. It doesn't prove how they were made.

Access was restored, but the reported API remained

The exchange froze the account at about 10:55 on September 25, according to Shuang Fei. The user then removed the attacker's authenticator, reset the password, and linked a new authenticator. The last change was completed at 03:45:07 on September 26.

Official documentation says withdrawals and fiat trading are restricted for 24 hours after changes to a linked email or Google Authenticator. The same account guide says freezing an account disables login and trading and causes all associated API keys to become invalid.

The wording creates an unresolved distinction. "Invalid" could mean the keys are permanently revoked, or it could mean they can't be used only while the account remains frozen. The documentation doesn't explain whether an old key can become usable again after the account is restored.

Shuang Fei says support disclosed the attacker-created API only after the assets had left. The user also said it hadn't appeared in the visible security-operation history and that any creation notice would have gone to the email address controlled by the attacker.

Six withdrawals followed the 24-hour lock

The first outgoing transaction was a 1 USDT test at 04:12:45 on September 27. That was about 27 minutes after the withdrawal restriction tied to the final security change had expired. Five more withdrawals followed over the next 13 minutes.

The user reported a total loss of 322,110 USDT and 9,133,999 ONE, valued at roughly $340,000. The account's visible login history showed no new login during the withdrawal window, according to the thread.

An absent interactive login would be consistent with API access, but it isn't proof. Establishing the route requires the exchange's internal logs: the withdrawal channel, API key identifier, permissions, source IP, address controls, and the account-freeze and reactivation events.

None of those records is public. The exchange also hasn't said what happened to the withdrawn assets.

Why the API policy matters

A 2023 MEXC announcement, still available on its website, says withdrawal address whitelisting isn't enabled by default for API withdrawals. Without a whitelist, an API key carrying withdrawal permission can send assets to any address.

That policy doesn't prove the disputed withdrawals used the reported key. It explains why the key's permission scope matters. A read-only key couldn't withdraw assets. A key with withdrawal access and no address whitelist could.

The exchange's current security guide separately says users can enable a withdrawal whitelist. It also offers an optional restriction that imposes a 24-hour wait before a newly added address can receive withdrawals.

Those controls work only if they're active and apply to the withdrawal channel in question. The public response doesn't say whether either control was enabled on this account.

What the exchange has confirmed

MEXC customer support said it contacted the user, reached an agreement, and now considers the matter fully resolved. It declined to provide details, citing privacy.

That statement doesn't confirm reimbursement. It also doesn't answer whether the API was used, whether the key became valid again after the freeze, or why the withdrawal pattern wasn't stopped. Unless the user or the exchange releases more information, the settlement and technical findings remain private.

The distinction matters when describing the event. This is a reported account takeover followed by disputed API activity, not evidence of a platform-wide breach. The withdrawal timeline is documented by the user, while the final attack path remains an allegation supported by circumstantial account records rather than a public forensic report.

What users should do after an account takeover

Changing the password and 2FA isn't enough if an attacker may have created a separate credential. Review the API-management page and revoke every key you don't recognize. For keys you need, remove trading and withdrawal permissions unless the integration requires them. Portfolio-monitoring tools should use read-only access.

Check active sessions and trusted devices as well. Then enable a withdrawal address whitelist and, where available, a delay for newly added addresses.

If an exchange freezes and restores a compromised account, ask for written confirmation that API keys, active sessions, withdrawal addresses, passkeys, and every linked authentication method were reviewed. Don't assume an account freeze permanently revoked them.