Versiones maliciosas de node-ipc publicadas en npm tras una presunta toma de control de la cuenta de un mantenedor

El 14 de mayo de 2026, se publicaron varias versiones maliciosas del popular paquete npm node-ipc en el registro de npm. Los informes públicos actuales identifican node-ipc@9.1.6, node-ipc@9.2.3 y node-ipc@12.0.1 como versiones comprometidas que contienen una carga ofuscada para robar credenciales. El código malicioso se agregó al paquete CommonJS, node-ipc.cjs, y se activa cuando el paquete se carga mediante require("node-ipc"). Los primeros análisis sugieren que el ataque pudo haber implicado el abuso de la cuenta legítima de un mantenedor de npm, en lugar de un compromiso de la canalización de CI/CD del proyecto. Las organizaciones que instalaron estas versiones o compilaron software a partir de ellas deben considerar potencialmente comprometidos los secretos de desarrolladores, CI/CD, nube, SSH, GitHub, Kubernetes y otros que hayan estado accesibles en esos entornos. Snyk publicó un aviso sobre este problema con el identificador SNYK-JS-NODEIPC-16697063. Los equipos deben usarlo para identificar rutas de dependencias vulnerables y priorizar la corrección.

Componente involucrado

node-ipc es un paquete de Node.js que se usa para la comunicación entre procesos. Históricamente, se ha utilizado ampliamente en todo el ecosistema npm, tanto de forma directa como transitiva.

No es la primera vez que node-ipc se ve involucrado en un incidente de cadena de suministro. En 2022, Snyk analizó el incidente de node-ipc / peacenotwar, en el que un comportamiento similar al protestware afectó a usuarios posteriores. La actividad de mayo de 2026 parece ser independiente. El análisis actual apunta a versiones maliciosas con una carga ofuscada para robar credenciales, no a protestware.

El incidente de 2026 parece ser independiente del de 2022. La carga de 2026 descrita hasta el momento se centra en el robo de credenciales y la exfiltración encubierta, no en el comportamiento de protestware observado en 2022. Los análisis públicos señalan que la carga se inyectó en el punto de entrada de CommonJS y que no dependía de scripts del ciclo de vida de npm, como postinstall.

Versiones afectadas conocidas

Los informes públicos actuales identifican estas tres versiones maliciosas e indican que todas se publicaron el 14 de mayo de 2026. También señalan que el archivo node-ipc.cjs comprometido era idéntico en todas las versiones afectadas.

Cronología

Cómo parece haberse producido el compromiso

La hipótesis pública más sólida es que las versiones maliciosas se publicaron desde una cuenta de mantenedor de npm con permisos legítimos de publicación. StepSecurity informó que las versiones se publicaron desde la cuenta atiertant, que figuraba en la lista de mantenedores, pero no tenía un historial previo de publicaciones de node-ipc.

Upwind y otros informes públicos describieron una posible vía de secuestro de un dominio vencido: el atacante pudo haber vuelto a registrar un dominio asociado al correo electrónico de la cuenta del mantenedor, configurado la recepción de correos y luego usado la recuperación de cuentas de npm para tomar el control de la cuenta.

Las pruebas actuales apuntan al abuso de la identidad de un mantenedor con permisos de publicación en npm. Los análisis públicos sugieren que un dominio de correo electrónico vencido del mantenedor pudo haber permitido recuperar la cuenta, pero la investigación sigue en curso. Esta distinción es importante porque sugiere que no fue necesario comprometer el registro de npm y que el repositorio de código fuente o la canalización de CI/CD del proyecto podrían no haber sido la vía inicial del ataque.

Vector de ataque y comportamiento malicioso

La carga parece haberse insertado en node-ipc.cjs, el paquete CommonJS que usan los consumidores al cargar el paquete con require("node-ipc"). Los análisis públicos indican que el punto de entrada de ESM no se modificó de la misma manera.

A diferencia de muchos incidentes de malware en npm, según los informes, este compromiso no se basó en scripts de instalación como preinstall, install o postinstall. En cambio, la lógica maliciosa se agregó como una expresión de función invocada de inmediato. Esto significa que el código podía ejecutarse al importar el paquete durante la ejecución, en lugar de hacerlo únicamente al instalar la dependencia.

• Identificación de huellas del entorno y del host

• Búsqueda de credenciales locales y archivos confidenciales de desarrolladores

• Recopilación de credenciales de nube, claves SSH, tokens de Kubernetes, configuración de GitHub CLI, estado de Terraform, credenciales de bases de datos, historial de shell y configuraciones de herramientas de IA y desarrollo

• Compresión de los datos recopilados

• Exfiltración de datos a infraestructura controlada por el atacante

StepSecurity informa que la carga apuntaba a más de 90 categorías de credenciales y que exfiltraba los datos recopilados a una infraestructura que usaba el dominio azurestaticprovider[.]net.

Quiénes podrían verse afectados

1. Tu proyecto depende directamente de node-ipc y se resuelve en las versiones 9.1.6, 9.2.3 o 12.0.1.

2. Tu proyecto depende de otra dependencia que, a su vez, incorporó una de las versiones afectadas.

3. Tu canalización de CI/CD, compilación de contenedores, estación de trabajo de desarrollo o caché de paquetes instaló una de las versiones maliciosas.

4. Usas rangos semver que pudieron resolver automáticamente una de las versiones afectadas, como ^9, ~9.1, ~9.2, ^12 o instalaciones sin una versión fija.

5. Ejecutaste rutas de código que cargaron node-ipc mediante la resolución de CommonJS.

Encontrar el paquete solo en un archivo de bloqueo no demuestra que el código malicioso se haya ejecutado, pero basta para iniciar una investigación. Si el paquete se instaló en un entorno de desarrollo o CI/CD con acceso a secretos, asume que las credenciales pudieron quedar expuestas.

Guía de detección

Revisa tu aplicación con Snyk CLI; ejecútalo desde la raíz de tu proyecto.

snyk test

Si monitoreas tu aplicación en la interfaz web de Snyk, recibirás una alerta automática.

Si no, revisa los árboles de dependencias y los archivos de bloqueo para encontrar las versiones afectadas:

npm ls node-ipc

npm ls node-ipc --all 2>/dev/null | grep -E '9\.1\.6|9\.2\.3|12\.0\.1'

grep -E '"node-ipc".*"(9\.1\.6|9\.2\.3|12\.0\.1)"' package-lock.json

grep -E 'node-ipc@(9\.1\.6|9\.2\.3|12\.0\.1)' yarn.lock

grep -E 'node-ipc.*9\.1\.6|9\.2\.3|12\.0\.1' pnpm-lock.yaml

find . -path '*/node_modules/node-ipc/node-ipc.cjs' -exec ls -lh {} \;

Los indicadores de red y host reportados incluyen conexiones salientes a sh.azurestaticprovider[.]net, tráfico saliente a 37.16.75[.]69, tráfico UDP/53 inesperado de procesos de aplicaciones o compilación, directorios temporales que coincidan con $TMPDIR/nt-* y procesos o procesos secundarios que usen la variable de entorno __ntw=1 . Estos indicadores pueden cambiar cuando se desactiva o rota la infraestructura del atacante, por lo que la ausencia de estas señales no debe considerarse una prueba de seguridad.

Mitigación y respuesta

Elimina las versiones maliciosas

• Fija node-ipc en una versión que se sepa que es segura.

• Actualiza los archivos de bloqueo.

• Borra las cachés locales y de paquetes de CI donde puedan persistir los archivos tar maliciosos.

• Vuelve a compilar los artefactos a partir de árboles de dependencias limpios.

Identifica todos los entornos donde se instaló el paquete

• Computadoras portátiles de desarrolladores

• Agentes de CI

• Contenedores de compilación

• Registros internos de artefactos

• Trabajadores de compilación efímeros

• Sistemas de producción, si hubo importaciones durante la ejecución

Rota los secretos expuestos

• Tokens de npm

• Tokens de GitHub

• Credenciales de proveedores de nube

• Claves SSH

• Secretos de CI/CD

• Tokens y archivos kubeconfig de Kubernetes

• Credenciales de bases de datos

• Credenciales de acceso al estado de Terraform

• Credenciales de herramientas de IA y desarrollo

Invalida las sesiones y revisa los registros de acceso

• Revisa los registros de auditoría de la nube.

• Revisa los registros de auditoría de la organización en GitHub.

• Revisa la actividad de la cuenta de npm y el historial de publicaciones de paquetes.

• Busca comportamientos inusuales en trabajos de CI/CD, secretos nuevos, claves de implementación nuevas o publicaciones inesperadas de paquetes.

Refuerza la seguridad del consumo de paquetes

• Usa archivos de bloqueo y compilaciones deterministas.

• Evita que los sistemas de compilación de producción consuman automáticamente versiones de paquetes recién publicadas.

• Considera períodos de espera para actualizar dependencias o políticas de proxy de paquetes internos.

• Exige MFA a quienes publican paquetes en npm.

• Elimina de los proyectos de código abierto a los mantenedores inactivos y los dominios de correo electrónico vencidos.

• Monitorea los cambios en las cuentas de mantenedores y las nuevas publicaciones después de largos períodos de inactividad.

• Analiza y monitorea continuamente tus aplicaciones con Snyk para detectar vulnerabilidades

Por qué importa este incidente

Este incidente es otro ejemplo de cómo los atacantes se enfocan en las relaciones de confianza que hacen funcionar los ecosistemas de código abierto. El paquete malicioso no necesitaba alterar el comportamiento de las aplicaciones para ser eficaz. Al mantener la funcionalidad esperada mientras recopilaba credenciales de forma discreta, el atacante aumentó las probabilidades de que las compilaciones comprometidas y los entornos de desarrollo siguieran funcionando con normalidad.

También pone de relieve una debilidad recurrente de la cadena de suministro: los paquetes inactivos o con poco mantenimiento pueden seguir teniendo un amplio alcance en el ecosistema incluso después de largos períodos sin actividad. Si se puede recuperar, secuestrar o abusar de la identidad de un antiguo mantenedor, los atacantes podrían publicar versiones maliciosas en los grafos de dependencias sin tocar el control de código fuente ni los sistemas de CI/CD.

Evaluación actual

Según la información disponible, este incidente debe tratarse como un compromiso crítico de la cadena de suministro de npm, cuyo principal riesgo es el robo de credenciales de entornos de desarrollo y CI/CD. Las versiones afectadas confirmadas son actualmente node-ipc@9.1.6, node-ipc@9.2.3 y node-ipc@12.0.1. La vía de ataque más probable es el abuso de una cuenta de mantenedor con permisos de publicación, posiblemente mediante la recuperación de un dominio de correo electrónico vencido del mantenedor, aunque la investigación de la causa raíz sigue en curso.

Los equipos deben determinar de inmediato si se instaló alguna versión afectada, rotar los secretos de los entornos expuestos y monitorear posibles ataques posteriores con las credenciales robadas.