Ataque a npm adultera paquetes como chalk y debug para cambiar direcciones de billetera: qué pasó y cómo protegerse

São Paulo, 16 de septiembre de 2025 — El lunes 8 de septiembre, desarrolladores de todo el mundo recibieron una alerta: se habían publicado versiones nuevas de paquetes tan básicos que casi todo proyecto de JavaScript los usa, como chalk y debug, con código malicioso. El objetivo no era robar contraseñas ni derribar servidores. Era más simple y más peligroso para quien maneja cripto: cambiar, en el navegador, la dirección de billetera a la que el usuario pretendía enviar dinero.

Paquetes del mantenedor comprometidos, según Aikido Security; con otros proyectos, Wiz listaba 24 el 9/9

18

Descargas semanales sumadas de los paquetes afectados

2.000 M+

Tiempo en que las versiones maliciosas estuvieron disponibles, según Wiz

~2 h

Redes cuyas direcciones el código intentaba cambiar: Ethereum, Bitcoin, Solana, TRON, Litecoin y Bitcoin Cash

6

Qué ocurrió

npm es el repositorio público de paquetes de JavaScript. Los proyectos de sitios y aplicaciones traen de allí bibliotecas ya hechas y, con ellas, las bibliotecas de las que estas dependen. Eso crea una cadena de suministro: quien vulnera una pieza pequeña y popular llega a miles de programas sin tocarlos.

El mantenedor Josh Junon, conocido como Qix, recibió un correo de phishing que imitaba al soporte de npm, enviado desde un dominio parecido (npmjs.help) registrado tres días antes, el 5 de septiembre. Al seguir el enlace e ingresar credenciales y el código de autenticación en dos pasos, entregó el control de la cuenta. Los atacantes publicaron versiones nuevas de 18 paquetes, entre ellos chalk 5.6.1, debug 4.4.2, ansi-styles, strip-ansi y color-convert. La empresa de seguridad Aikido señaló las versiones a las 13:16 UTC (10:16 en Brasilia), y el mantenedor confirmó la intrusión unas dos horas después. Al día siguiente, JFrog y Wiz informaron que la misma campaña también había alcanzado paquetes de DuckDB, otro proyecto.

1. 05/09/2025Registro del dominio de phishing que imita al soporte de npm.
2. 08/09, cerca de las 13:00 UTCSe toma la cuenta del mantenedor y se publican versiones maliciosas de los paquetes.
3. 08/09, 13:16 UTCAikido señala las versiones adulteradas.
4. 08/09, 15:15 UTCEl mantenedor confirma la intrusión y comienza la limpieza; las versiones estuvieron disponibles unas dos horas, según Wiz.
5. 09/09/2025JFrog y Wiz informan que la campaña también alcanzó paquetes de DuckDB; empresas de seguridad publican listas de indicadores.

Cómo el código cambiaba las direcciones

El código solo actuaba en navegadores, cuando estaba abierta una página que usaba los paquetes. Se enganchaba en funciones que el sitio usa para comunicarse con la red y con la billetera, y alteraba los datos en el camino.

El parecido es el punto central. Quien verifica solo el comienzo y el final de la dirección puede ser engañado por una dirección elegida justamente por tener inicio y final parecidos. Es la misma lógica del envenenamiento de direcciones, pero aplicada dentro del software y no en el historial de la billetera.

Cuánto se llevaron los delincuentes

Poco, según los primeros relatos. Wiz, citando publicaciones de investigadores en redes sociales, describió la ganancia como “mínima”, y no hay un valor consolidado por una fuente primaria. Dos factores ayudan a explicarlo: las versiones estuvieron en línea unas dos horas, y el código afectaba solo páginas de aplicaciones que actualizaron la dependencia y fueron publicadas en ese intervalo, muchas de ellas sin ningún flujo de pago en cripto.

Cómo protegerse al pagar en cripto

Para quien desarrolla, las reglas son: fijar versiones con un archivo de bloqueo (package-lock.json), instalar con npm ci, esperar algunos días antes de adoptar versiones recién publicadas y proteger las cuentas de publicación con llaves de seguridad físicas, que no se entregan en un sitio falso como un código digitado. Para quien solo paga, el principio es otro: la pantalla de la computadora no es prueba de la dirección. Fue la misma lección del ataque a Bybit, en que la pantalla mostraba el destino correcto y la firma autorizaba otro.

1. Verifique la dirección en el dispositivo de la billetera (billetera de hardware o aplicación del celular), no en el sitio ni en la extensión del navegador.
2. Compare la dirección completa, carácter por carácter, con la que el proveedor informó por un canal fuera de la computadora, como una llamada a un teléfono ya conocido.
3. En la red TRON, la dirección TRC-20 empieza con T y tiene 34 caracteres; vea cómo leerla en qué es la red TRON.

La verificación fuera de la computadora vale porque rompe la dependencia de la misma máquina. Un navegador adulterado puede mostrar una dirección cambiada igualmente en el sitio, en el correo abierto en el webmail y en la pantalla de confirmación, pero no altera el mensaje enviado por teléfono ni lo que aparece en el dispositivo de la billetera. El envío de prueba, la lista de billeteras aprobadas y la doble aprobación completan la rutina y están en la guía contra el envenenamiento de direcciones.

Qué muestra el episodio

El caso refuerza un patrón visto en 2025: el eslabón más débil suele ser una persona o una credencial, y no la criptografía. Un correo convincente a una sola persona bastó para alcanzar bibliotecas presentes en incontables proyectos. La respuesta pasó por mantenedores, empresas de seguridad y el propio npm, y las versiones salieron de línea en unas dos horas, pero la verificación final del destino sigue siendo responsabilidad de quien envía el dinero.

• Hackeos
• Billeteras
• Seguridad digital
• Ingeniería social
• Estafas
• TRON
• USDT