User Claims MEXC Did Not Revoke API, Resulting in $340,000 Withdrawal
A user reported that their MEXC account had 322,110 USDT and 9,133,999 ONE withdrawn on September 27, totaling approximately $340,000. They indicated that on September 25, an attacker used forged materials to change the email and reset security items, briefly gaining control to create an API key.
The platform later confirmed the theft, froze the account, and assisted in recovery. The user changed their password and Google Authenticator as required, but the API was not revoked. About 27 minutes after the 24-hour withdrawal limit was lifted, assets were drained via the API, with no new login records during that time.
The user questioned the review, freezing procedures, and risk control, demanding log preservation, a written response, and asset return. They have filed a formal claim and attempted to report to the police. The help center's guidelines were cited: APIs associated with frozen accounts should become invalid; API withdrawals do not require Google or email verification.
The control window was noted to be approximately 7.5 hours, and the security item reset was approved in about 10 minutes. Withdrawals were made in multiple transactions. Another user reported receiving similar emails about resetting security settings, and the community advised checking the API management page for unfamiliar keys immediately.
Some English reports mentioned that forged documents and facial verification were bypassed, while the platform's public response only stated that a preliminary investigation was completed, a solution was provided, and a dedicated person would follow up, communicating through the registered email without acknowledging the API was not revoked in the public post.
In market mechanisms, what is sold is account recovery services, while what is bought is whether withdrawal permissions have been reset. Funds flowed from the spot balance through residual keys to on-chain addresses; the beneficiary is the party still holding the withdrawal API, while the pressured party is the user who thought the channel was closed after completing the customer service checklist. The incident was driven by residual permissions, not new login sessions.
Source: Public Information
ABAB AI Insight
This allegation breaks down the exchange's risk control into two accounts: the login account and the withdrawal account. Customer service fixed the email, password, and authenticator, which equates to fixing the login account; the API left by the attacker is the withdrawal account. The 27 minutes after the limit was lifted indicates that the cooling period is only tied to human identity, not to the token lifecycle.
The capital path is that the custodial platform uses the API to provide backdoor convenience for quantitative clients while giving retail clients a sense of security through secondary verification. The two channels have unequal permissions, and if the recovery process only follows the retail checklist, the quantitative channel becomes an ATM after takeover. Claims and police reports shift the pricing power from customer service scripts to log preservation.
A comparable situation is changing the login password for a cloud host but leaving the access key, and a brokerage resetting the password but not terminating the delegation agreement. The industry phase is shifting account security from "who is logging in" to "what keys can withdraw funds without ever logging in."
The structural judgment pertains to the transfer of pricing power. The mechanism is that whoever defines the coverage of the frozen account checklist provides the security pricing for withdrawals; if the checklist does not include the API, "assisted recovery" only applies to logins.
ABAB News · Cognitive Laws
Recovering an account does not equal regaining withdrawal access.
The cooling period ties to people, not to tokens.
Withdrawals without login records indicate permissions are in the interface.