A principios de septiembre de 2025, el mundo de JavaScript se enfrentó a uno de los ataques más peligrosos de los últimos años. Los atacantes obtuvieron acceso a la cuenta de un desarrollador popular y subieron a NPM nuevas versiones de paquetes fundamentales que contenían código malicioso. Estos paquetes se utilizan miles de millones de veces cada semana, y el ataque podría haber provocado un robo masivo a usuarios de servicios de criptomonedas.
Afortunadamente, gracias a los errores de los hackers y a la rápida reacción de la comunidad, el daño fue mínimo. El equipo editorial de Quickex reconstruyó la cronología de los hechos y descubrió por qué todo terminó de manera relativamente indolora.
Sigue cómo el precio de Bitcoin reacciona a las sacudidas del mercado con Quickex.
Cómo se desarrolló el ataque
El primero en informar de lo que estaba ocurriendo la noche del 8 de septiembre fue Charles Guillaume, CTO de Ledger. Advirtió que la cuenta de un desarrollador conocido había sido comprometida y que se habían subido a NPM versiones infectadas de herramientas como chalk, debug, ansi-styles y strip-ansi. Estos paquetes forman parte de la base de la mayoría de las aplicaciones web, por lo que la infección amenazaba a todo el ecosistema.
Más tarde se supo que los hackers accedieron a la cuenta a través de un correo electrónico de phishing. Imitaba un mensaje del soporte de NPM y conducía a una página de inicio de sesión falsa.
NPM (Node Package Manager) es el mayor catálogo de paquetes de JavaScript, donde los desarrolladores publican y descargan módulos de código listos. Por ejemplo, chalk se usa para el formato de texto en color, debug para el registro, y ansi-styles y strip-ansi para trabajar con caracteres de control de la consola. Cuando los atacantes publicaron las nuevas versiones, estas se instalaron automáticamente en los proyectos si los desarrolladores no habían fijado revisiones anteriores.
A medida que se difundían las noticias del ataque, los proyectos cripto se apresuraron a publicar en sus redes sociales que el incidente no los había afectado.
Cómo funcionaba el código malicioso
El programa incrustado actuaba como un crypto-clipper: un tipo de ataque que reemplaza la dirección de una cartera en una transacción. El usuario cree que envía fondos a su propia cuenta o a un amigo, pero en realidad el dinero va a la dirección del atacante.
StarPlatinum analizó en detalle la mecánica. Según él, el código tenía dos modos.
- En el modo “pasivo”, reemplazaba direcciones directamente en las interfaces de las aplicaciones.
- En el modo “activo”, interceptaba las transacciones antes de la firma y cambiaba los datos de destino.
Para enmascararse, utilizaba el algoritmo de Levenshtein para elegir las cadenas más parecidas: coincidían los primeros y últimos caracteres de la dirección, lo que hacía la sustitución casi imperceptible.
También señaló cuentas específicas a las que debían enviarse los fondos robados: la principal, 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976, y varias direcciones de reserva.
En el momento de la publicación del bloguero, se habían registrado transferencias a estas carteras, pero los fondos permanecían inmóviles.
Los desarrolladores se enteraron por primera vez del problema cuando empezaron a fallar las compilaciones automáticas. En los registros aparecían errores inusuales como “fetch is not defined”. La comprobación reveló código ofuscado y funciones sospechosas relacionadas con Ethereum y Solana.
Por qué el daño fue mínimo
Aunque la idea del ataque parecía peligrosa, en la práctica no funcionó. El código resultó demasiado inestable y rompía los procesos de compilación. Esto permitió a la comunidad detectar rápidamente las anomalías y bloquear las versiones infectadas.
Charles Guillaume aclaró después que el ataque había fracasado de hecho: hubo muy pocas víctimas. Según él, el código malicioso estaba dirigido a operaciones cripto y reemplazaba direcciones directamente en las respuestas de red, pero debido a errores de los desarrolladores-hackers se activaba de forma impredecible.
Arkham estimó que los atacantes lograron robar solo 159 $. El dinero llegó a las carteras que habían aparecido en los informes de Ledger. La cantidad es insignificante en comparación con la magnitud del riesgo potencial, pero el episodio mostró lo cerca que estuvo el ecosistema de una crisis grave.
Saldo de la cartera cripto de los atacantes, según Arkham
El papel de las carteras hardware
El mayor riesgo fue para los usuarios de carteras de software que firman transacciones directamente en el navegador. Allí, la sustitución de la dirección podía pasar casi desapercibida. La situación era muy diferente para quienes usaban dispositivos hardware para almacenar las claves.
Una cartera hardware muestra al usuario todos los datos de la operación en su propia pantalla, y la confirmación se realiza con un botón físico. Incluso si una aplicación sustituye la dirección, el dispositivo muestra al verdadero destinatario. Un usuario atento notará inmediatamente la discrepancia y cancelará la firma.
Según Guillaume, funciones como Clear Signing y las comprobaciones de transacciones integradas convierten a las soluciones hardware en una barrera clave contra este tipo de ataques.
Una lección para la comunidad cripto
Esta historia recuerda que la vulnerabilidad de la cadena de suministro sigue siendo el principal riesgo para la industria. Un solo compromiso de la cuenta de un desarrollador puede poner en peligro a millones de usuarios en todo el mundo.
De toda la situación se pueden extraer tres lecciones principales:
- Los desarrolladores deben fijar las versiones de dependencias, usar compilaciones reproducibles y revisar cuidadosamente las actualizaciones de las herramientas fundamentales.
- Los poseedores de criptomonedas deben guardar sus activos en carteras hardware y verificar cuidadosamente las direcciones en la pantalla del dispositivo antes de cada firma.
Las cuentas de desarrolladores en el ecosistema NPM deben protegerse con llaves de seguridad y autenticación multifactor para que el phishing no lleve a una brecha.
Conclusión
El ataque a NPM mostró lo frágil que puede ser toda la infraestructura: miles de millones de instalaciones dependían de una sola cuenta. Esta vez el daño se limitó a 159 $, pero la próxima podría ser diferente.
La suerte y los errores de los atacantes no sustituyen a la seguridad sistemática. Por eso, tanto desarrolladores como usuarios deben tomar medidas para que los nuevos ataques no los sorprendan desprevenidos.
Encuentra el mejor tipo de cambio de criptomonedas en Quickex.