Respuesta rápida: Los ataques a la cadena de suministro de Npm funcionan comprometiendo una cuenta de mantenedor de confianza o una CI/CD token, publicando una versión maliciosa de un paquete en el que los desarrolladores ya confían, y dejando que los scripts de instalación o la lógica del gusano de ese paquete hagan el resto. Entre agosto de 2025 y mediados de 2026, este patrón produjo la mayor ola de ataques a la cadena de suministro de paquetes npm en la historia del registro, incluido el secuestro de chalk/debug, el Gusano Shai-Huludy malware de estado nación oculto en un paquete descargado 100 millones de veces por semana. La solución no es escanear el código después de que se descarga. Es detectar paquetes maliciosos antes de que se instalen y vigilar el pipeline por el comportamiento exacto que comparten estos ataques.
Cada instalación es un acto de confianza, y los atacantes lo saben.
Un desarrollador ejecuta npm instalarDetrás de ese comando se esconde un árbol de dependencias con cientos, a veces miles, de paquetes, la mayoría escritos y mantenidos por personas que el desarrollador jamás conocerá. Nadie revisa ese árbol línea por línea. Nadie tiene tiempo para hacerlo.
Esa confianza es el objetivo. Para un atacante es más barato realizar un ataque de phishing a un mantenedor de npm con 2.6 millones de descargas semanales que encontrar una vulnerabilidad de día cero en el firewall de una empresa Fortune 500. Los ataques a la cadena de suministro de npm explotan precisamente esta asimetría, y la ola de 2025-2026 muestra hasta qué punto se ha extendido esa explotación: desde el typosquatting aislado hasta gusanos que se autopropagan que publican sus propios paquetes maliciosos más rápido de lo que cualquier ser humano puede reaccionar.
¿Qué se considera un ataque a la cadena de suministro de npm?
Un ataque a la cadena de suministro de npm es cualquier incidente en el que un atacante inserta código malicioso en la distribución de npm. pipeline en lugar de en el propio código fuente del objetivo, de modo que el malware llega disfrazado como una actualización de dependencia rutinaria. El punto de entrada suele ser una de tres cosas: credenciales robadas de un mantenedor, una publicación robada o CI/CD token o una compilación comprometida pipeline que se deja engañar para que publique en nombre del atacante. Dado que los paquetes npm incorporan automáticamente dependencias transitivas, un solo paquete comprometido puede llegar a aplicaciones que nunca lo declararon como dependencia directa.
Cronología: los mayores ataques a la cadena de suministro de npm entre 2025 y 2026.
El patrón detrás de cada ataque a la cadena de suministro de paquetes npm
Si eliminamos los detalles, casi todos los incidentes anteriores siguen los mismos cuatro pasos:
- Compromete una identidad, no un sistema. Un mantenedor víctima de phishing, un token npm filtrado, un PAT de GitHub robado o un token OIDC extraído de CI/CD Memoria del corredor. El atacante no daña el registro. Toma prestada la clave de acceso de otra persona.
- Publique bajo un nombre en el que los desarrolladores ya confían. No es necesario recurrir al typosquatting cuando el nombre real del paquete funciona. Esto es lo que hace que estos ataques sean tan efectivos contra las actualizaciones automatizadas. pipelines: La actualización parece completamente legítima.
- Corre antes de que alguien lo revise. Los scripts de instalación maliciosos, las cargas útiles ofuscadas o el código latente que solo se activa bajo condiciones específicas se ejecutan en el momento npm instalar Se ejecuta, a menudo en el ordenador portátil de un desarrollador, mucho antes de que un análisis de seguridad programado lo detecte.
- Persistir y, cada vez más, propagar. Shai-Hulud y sus descendientes utilizan las credenciales que roban para publicar automáticamente el siguiente paquete infectado, convirtiendo una única vulnerabilidad en una reacción en cadena a través del gráfico de dependencias.
Por qué las defensas habituales no lo entienden
La mayoría de las herramientas de seguridad de aplicaciones se crearon para analizar lo que ya está en el repositorio: CVE conocidos, patrones de código estático, problemas de licencia. Eso es necesario, pero estructuralmente llega demasiado tarde para esta clase de ataque. Para cuando un escáner ve una dependencia, el script de instalación puede que ya se haya ejecutado en la máquina de un desarrollador. Los antivirus y EDR tradicionales monitorean el sistema operativo, no los registros de paquetes, por lo que no tienen el concepto de una "nueva versión de npm" como una unidad de riesgo. Y como muestran los incidentes de TanStack y Red Hat, incluso las certificaciones de integridad de compilación como SLSA provenance No sirven de nada cuando el atacante ha capturado legítimamente la identidad de quien las firma: la firma es válida, pero el paquete sigue siendo malicioso.
La vulnerabilidad que explotan estos ataques a la cadena de suministro de npm reside específicamente en el momento de la publicación y la instalación, antes de que exista una firma para el malware y antes de que el paquete se haya ejecutado en algún lugar donde un escáner tradicional buscaría.
Cómo detener el próximo ataque a la cadena de suministro de npm
Parte de esto es disciplina de procesos que cualquier equipo de ingeniería puede adoptar hoy en día:
- Dependencias de pines y commit archivos de bloqueo, por lo que una actualización automática no puede instalar silenciosamente una versión maliciosa recién publicada.
- Deshabilitar o aislar los scripts posteriores a la instalación. Por defecto, la mayoría de los paquetes no necesitan ejecutar código arbitrario en el momento de la instalación.
- Implementar autenticación multifactor (MFA) basada en hardware para las cuentas de publicación de npm., cerrando la ruta de phishing exacta que comprometió las cuentas de chalk, debug y Qix.
- Alcance y rotación CI/CD tokens agresivamentey tratar los tokens OIDC en la memoria del ejecutor como una credencial que merece protección, no como un detalle de implementación.
- Esté atento al patrón de desbloqueo, inyección y bloqueo. in CI/CD: una regla de protección de rama deshabilitada, una commit empujado, la regla reactivada, todo en un lapso de tiempo ajustado. Es una característica recurrente de pipeline-compromiso en la cadena de suministro de nivel.
Donde se agota la disciplina de los procesos
La disciplina en los procesos reduce la exposición. No detecta un paquete malicioso en el momento de su publicación, ni un gusano que ya se está propagando por la red más rápido de lo que un humano puede analizar. Esa es la función para la que está diseñada la seguridad de la cadena de suministro de Xygeni.
xygenis MEW (Alerta Temprana de Malware) Analiza continuamente los nuevos paquetes publicados en npm, PyPI y Maven, detectando el malware antes de que exista una firma en lugar de después, y alimentando las amenazas confirmadas de vuelta a xygenis Motor de detección propio. El Firewall de dependencia Analiza npm, PyPI, Maven, NuGet y RubyGems en tiempo real y bloquea las instalaciones maliciosas antes de que lleguen al equipo de un desarrollador o a una compilación. CI/CD Detección de anomalías relojes pipelines para exactamente el patrón de comportamiento detrás de incidentes como el compromiso de TanStack, incluida la secuencia de desbloqueo-inyección-rebloqueo, con un registro de auditoría completo. Y porque Xygeni Clasificación y remediación mediante inteligencia artificial Esto también se aplica a los resultados de escáneres de terceros; los equipos no tienen que desechar las herramientas existentes para subsanar esta deficiencia.
Preguntas frecuentes: ataques a la cadena de suministro de npm
¿Qué es un ataque a la cadena de suministro de npm?
Es un ataque donde el código malicioso llega a una aplicación objetivo a través de una dependencia npm confiable en lugar de a través del propio código del objetivo, generalmente porque un atacante comprometió la cuenta de un mantenedor, un token de publicación o un CI/CD pipelineidentidad de.
¿Cuál fue el mayor ataque a la cadena de suministro de npm?
En cuanto a su alcance, el secuestro de chalk/debug de septiembre de 2025 se encuentra entre los más grandes: 18 paquetes con un total de 2.6 millones de descargas semanales se vieron comprometidos a través de una única cuenta de mantenedor robada mediante phishing. En términos de novedad técnica, Shai-Hulud representó un punto de inflexión más significativo, al ser el primer gusano autopropagante en la historia de npm.
¿Cómo suele comenzar un ataque a la cadena de suministro de paquetes npm?
Casi siempre con una identidad robada: un mantenedor víctima de phishing, un token de publicación filtrado o un token robado. CI/CD credenciales como un token OIDC extraído de la memoria de un ejecutor, en lugar de una intrusión técnica en npm en sí.
¿Pueden un antivirus o un EDR detener un ataque a la cadena de suministro de npm?
No de forma fiable. EDR monitoriza el sistema operativo y no reconoce los registros de paquetes, y el antivirus se basa en firmas, lo que provoca fallos ante el malware publicado antes de que exista ninguna firma. Para detener este tipo de ataque, es necesario monitorizar el malware en el punto de publicación e instalación, no solo en el dispositivo final.
Does SLSA provenance ¿O la certificación de compilación lo impide?
Esto demuestra que pipeline El archivo en sí no fue manipulado durante la compilación. Esto no prueba que la identidad que activó la compilación no estuviera comprometida, como demostraron los incidentes de TanStack y Red Hat con las certificaciones válidas adjuntas a los paquetes maliciosos.
¿Cómo puede un equipo detectar un paquete npm malicioso antes de que se instale?
Mediante la ejecución de análisis continuos de malware previos a la firma en los paquetes recién publicados, que es para lo que están diseñados un sistema de alerta temprana de malware y un cortafuegos de dependencias, en lugar de depender únicamente del escaneo de vulnerabilidades posterior al análisis del código que ya se encuentra en un repositorio.
Por dónde empezar
Los ataques a la cadena de suministro de Npm no se están ralentizando, y la tendencia desde Shai-Hulud apunta hacia una mayor automatización, no hacia una menor. Los equipos mejor posicionados para la próxima campaña son aquellos que dejaron de tratar cada instalación de npm como un evento rutinario y comenzaron a vigilar el registro, el pipeliney el punto final como una superficie de ataque conectada.
El plan para desarrolladores de Xygeni incluye cobertura MEW y Dependency Firewall. Para hasta 25 repositorios sin costo alguno. Es un buen lugar para ver qué hay ya en un árbol de dependencias.
