El CTO de Ledger, Charles Guillemet, informó en X sobre un ataque a la cadena de suministro que involucra paquetes de NPM de uso generalizado.
Hay un ataque a gran escala en la cadena de suministro en progreso: la cuenta de NPM de un desarrollador de renombre ha sido comprometida. Los paquetes afectados ya se han descargado más de 1 mil millones de veces, lo que significa que todo el ecosistema de JavaScript puede estar en riesgo.
La carga maliciosa funciona...
— Charles Guillemet (@P3b7_) 8 de septiembre de 2025
Según un informe de CoinDesk, algunas versiones comprometidas – que suman más de 1 mil millones de descargas – incluyen código capaz de reemplazar, "sobre la marcha", direcciones de destino en transacciones de criptomonedas, redirigiendo fondos a billeteras controladas por atacantes. Este escenario coincide con las recomendaciones de protección de la cadena de suministro publicadas por organizaciones de la industria como OWASP, que destacan cómo los compromisos de la cadena de suministro pueden tener impactos a gran escala.
Según los datos recopilados por nuestro equipo de inteligencia de amenazas en las últimas 24 horas, han surgido indicadores de compromiso consistentes con la técnica descrita en múltiples repositorios y tuberías de construcción. Los analistas con los que colaboramos también enfatizan que el alcance del incidente se ve amplificado por las dependencias transitivas y el tamaño del registro: el registro de NPM alberga más de 2 millones de paquetes, aumentando la probabilidad de propagación de un módulo comprometido.
Mecanismo de Ataque: Direcciones Cambiadas "Sobre la Marcha"
Dicho esto, la carga maliciosa se activa tanto durante las operaciones en la cadena como en el momento de la generación o firma de la transacción. En la práctica, el malware intercepta la dirección del destinatario y la reemplaza por una que pertenece a los actores maliciosos. El usuario, al ver una pantalla aparentemente "limpia", podría no darse cuenta de que la transacción final envía los fondos a una dirección diferente, una dinámica también confirmada por The Block. Cabe señalar que la manipulación tiene como objetivo permanecer invisible hasta el último paso de confirmación.
Actualización sobre el ataque de NPM: Afortunadamente, el ataque fracasó, con casi ninguna víctima.
Comenzó con un correo electrónico de phishing de un dominio de soporte de npm falso que robó credenciales y dio a los atacantes acceso para publicar actualizaciones de paquetes maliciosos. El código inyectado apuntaba a la actividad de criptografía web,… pic.twitter.com/lOik6k7Dkp
— Charles Guillemet (@P3b7_) 9 de septiembre de 2025
Paquetes involucrados: números, nombres provisionales y distribución
Los análisis iniciales indican que la vulneración ocurrió al explotar la cuenta de un mantenedor con acceso a bibliotecas de uso generalizado. Entre los nombres que se están circulando está, por ejemplo, el paquete error-ex – cuyo perfil oficial se puede ver en npmjs.com – aunque las listas oficiales aún se están actualizando. El impacto se amplifica por el efecto en cascada debido a las dependencias: un solo módulo comprometido puede propagarse a cientos de proyectos, gracias a las cadenas de importación. De hecho, la naturaleza modular del código JavaScript facilita que el problema se propague cuando las dependencias están profundamente anidadas.
Escala de exposición: más de 1 mil millones de descargas acumulativas de versiones potencialmente en riesgo.
Vector: publicaciones en NPM a través de credenciales robadas o pipeline comprometido.
Alcance: bibliotecas principales utilizadas en proyectos web y billeteras.
Las listas oficiales de paquetes y versiones afectados son parciales; se aconseja monitorear los avisos de NPM y los repositorios de los mantenedores. Sin embargo, hasta que se realicen comunicaciones definitivas, sigue siendo prudente considerar que toda la cadena de dependencias está en riesgo.
Impacto en usuarios y negocios
Robo directo de criptomonedas tras el sigiloso reemplazo de la dirección.
La integridad de la aplicación se ha visto comprometida en dApp, extensiones y billeteras de escritorio/web.
Riesgo reputacional para proyectos que integran paquetes contaminados.
Qué hacer de inmediato: lista de verificación de emergencia
Para los usuarios finales (crypto)
Prefiere billeteras que muestren claramente la información de transacción (pantalla y firma clara – Firma Clara), verificando la dirección y la cantidad en el dispositivo antes de confirmar. Para orientación práctica, consulta nuestra guía sobre cómo verificar billeteras de hardware.
Evite la firma ciega y limite el uso de códigos QR no verificados.
Compara la dirección mostrada con una copia segura y utiliza listas blancas para los destinatarios frecuentes.
Esta precaución es crucial porque la confirmación en una billetera de hardware muestra los datos que realmente se están firmando, haciendo evidente cualquier sustitución de dirección por el software anfitrión. En este contexto, la verificación en la pantalla del dispositivo reduce la probabilidad de error o manipulación en la fuente.
Para equipos de desarrollo
Suspender temporalmente las actualizaciones automáticas de dependencias críticas.
Realizar auditorías y revertir las versiones publicadas durante el período sospechoso.
Rotar los tokens NPM y hacer que la activación de 2FA sea obligatoria para los mantenedores y liberadores (ver aquí).
Habilitar sistemas de procedencia para publicaciones y firmar artefactos de construcción.
Cómo verificar si un proyecto está expuesto
Identificar rápidamente las dependencias sospechosas y los rangos de versión instalados es crucial: la exploración oportuna limita el efecto dominó en los pipelines.
Listar versiones instaladas y cadena de dependencias
npm ls error-ex
Verificar vulnerabilidades y avisos conocidos
npm audit –producción
npm audit –json > audit.json
Bloquear actualizaciones no deterministas en CI
npm ci –ignore-scripts
Establecer un umbral de auditoría más estricto
npm config set audit-level=high
Verifique las versiones disponibles y las fechas de publicación
npm view error-ex versions –json
npm view error-ex time –json
En contextos de CI, establecer ignore-scripts=true ayuda a reducir el riesgo de ejecutar scripts maliciosos post-instalación. Dicho esto, es recomendable establecer una base reproducible de inmediato para evitar desviaciones inesperadas. Para una lista de verificación ampliada sobre verificaciones de CI, consulte nuestra página sobre las mejores prácticas de la cadena de suministro.
Fortalecimiento de la cadena de suministro: defensas técnicas recomendadas
Utiliza un archivo de bloqueo determinista (package-lock.json) y despliega con npm ci para asegurar la reproducibilidad.
Habilitar 2FA en NPM para publicaciones y acceso crítico, utilizando tokens con ámbitos limitados (automatización vs. publicar).
Implementar una revisión de código obligatoria y utilizar un pipeline de CI aislado con firma de artefactos.
Adopte sistemas de procedencia, refiriéndose a la documentación oficial sobre la procedencia de paquetes npm y estándares como SLSA.
Utiliza herramientas de escaneo y actualizaciones controladas, como Dependabot, Renovate y sigstore/cosign, donde sea aplicable.
Aplica el principio de menor privilegio para las cuentas de los mantenedores y los bots de lanzamiento.
Cronograma y estado de las investigaciones
La alerta se hizo pública hoy, 8 de septiembre de 2025, y actualmente se están llevando a cabo verificaciones. Se liberarán progresivamente avisos oficiales y listas actualizadas de paquetes y versiones comprometidos. Por lo tanto, se aconseja mantener un enfoque cauteloso, suspendiendo actualizaciones no esenciales hasta que se consoliden los indicadores de compromiso. A la espera de más comentarios, la prioridad sigue siendo contener la exposición y documentar cuidadosamente cada cambio.
Ángulo Crítico: Una Cadena de Confianza Aún Frágil
La cadena de suministro de código abierto sigue siendo vulnerable cuando el acceso a las cuentas y las canalizaciones de publicación no están adecuadamente protegidos. El problema se vuelve particularmente urgente cuando, en 2025, numerosas publicaciones aún ocurren sin la adopción sistemática de medidas como 2FA, procedencia y revisiones rigurosas.
Mientras la confianza se dé por sentada, cada proyecto seguirá expuesto al riesgo generado por otros. Sin embargo, incluso pequeñas mejoras en los procesos pueden reducir significativamente la superficie de ataque.
El Punto
Este episodio destaca cuán crítica es la seguridad de la cadena de suministro en el software de código abierto. Mientras las investigaciones estén en curso, la prioridad será limitar las superficies de ataque, verificar cuidadosamente los datos de transacciones en pantalla y consolidar los procesos de publicación mediante la adopción de 2FA, lockfile y sistemas de procedencia.
La transparencia de los avisos, como han señalado numerosos expertos, será crucial para medir el impacto real y restaurar la confianza en el ecosistema. En este contexto, la adherencia a las mejores prácticas sigue siendo la única salvaguarda inmediata.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
NPM bajo ataque: paquetes de JavaScript comprometidos, direcciones de criptomonedas secuestradas. Advertencia de Ledger...
El CTO de Ledger, Charles Guillemet, informó en X sobre un ataque a la cadena de suministro que involucra paquetes de NPM de uso generalizado.
Hay un ataque a gran escala en la cadena de suministro en progreso: la cuenta de NPM de un desarrollador de renombre ha sido comprometida. Los paquetes afectados ya se han descargado más de 1 mil millones de veces, lo que significa que todo el ecosistema de JavaScript puede estar en riesgo.
La carga maliciosa funciona...
— Charles Guillemet (@P3b7_) 8 de septiembre de 2025
Según un informe de CoinDesk, algunas versiones comprometidas – que suman más de 1 mil millones de descargas – incluyen código capaz de reemplazar, "sobre la marcha", direcciones de destino en transacciones de criptomonedas, redirigiendo fondos a billeteras controladas por atacantes. Este escenario coincide con las recomendaciones de protección de la cadena de suministro publicadas por organizaciones de la industria como OWASP, que destacan cómo los compromisos de la cadena de suministro pueden tener impactos a gran escala.
Según los datos recopilados por nuestro equipo de inteligencia de amenazas en las últimas 24 horas, han surgido indicadores de compromiso consistentes con la técnica descrita en múltiples repositorios y tuberías de construcción. Los analistas con los que colaboramos también enfatizan que el alcance del incidente se ve amplificado por las dependencias transitivas y el tamaño del registro: el registro de NPM alberga más de 2 millones de paquetes, aumentando la probabilidad de propagación de un módulo comprometido.
Mecanismo de Ataque: Direcciones Cambiadas "Sobre la Marcha"
Dicho esto, la carga maliciosa se activa tanto durante las operaciones en la cadena como en el momento de la generación o firma de la transacción. En la práctica, el malware intercepta la dirección del destinatario y la reemplaza por una que pertenece a los actores maliciosos. El usuario, al ver una pantalla aparentemente "limpia", podría no darse cuenta de que la transacción final envía los fondos a una dirección diferente, una dinámica también confirmada por The Block. Cabe señalar que la manipulación tiene como objetivo permanecer invisible hasta el último paso de confirmación.
Actualización sobre el ataque de NPM: Afortunadamente, el ataque fracasó, con casi ninguna víctima.
Comenzó con un correo electrónico de phishing de un dominio de soporte de npm falso que robó credenciales y dio a los atacantes acceso para publicar actualizaciones de paquetes maliciosos. El código inyectado apuntaba a la actividad de criptografía web,… pic.twitter.com/lOik6k7Dkp
— Charles Guillemet (@P3b7_) 9 de septiembre de 2025
Paquetes involucrados: números, nombres provisionales y distribución
Los análisis iniciales indican que la vulneración ocurrió al explotar la cuenta de un mantenedor con acceso a bibliotecas de uso generalizado. Entre los nombres que se están circulando está, por ejemplo, el paquete error-ex – cuyo perfil oficial se puede ver en npmjs.com – aunque las listas oficiales aún se están actualizando. El impacto se amplifica por el efecto en cascada debido a las dependencias: un solo módulo comprometido puede propagarse a cientos de proyectos, gracias a las cadenas de importación. De hecho, la naturaleza modular del código JavaScript facilita que el problema se propague cuando las dependencias están profundamente anidadas.
Escala de exposición: más de 1 mil millones de descargas acumulativas de versiones potencialmente en riesgo.
Vector: publicaciones en NPM a través de credenciales robadas o pipeline comprometido.
Alcance: bibliotecas principales utilizadas en proyectos web y billeteras.
Las listas oficiales de paquetes y versiones afectados son parciales; se aconseja monitorear los avisos de NPM y los repositorios de los mantenedores. Sin embargo, hasta que se realicen comunicaciones definitivas, sigue siendo prudente considerar que toda la cadena de dependencias está en riesgo.
Impacto en usuarios y negocios
Robo directo de criptomonedas tras el sigiloso reemplazo de la dirección.
La integridad de la aplicación se ha visto comprometida en dApp, extensiones y billeteras de escritorio/web.
Riesgo reputacional para proyectos que integran paquetes contaminados.
Qué hacer de inmediato: lista de verificación de emergencia
Para los usuarios finales (crypto)
Prefiere billeteras que muestren claramente la información de transacción (pantalla y firma clara – Firma Clara), verificando la dirección y la cantidad en el dispositivo antes de confirmar. Para orientación práctica, consulta nuestra guía sobre cómo verificar billeteras de hardware.
Evite la firma ciega y limite el uso de códigos QR no verificados.
Compara la dirección mostrada con una copia segura y utiliza listas blancas para los destinatarios frecuentes.
Esta precaución es crucial porque la confirmación en una billetera de hardware muestra los datos que realmente se están firmando, haciendo evidente cualquier sustitución de dirección por el software anfitrión. En este contexto, la verificación en la pantalla del dispositivo reduce la probabilidad de error o manipulación en la fuente.
Para equipos de desarrollo
Suspender temporalmente las actualizaciones automáticas de dependencias críticas.
Realizar auditorías y revertir las versiones publicadas durante el período sospechoso.
Rotar los tokens NPM y hacer que la activación de 2FA sea obligatoria para los mantenedores y liberadores (ver aquí).
Habilitar sistemas de procedencia para publicaciones y firmar artefactos de construcción.
Cómo verificar si un proyecto está expuesto
Identificar rápidamente las dependencias sospechosas y los rangos de versión instalados es crucial: la exploración oportuna limita el efecto dominó en los pipelines.
Listar versiones instaladas y cadena de dependencias
npm ls error-ex
Verificar vulnerabilidades y avisos conocidos
npm audit –producción
npm audit –json > audit.json
Bloquear actualizaciones no deterministas en CI
npm ci –ignore-scripts
Establecer un umbral de auditoría más estricto
npm config set audit-level=high
Verifique las versiones disponibles y las fechas de publicación
npm view error-ex versions –json
npm view error-ex time –json
En contextos de CI, establecer ignore-scripts=true ayuda a reducir el riesgo de ejecutar scripts maliciosos post-instalación. Dicho esto, es recomendable establecer una base reproducible de inmediato para evitar desviaciones inesperadas. Para una lista de verificación ampliada sobre verificaciones de CI, consulte nuestra página sobre las mejores prácticas de la cadena de suministro.
Fortalecimiento de la cadena de suministro: defensas técnicas recomendadas
Utiliza un archivo de bloqueo determinista (package-lock.json) y despliega con npm ci para asegurar la reproducibilidad.
Habilitar 2FA en NPM para publicaciones y acceso crítico, utilizando tokens con ámbitos limitados (automatización vs. publicar).
Implementar una revisión de código obligatoria y utilizar un pipeline de CI aislado con firma de artefactos.
Adopte sistemas de procedencia, refiriéndose a la documentación oficial sobre la procedencia de paquetes npm y estándares como SLSA.
Utiliza herramientas de escaneo y actualizaciones controladas, como Dependabot, Renovate y sigstore/cosign, donde sea aplicable.
Aplica el principio de menor privilegio para las cuentas de los mantenedores y los bots de lanzamiento.
Cronograma y estado de las investigaciones
La alerta se hizo pública hoy, 8 de septiembre de 2025, y actualmente se están llevando a cabo verificaciones. Se liberarán progresivamente avisos oficiales y listas actualizadas de paquetes y versiones comprometidos. Por lo tanto, se aconseja mantener un enfoque cauteloso, suspendiendo actualizaciones no esenciales hasta que se consoliden los indicadores de compromiso. A la espera de más comentarios, la prioridad sigue siendo contener la exposición y documentar cuidadosamente cada cambio.
Ángulo Crítico: Una Cadena de Confianza Aún Frágil
La cadena de suministro de código abierto sigue siendo vulnerable cuando el acceso a las cuentas y las canalizaciones de publicación no están adecuadamente protegidos. El problema se vuelve particularmente urgente cuando, en 2025, numerosas publicaciones aún ocurren sin la adopción sistemática de medidas como 2FA, procedencia y revisiones rigurosas.
Mientras la confianza se dé por sentada, cada proyecto seguirá expuesto al riesgo generado por otros. Sin embargo, incluso pequeñas mejoras en los procesos pueden reducir significativamente la superficie de ataque.
El Punto
Este episodio destaca cuán crítica es la seguridad de la cadena de suministro en el software de código abierto. Mientras las investigaciones estén en curso, la prioridad será limitar las superficies de ataque, verificar cuidadosamente los datos de transacciones en pantalla y consolidar los procesos de publicación mediante la adopción de 2FA, lockfile y sistemas de procedencia.
La transparencia de los avisos, como han señalado numerosos expertos, será crucial para medir el impacto real y restaurar la confianza en el ecosistema. En este contexto, la adherencia a las mejores prácticas sigue siendo la única salvaguarda inmediata.