MEXC devuelve 340.000 dólares: la clave de API del atacante sobrevivió al bloqueo de la cuenta

Un atacante retiró alrededor de 340.000 dólares de la cuenta de un usuario del exchange de criptomonedas MEXC, pese a que esa cuenta ya había sido identificada como comprometida, congelada y devuelta a su propietario. La vía fue una clave de API que el atacante había creado durante la toma de control y que el exchange no revocó al restaurar la cuenta. MEXC lo admitió públicamente los días 28 y 29 de septiembre de 2026 y afirma haber resarcido el daño por completo.

No se trata de un hackeo de exchange en el sentido habitual. No se vació ninguna cartera del exchange ni se explotó un fallo de contrato. Se vio afectada una sola cuenta, y el acceso pasó por una interfaz que la mayoría de los usuarios no mira nunca. Quien tenga criptomonedas en una plataforma de negociación reconocerá en esta secuencia tres puntos que pueden presentarse exactamente igual en su propia cuenta.

Qué ocurrió en la cuenta de MEXC entre el 24 y el 27 de septiembre

El relato de los hechos procede del propio afectado, que publica en X con el nombre @shuangfei8, y ha sido recogido de forma independiente por varios medios especializados. Su cuenta fue tomada el 24 de septiembre de 2026. MEXC detectó el acceso, congeló la cuenta y ayudó al usuario a recuperar la dirección de correo original y la aplicación de autenticación. Hasta ahí, la reacción del exchange fue rápida y en la dirección correcta.

Durante la toma de control, sin embargo, el atacante hizo una segunda cosa. Según Crypto Economy, creó el 24 de septiembre a las 21:05:42 una clave de API con permiso de retirada, 83 segundos después de su segundo inicio de sesión en la cuenta ajena. Esa clave siguió activa cuando la cuenta fue devuelta a su titular.

Tras una intervención de seguridad en una cuenta, los exchanges de criptomonedas suelen imponer un bloqueo de retiradas de 24 horas. Ese plazo expiró. Veintisiete minutos después comenzaron las salidas. Según el usuario, salieron 322.110 USDT y 9.133.999 ONE, en conjunto unos 340.000 dólares, en seis transacciones a dos direcciones y en un intervalo de 13 minutos.

Las informaciones difieren ligeramente en la hora, porque citan husos horarios distintos. TechFlow sitúa la ventana entre las 04:12 y las 04:25, hora de Pekín, del 27 de septiembre; The Crypto Times fecha la salida el 26 de septiembre. Ambas describen la misma ventana, una vez en hora local del este asiático y otra convertida. La diferencia no cambia nada del desarrollo.

Clave de API con permiso de retirada: por qué no necesita Google Authenticator ni el código por correo

Una clave de API es un juego de credenciales con el que un programa habla con el exchange en nombre del titular de la cuenta, sin iniciar sesión como lo haría una persona. Consta de una parte pública y una secreta, y lleva una lista fija de permisos: solo lectura, negociación, o también retirada.

El punto decisivo de este caso está en el diseño. La autenticación de dos factores mediante una aplicación y el correo de confirmación son controles pensados para la vía de acceso humana. Una máquina no puede leer un código de seis dígitos en una aplicación, de modo que la interfaz tampoco lo exige. Quien posee una clave con permiso de retirada no necesita ni la contraseña, ni la aplicación de autenticación, ni acceso al buzón de correo.

Esa es la razón por la que restaurar la cuenta no puso fin al ataque. El correo y la aplicación se recuperaron, y ninguno de los dos tuvo importancia para la salida de fondos. Un bot de trading, un rastreador de cartera y un atacante usan técnicamente la misma puerta.

La consecuencia práctica: cambiar la contraseña y volver a configurar la autenticación de dos factores todavía no asegura una cuenta. Solo revocar todas las claves cierra esta segunda vía. Lo distintos que son los proveedores en la protección del inicio de sesión lo hemos recogido en nuestro repaso a la autenticación de dos factores en el exchange de criptomonedas.

El bloqueo de retiradas de 24 horas y su hueco

El bloqueo posterior a un incidente de seguridad pretende ganar tiempo, y da por supuesto que quien tiene acceso ilegítimo lo pierde en un día, porque el propietario cambia la contraseña y el exchange hace limpieza. Ese supuesto solo se sostiene si la limpieza es completa.

En el caso de MEXC el bloqueo funcionó como estaba previsto e impidió cualquier retirada durante 24 horas. Luego el plazo expiró, y la clave que había quedado seguía siendo válida. Los 27 minutos entre el fin del bloqueo y la primera transacción sugieren que el vencimiento no se alcanzó por casualidad, sino que se esperó.

Para ti eso significa que un bloqueo de retiradas es una ventana de tiempo, no una reparación. Lo que no se resuelve dentro de esa ventana sigue actuando después. Y el titular no ve nada de una interfaz existente mientras no abra expresamente la gestión de claves.

Toma de control mediante verificación de identidad: la versión del usuario

Cómo llegó el atacante a entrar en la cuenta es la parte más discutida de la historia, y aquí conviene la prudencia. Según el afectado, cuya versión recoge TechFlow con detalle, los ajustes de seguridad de la cuenta se restablecieron por la vía de la verificación de identidad, presentando documentos falsificados. Ni la contraseña ni una sesión activa habrían estado comprometidas.

Esta versión procede del perjudicado. MEXC no se ha pronunciado públicamente en detalle sobre este punto y señala que la investigación sigue abierta. Por ahora solo se tiene por acreditado lo que la propia empresa ha constatado: que la cuenta fue tomada, que fue congelada y restaurada, y que una clave que quedó activa hizo posible la salida de fondos.

Con independencia de la vía que acabe confirmándose, de ahí se deriva una pregunta que cada usuario puede responder para su propia cuenta: ¿por qué caminos se puede restablecer la autenticación de dos factores en mi exchange, y con qué rigor está protegido ese camino? La vía de restablecimiento es el punto más débil de cualquier cuenta, porque por diseño desengancha todas las demás capas de protección.

Qué explicó en X Vugar Usi Zade, el máximo responsable de MEXC

El 28 de septiembre de 2026, Vugar Usi Zade, director ejecutivo de MEXC, se pronunció en X sobre el caso y describió el desarrollo desde la óptica de la empresa. El servicio de atención habría detectado con rapidez la toma de control y congelado la cuenta; después MEXC habría ayudado al usuario a recuperar el correo y la aplicación de autenticación.

Sobre el punto decisivo escribió, según recoge 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.» En español: una clave de API que permaneció en la cuenta permitió al atacante mover los fondos antes de que el incidente pudiera contenerse por completo.

La investigación no estaría cerrada, pero una cosa sería clara: «We do not believe the user should have to bear the consequences of this incident.» El usuario no debe cargar con las consecuencias. MEXC afirma haber puesto un equipo propio en el caso y haber indemnizado por completo al afectado.

El camino hasta ahí llama la atención. Todavía el 28 de septiembre, Crypto Economy informaba de un acuerdo con el usuario en condiciones no reveladas, y el servicio de atención había comunicado antes al titular que no podía determinar si las retiradas procedían de la aplicación, del navegador o de una interfaz. Solo la declaración del director ejecutivo puso nombre a la vía. Quien libre una disputa así debe contar con que la primera respuesta del servicio de atención no sea la versión definitiva.

Indemnización sin derecho reclamable: la diferencia entre cortesía comercial y responsabilidad

Que el usuario haya recuperado su dinero es una buena noticia con un matiz. El reembolso fue una decisión de la empresa, no la ejecución de un derecho. Fórmulas como «user-first» son un compromiso, no un texto contractual.

La diferencia pesa cuando un caso acaba mal. La cortesía comercial depende de la atención que reciba un asunto. Este estuvo visible durante días en X y en la prensa especializada, con marcas de tiempo, datos de transacciones y un desarrollo verificable. Una cuenta con 3.000 euros y sin público no tiene esa palanca.

Un derecho, en cambio, depende de la ley a la que esté sometido el proveedor. Y justo en ese terreno las plataformas se diferencian notablemente para los usuarios europeos.

MiCA y la responsabilidad del exchange por los activos perdidos de sus clientes

Desde que se aplica el reglamento europeo sobre mercados de criptoactivos, los servicios de custodia y negociación solo pueden prestarse en la Unión Europea por proveedores autorizados. La autorización lleva aparejada una obligación que rara vez se lee en el día a día y que resulta decisiva en casos exactamente como este: un custodio autorizado responde ante sus clientes por la pérdida de criptoactivos o de medios de acceso cuando el incidente le es imputable. La separación de los fondos de los clientes respecto del patrimonio propio y una política de custodia documentada pertenecen al mismo conjunto de deberes.

Esta responsabilidad no es automática y no cubre cualquier daño. Presupone que el proveedor esté autorizado y que el incidente caiga en su ámbito de responsabilidad. Una frase de recuperación que un usuario introduce él mismo en una página de cartera falsa no entra ahí. Un medio de acceso que el exchange deja subsistir tras una intrusión detectada se acerca claramente al ámbito del proveedor.

Si tu plataforma queda sujeta a estos deberes no se lee en su publicidad, sino en el registro del supervisor. La BaFin alemana recoge a los proveedores de servicios de criptoactivos autorizados allí en un listado público, y la autoridad europea ESMA lleva el registro para todo el espacio económico.

Solicitud inversa: qué supone para los usuarios europeos el estatus de un exchange sin licencia

Muchas plataformas grandes con amplia oferta de tokens pequeños no tienen autorización en la UE. Oficialmente estos proveedores no hacen publicidad en la Unión, pero aceptan clientes que acuden por iniciativa propia. Esa vía se llama solicitud inversa y está concebida como una excepción estrecha, no como un modelo de negocio.

Para ti como usuario, el estatus tiene consecuencias tangibles. Sin autorización en la UE no hay supervisor al que dirigirte, ni oficina de reclamaciones en tu idioma, ni derecho exigible derivado del catálogo europeo de deberes, y en caso de litigio un foro judicial lejano. Queda la cortesía del proveedor.

Esto no es una recomendación de evitar ni de usar esas plataformas. Es la condición bajo la cual decides cuánto dejas allí. Quien opere ahí porque el par solo existe ahí puede limitar el importe y retirarlo tras la operación.

Claves de API en tu propia cuenta: permisos, vinculación a IP y fecha de caducidad

La gestión de claves está en la mayoría de exchanges bajo los ajustes de cuenta o de seguridad y se llama gestión de API. Allí figura cada clave activa con sus permisos, a menudo con la fecha de creación y la del último uso. Esa lista es justamente el lugar que habría marcado la diferencia en el caso de MEXC.

Tres ajustes deciden el daño que puede causar una clave extraviada. El permiso de retirada es el primero: sin él, una clave puede operar y leer, pero no mover nada fuera del exchange. El segundo es la vinculación a direcciones IP fijas, que solo da validez a una clave desde equipos conocidos. El tercero es una fecha de caducidad, que muchas plataformas imponen ya para que las claves olvidadas mueran solas.

Un cuarto punto es pura higiene: una clave por aplicación, con un nombre reconocible. Quien usa una clave para tres programas no puede revocarla ante una sospecha sin apagarlo todo. Quien en cambio mantiene tres claves con nombre retira la dudosa en segundos.

Software fiscal, rastreador de cartera y bot de trading: qué permisos necesita de verdad una clave

En la gran mayoría de los casos, el programa que conectas necesita bastante menos de lo que pide. Un programa fiscal o un rastreador de cartera lee el historial de operaciones y las posiciones, y se apaña con un permiso de solo lectura. No hay razón de fondo para que un software que calcula ganancias pueda mover criptomonedas.

Un bot de trading necesita el permiso de negociación, porque coloca órdenes. Tampoco él necesita el de retirada. Quien concede ambos a la vez ha creado un acceso capaz de todo lo que él mismo puede hacer, de forma permanente y sin segundo factor.

Qué permisos piden realmente las herramientas fiscales más habituales, y en qué se diferencian, puedes consultarlo en nuestro repaso al software fiscal de criptomonedas y rastreadores de cartera antes de crear tu próxima clave.

Una última nota sobre conexiones que hace tiempo olvidaste: un rastreador que probaste una vez hace dos años conserva hoy su clave. Esos restos se reconocen enseguida en la lista, porque su fecha de último uso queda muy atrás.

La autenticación de dos factores y el límite de su protección

La autenticación de dos factores sigue siendo correcta y necesaria. La protección actúa en la vía de inicio de sesión, que es con diferencia la vía de ataque más frecuente. Una aplicación dedicada es ahí claramente superior al SMS, porque un número de móvil puede ser secuestrado.

Lo que la autenticación de dos factores no cubre son los accesos de máquina y la vía de restablecimiento. Los rodea por diseño, no por un fallo. La seguridad en una plataforma de negociación se compone por tanto de tres capas: la protección del acceso, la gestión de claves y la cuestión de cuánto hay allí depositado.

La tercera capa es la única que tienes por completo en tu mano.

Saldo en el exchange y autocustodia: el reparto tras este caso

Las criptomonedas en un exchange son un crédito frente a una empresa. Las criptomonedas en tu propia cartera son una clave en tu mano. El caso de MEXC no altera de raíz ese viejo equilibrio, pero muestra una superficie de ataque que no existe en la autocustodia. Una cartera de hardware no tiene una interfaz que un atacante pudiera hacer activar en atención al cliente.

A cambio, la autocustodia traslada el riesgo hacia ti. Unas palabras de recuperación perdidas lo están para siempre, y no hay ningún director ejecutivo que ordene un pago de cortesía. El reparto más extendido en la práctica: lo que negocias de forma activa se queda en la plataforma, lo que quieres mantener a más largo plazo reposa en custodia propia.

Para los inversores europeos se añade un punto fiscal. Mover tus propias criptomonedas del exchange a tu cartera no es una venta y, según la lectura habitual, no genera impuesto, porque no hay cambio de propietario. Los datos de adquisición y, con ellos, el plazo de tenencia debes llevarlos tú mismo, porque tras la transferencia ninguna plataforma conoce ya la fecha de compra original. Quien use una herramienta para eso debería exportar el historial antes de cerrar una cuenta.

Claves de API en el exchange de criptomonedas: tus tres próximos pasos

1. En cada exchange donde tengas cuenta, abre la gestión de API y elimina toda clave que no puedas asignar de inmediato a una aplicación en uso. A las que queden, quítales el permiso de retirada y vincúlalas a tu dirección IP. Qué plataformas están bajo supervisión europea lo encuentras en nuestra lista de exchanges de criptomonedas regulados.
2. Fija qué importe puede quedar en una plataforma de negociación y retira el resto. Sirve de orientación el importe cuya pérdida total no te sacaría de la vía. Para la parte que deba quedarse más tiempo, un dispositivo con clave propia es el siguiente paso; las diferencias están en la comparativa de carteras de hardware.
3. Mira cómo se restablece la autenticación de dos factores en tu exchange y activa todas las notificaciones que existan al respecto. Un correo sobre una interfaz recién creada es el único aviso que habría llegado a tiempo en este caso. Si después retiras fondos de la plataforma, la comparativa de carteras de software ayuda a elegir el destino.

El caso de MEXC acabó bien porque pagó una empresa que no tenía que pagar. Esa es la más débil de todas las salvaguardas. La versión sólida consiste en una lista corta de claves activas, un saldo limitado en la plataforma y un exchange cuyo supervisor puedes nombrar.

La confirmación completa de la empresa, con citas de su director ejecutivo, puede leerse en The Crypto Times.

(29 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)