¿Qué controles detienen realmente a axios, jscrambler, Shai-Hulud y Miasma?

Principales conclusiones

• «Third Coming» y «Miasma» se valieron de vías de publicación de CI de confianza, en lugar de tokens de mantenedor de larga duración sustraídos.
• Un registro que filtre el contenido de las publicaciones puede detectar esas publicaciones incluso cuando la certificación sea válida.
• En el caso de los paquetes cubiertos por SecureChain, recompilar a partir de código fuente verificado evita que se vuelva a publicar en tu compilación utilizando credenciales robadas.
• Un periodo de cuarentena solo sirve de algo si la versión maliciosa se retira antes de que expire el plazo.

Las vulnerabilidades de npm se producen con tanta frecuencia que siempre surge la misma pregunta: ¿habría evitado esto realmente un registro seguro de npm? La respuesta varía en función del mecanismo, que es la parte que la mayoría de los proveedores omiten en sus afirmaciones.

En este artículo se analizan los controles reales de SecureChain frente a cuatro incidentes de 2026: axios, jscrambler, la «Tercera Venida» de Shai-Hulud y Miasma. Cada uno de ellos se asocia al mecanismo que lo detecta, junto con el nivel de confianza que merece dicha asociación.

Dos causas fundamentales, no cuatro incidentes distintos

Si clasificamos las cuatro campañas según su mecanismo, se dividen en dos grupos, no en cuatro.

Tanto en el caso de Axios como en el de Jscrambler, todo se redujo a unas credenciales de publicación robadas que se utilizaron directamente contra el registro, eludiendo por completo el propio proceso de integración continua (CI) del proyecto. En el caso de Axios, un atacante accedió al ordenador del mantenedor principal mediante una campaña de ingeniería social dirigida y, a continuación, publicó manualmente dos versiones maliciosas el 31 de marzo. El repositorio de código fuente nunca fue alterado, y no hay ningún commit ni etiqueta detrás de ninguna de las dos versiones. El incidente de jscrambler, ocurrido en julio, siguió el mismo patrón. Jscrambler confirmó posteriormente que un atacante utilizó una credencial de publicación de npm comprometida para publicar cinco versiones maliciosas en unas tres horas, de nuevo sin que hubiera nada detrás de ellas en el repositorio.

«Third Coming» y «Miasma» no encajan en ese patrón, y esa laguna es la razón por la que existe este artículo, en lugar de limitarme a enlazar a los informes. Ambos vulnerabilidades llegaron al proceso de compilación en lugar de al token de npm de un mantenedor. En el caso de Bitwarden, la vía de acceso fue una acción de GitHub de Checkmarx comprometida que ya se utilizaba en el propio proceso de compilación de Bitwarden; posteriormente, el flujo de trabajo de lanzamiento se modificó en repetidas ocasiones para publicar un archivo tar precompilado a través de la ruta de publicación de npm de Bitwarden, respaldada por OIDC. En el caso de Miasma, al menos 32 paquetes pertenecientes al ámbito @redhat-cloud-services de Red Hat distribuyeron versiones maliciosas el 1 de junio, después de que se comprometiera la cuenta de GitHub de un empleado de Red Hat. El atacante envió commits huérfanos, que eludieron por completo la revisión de código, y luego los publicó a través de la ruta OIDC de GitHub Actions del repositorio. Ninguno de los atacantes necesitó las credenciales npm de un mantenedor para que la publicación pareciera legítima.

Esa distinción es importante a la hora de realizar una evaluación. Miasma es el ejemplo más claro. Wiz detectó que el flujo de trabajo inyectado solicitaba un token OIDC y publicaba paquetes con certificados de procedencia SLSA válidos, ya que el flujo de trabajo que los generó era, en realidad, el proceso de integración continua (CI) legítimo, que simplemente se había activado a raíz de una confirmación que nadie había autorizado.

El caso de «Third Coming» es más confuso. Endor Labs revisó el historial público de commits y descubrió que el flujo de trabajo de publicación se había editado cinco veces seguidas para conseguir publicar un archivo tar por etapas; en uno de esos intentos se eliminó por completo el indicador de procedencia, y el análisis se niega explícitamente a atribuir la publicación exitosa a ninguna ejecución concreta ni a interpretarse como una cronología firmada de respuesta a incidentes.

En cualquier caso, la cuestión sigue siendo válida. Sustituir los tokens de larga duración por «Trusted Publishing» es precisamente lo que se recomienda tras un incidente de robo de credenciales como el de Axios, y ambas campañas ponen de manifiesto hasta dónde llega ese consejo, ya que un proceso de publicación comprometido puede generar una publicación que parezca legítima, independientemente de si finalmente se le adjunta o no un certificado válido. Un registro que solo comprobara la presencia de un certificado válido habría pasado por alto Miasma por completo, y tampoco se puede dar por sentado que hubiera detectado Third Coming.

La tradición de poner nombres también continuó. En agosto surgió otra campaña bajo el lema «Here We Go Again». Se trata de un caso independiente, no de una repetición de «Third Coming».

Cómo un registro seguro de npm detecta lo que llega al proceso de integración

Esta es la parte que resulta relevante para «Third Coming» y «Miasma», ya que ninguno de los dos detecta si una publicación procede de un flujo de trabajo de confianza. Ambos utilizaban rutas de publicación de CI de confianza.

Cuándo deja de ser útil bloquear los scripts de instalación

npm ejecuta automáticamente los scripts de instalación de un paquete a menos que algo lo impida, y ese es el mecanismo al que recurrieron en primer lugar la mayoría de estas campañas. La dependencia maliciosa de axios se activaba desde un hook «postinstall». Las tres primeras versiones infectadas de jscrambler utilizaban «preinstall», al igual que la CLI de Bitwarden con puerta trasera y la oleada principal de versiones de Miasma.

A fecha de npm 12, que se lanzó en julio de 2026, los scripts de instalación de dependencias están desactivados por defecto. Los procesos «preinstall», «install» y «postinstall» ya no se ejecutan a menos que un proyecto los apruebe explícitamente, y npm también bloquea la reconstrucción implícita de node-gyp que realiza un archivo de nivel raíz binding.gyp archivo utilizado para activar la acción. Esa segunda parte no es mera teoría en este caso, ya que el informe de seguimiento de Wiz del 4 de junio se refería a una nueva oleada de paquetes «Miasma» que hacían uso indebido de binding.gyp para ejecutar código durante la instalación, que es precisamente lo que ocurre cuando los escáneres solo leen el bloque de scripts. En los clientes más antiguos, --ignore-scripts abarca el subconjunto de scripts del ciclo de vida y nada más allá de ello.

Luego está el límite, y jscrambler lo demostró en el mismo incidente. A partir de la versión 8.18.0, el atacante trasladó el mismo dropper de la fase previa a la instalación a una función autoejecutable situada al principio de dist/index.js, así que se ejecutó al importarlo o al utilizarlo desde la línea de comandos, en lugar de durante la instalación, y todo salió a la perfección npm install --ignore-scripts. Los atacantes pueden mover la carga maliciosa. Bloquear los scripts de instalación no la elimina del paquete.

Por qué el control de contenidos pasa por alto la certificación

El control que realmente responde a «Third Coming» y «Miasma» se sitúa un paso antes y analiza la versión en lugar del editor. La revisión de contenidos puede detectar ganchos de instalación inesperados, código ofuscado sin motivo aparente, discrepancias entre el artefacto publicado y el código fuente del proyecto, y anomalías de una versión a otra. La versión de Bitwarden muestra lo evidente que puede llegar a ser esta última señal, ya que la comparación recursiva de Endor Labs encontró package.json Se anunciaba la versión 2026.4.0, mientras que la CLI incluida seguía indicando la versión 2026.3.0 en sus metadatos empaquetados, lo que sugiere que se volvió a empaquetar mucho antes de que nadie descompilara nada.

Según la propia explicación de SecureChain sobre este paso, cada paquete se recompila desde el código fuente en entornos reforzados y aislados, y se somete a un análisis para detectar malware conocido, patrones de código sospechosos y riesgos de la cadena de suministro; todo aquello que no supere la inspección se bloquea antes de que llegue a tu entorno. Este tipo de análisis no tiene en cuenta si una publicación ha llegado a través de un token personal secuestrado o de un canal de integración continua (CI) comprometido con una certificación impecable, ya que la certificación no es lo que se comprueba.

El nivel de confianza en este caso es de moderado a alto, con la misma salvedad que se aplica al bloqueo de scripts. Se trata de una detección, y la detección conlleva una tasa de falsos negativos. El malware puede retrasar, camuflar o fragmentar su comportamiento, y el cambio de estrategia de jscrambler en pleno incidente es un buen recordatorio de que los atacantes se adaptan a lo que sea que estén analizando los escáneres. Sigue siendo lo más parecido en esta lista a responder a Third Coming y Miasma en sus propios términos, ya que evalúa el contenido de una versión en lugar de confiar en la identidad que hay detrás de ella.

SecureChain como alternativa al registro de npm frente al secuestro mediante credenciales robadas

Axios y jscrambler son los casos más sencillos, y es aquí donde un sustituto del registro de npm demuestra su utilidad con el menor riesgo.

Dirige tus compilaciones a un catálogo seleccionado y reconstruido a partir del código fuente y, para cualquier paquete que cubra SecureChain, la versión que se resuelva será la que TuxCare haya compilado a partir de código fuente verificado en un entorno reforzado, en lugar de la última versión subida a npmjs.com. Un archivo tar malicioso publicado con un token robado simplemente no se encuentra en esa ruta. No importa lo convincente que sea su empaquetado ni lo rápido que se detecte en otros sitios, porque tu compilación nunca iba a consultar la copia del registro público. La vulnerabilidad de jscrambler consiste, estructuralmente, en axios con un nombre de paquete diferente, por lo que la misma garantía cubre a ambos.

Hay dos aspectos sobre los que conviene ser preciso, ya que confundirlos es lo que lleva a exagerar este argumento. El primero es la cobertura. SecureChain se lanzó con los paquetes más utilizados del registro de npm y añadirá cualquier paquete del que dependas si aún no está en el catálogo, por lo que la garantía anterior se aplica a los paquetes cubiertos y no a todos y cada uno de los nombres que el árbol de dependencias pueda incluir. La fidelidad en la reproducción es la segunda. Un paquete npm publicado suele contener un resultado transpilado o empaquetado, en lugar del código fuente sin procesar del repositorio, y hacer coincidir cada byte significaría reproducir el propio entorno de compilación del editor, algo que el ecosistema no garantiza. Una reconstrucción de SecureChain no es un clon bit a bit del archivo tar del editor, ni nunca se pretendió que lo fuera. Se trata de una compilación con un origen trazable, lo cual es una propiedad diferente y más útil cuando el archivo tar del editor es precisamente aquello en lo que has dejado de confiar.

Esa trazabilidad es precisamente para lo que sirven los metadatos adjuntos. Los paquetes de SecureChain se compilan y firman para cumplir con el nivel 3 de procedencia de SLSA, con compilaciones que se ejecutan a partir de fuentes verificadas y respaldadas por pruebas continuas, y TuxCare publica metadatos SBOM y VEX cuando están disponibles. La cobertura de SBOM varía según el paquete y sigue ampliándose, en formato SPDX o CycloneDX dependiendo del paquete, por lo que es recomendable consultar la documentación actual en lugar de dar por sentado que se trata de un conjunto uniforme.

Una ventana de cuarentena es determinista frente a lanzamientos de corta duración

Filtrado, bloqueo de scripts, recompilación a partir del código fuente. Las tres funciones se basan en detectar que algo va mal. Una ventana de cuarentena no tiene por qué detectar nada.

Si se retrasa lo suficiente la resolución de una versión recién publicada, cualquier lanzamiento que se retire dentro de ese intervalo nunca podrá llegar a una compilación. No se analiza nada y no hay ningún clasificador con una tasa de falsos negativos que ajustar. La duración del intervalo y las posibles exclusiones siguen siendo decisiones de configuración, pero son de las que se pueden acordar en una pizarra. Sin embargo, la trampa está en la redacción. La antigüedad por sí sola no hace que una versión sea segura. Solo gana tiempo para que otra persona la detecte. Una versión maliciosa que permanece activa más allá del periodo de retraso acaba cumpliendo los requisitos como cualquier otra versión, que es exactamente lo que ocurrió con jscrambler 8.14.0.

Dos de ellos son victorias confirmadas de la aritmética frente al análisis. jscrambler es el contraejemplo. Miasma se sitúa en un término medio, ya que Wiz informó de que la mayoría de las versiones maliciosas habían sido revocadas a las 13:00 UTC, aunque en ese momento aún quedaban dos activas, lo que demuestra una rápida eliminación parcial, pero no aclara si todas las versiones habían desaparecido antes de que expirara el plazo de 24 horas.

La disyuntiva también es real. Un periodo de cuarentena implica un ligero retraso en la aplicación de parches legítimos, y los equipos que trabajan con dependencias de código fuente que evolucionan rápidamente lo notan más que los equipos que utilizan plataformas internas más lentas. Además, es uno de los controles más sencillos de implementar en este contexto, y el que tiene más probabilidades de ser descartado en una evaluación por parecer demasiado simple como para que resulte realmente eficaz.

Seguridad del registro privado de npm más allá de una caché de «pull-through»

El cambio solo tiene importancia si funciona en el día a día, así que aquí viene la parte operativa.

La integración consta de dos líneas en .npmrc, una línea de registro y la línea de autenticación para ese host, utilizando el token CLN que te proporciona TuxCare, sustituyendo «YOUR_CLN_TOKEN» por el valor real:

registry=https://artifacts.tuxcare.com/npm/
//artifacts.tuxcare.com/npm/:_authToken=YOUR_CLN_TOKEN

package.json no cambia. Los nombres y las versiones se mantienen tal y como están, y el mismo punto final aloja las compilaciones de SecureChain cuando existen, además del paquete público de origen para todo lo demás, por lo que no es necesario configurar un segundo registro.

Hay un pequeño inconveniente que conviene comprobar antes de proceder a una implantación generalizada. package-lock.json Registra, entre otras cosas, una URL resuelta que indica de dónde procede cada archivo tar y un hash de integridad sobre los bytes de dicho archivo tar. Es de esperar que la URL resuelta cambie al cambiar de servidor. Lo interesante es el hash de integridad. Un hash se valida comparándolo con un archivo tar de bytes idénticos procedente de cualquier servidor, por lo que un simple cambio de servidor no lo afectaría; sin embargo, una reconstrucción de SecureChain, lógicamente, no tiene bytes idénticos a los del artefacto público. Esa discrepancia es lo que se manifiesta como EINTEGRITY cuando un antiguo archivo de bloqueo del Registro público se encuentra con un nuevo Registro que hay debajo de él.

Así que prepárate para un archivo de bloqueo regenerado en lugar de una diferencia superficial. Eliminar node_modules y package-lock.json, realiza una instalación nueva con el nuevo registro y, a continuación, confirma el archivo de bloqueo que genera, en el que se registran las URL de SecureChain y las sumas de comprobación. Hazlo primero en una rama temporal o en un clon, para que seas tú quien lea el diff en lugar de que sea la integración continua (CI) quien lo detecte por ti. A continuación, decide de antemano si el cambio se implementa como una confirmación independiente en todos los repositorios de una sola vez o si se implementa de forma gradual. Mezclar un cambio de registro en una rama de características es la forma en que la configuración acaba siendo revertida silenciosamente por alguien que ni siquiera sabía que estaba ahí.

Dos pasos más bastan para que la propuesta se convierta en una medida obligatoria. Trasladar CI a npm ci dondequiera que siga funcionando npm install, ya que npm ci se instala a partir del archivo de bloqueo confirmado y falla cuando el archivo de bloqueo y package.json no estar de acuerdo en lugar de actualizarlo discretamente. A continuación, bloquea el acceso a registry.npmjs.org desde los agentes de compilación, ya que, hasta que no se cierre, la configuración del registro en .npmrc Es una sugerencia que cualquiera puede anular para desbloquear una implementación.

Prueba ese bloqueo de salida en el entorno de prueba antes de aplicarlo en todas partes. Cualquier fallo que se produzca allí te indicará qué procesos y herramientas han estado eludiendo la configuración del registro, y es mucho mejor disponer de esa lista en forma de documento que como un incidente.

Argumentos a favor de un registro npm diferente

La filtración de contenidos y la reconstrucción y resolución abarcan diferentes modos de fallo, no el mismo dos veces. La filtración se aplica a «Third Coming» y «Miasma», ya que no depende del origen de una publicación. La reconstrucción y resolución a partir de un catálogo curado se aplica a «axios» y «jscrambler», ya que, para un paquete cubierto, el artefacto malicioso nunca entra en la ruta desde la que se resuelve tu compilación, respaldada por artefactos firmados y procedencia SLSA de nivel 3.

Si tu equipo sigue resolviendo las dependencias directamente desde el registro público, solicita un presupuesto para SecureChain para npm y comprueba cuánto cuesta subsanar esa carencia.

PREGUNTAS FRECUENTES

¿Qué es un registro npm seguro?

Una capa de registro que proporciona paquetes reconstruidos y evaluados para las dependencias que cubre, en lugar de transmitir directamente el artefacto del editor. En la práctica, se trata de una combinación: se utilizan compilaciones de SecureChain cuando existen y paquetes públicos de origen para el resto, todos ellos servidos a través del mismo punto final. Esto difiere de una caché de «pull-through», que mejora la disponibilidad y la velocidad sin inspeccionar nada de lo que pasa por ella.

¿Habría impedido un registro npm seguro la campaña «La tercera venida de Shai-Hulud»?

Es posible, siempre que el registro analice el contenido independientemente de la identidad del editor. Nunca se determinó si la propia versión maliciosa incluía una certificación válida, por lo que en este caso no se puede confiar únicamente en los controles basados en la identidad. Un paso de filtrado que analice el contenido de una versión —un nuevo gancho de compilación, código ofuscado, archivos sin commit correspondiente— puede detectar esto independientemente de lo que indique un certificado. Miasma es el ejemplo más claro de este mismo modo de fallo, ya que aquellas versiones sí incluían una procedencia SLSA válida y firmada.

¿Habría impedido «Axios» un periodo de cuarentena?

Sí. Las versiones maliciosas estuvieron activas durante unas tres horas y luego se retiraron, por lo que un retraso de un día en la adopción —el más corto que npm puede expresar— las habría mantenido inelegibles durante todo su tiempo de vida maliciosa, sin que fuera necesario identificar nada como malicioso. Esa barrera es el parámetro «min-release-age», que toma un valor en días y requiere npm 11.10.0 o una versión más reciente, ya que los clientes más antiguos lo ignoran sin avisar. Limita la resolución de dependencias en lugar de actuar como una comprobación retroactiva, por lo que una versión maliciosa ya fijada en un archivo de bloqueo confirmado es un problema aparte.

¿Qué cambios supone realmente en el día a día un sustituto del registro de npm?

Principalmente, de dónde se resuelven los comandos de instalación. package.json y la mayoría de los flujos de trabajo siguen siendo los mismos. package-lock.json Es necesario regenerarlo una vez, ya que tanto la URL resuelta como el hash de integridad que contiene hacen referencia a elementos del antiguo registro.

¿La seguridad de un registro privado de npm se garantiza simplemente con la creación de dicho registro?

No por sí solo. Un proxy de almacenamiento en caché te proporciona un punto de control sobre el origen de los paquetes, pero ese punto de control no garantiza que lo que pasa por él sea fiable. Que las instalaciones sean realmente más seguras depende de lo que se ejecute en ese punto de control y de si también se han bloqueado las rutas alternativas. La brecha habitual sigue siendo que la integración continua (CI) sigue resolviendo directamente desde el registro público.

Resumen

Nombre del artículo

Registro seguro de npm probado con axios y Shai-Hulud

Descripción

¿Habría impedido un registro npm seguro los ataques de axios, jscrambler, Shai-Hulud y Miasma? Los controles de SecureChain, asignados a cada mecanismo.

Autor

Artem Karasev

Nombre del editor

TuxCare

Logotipo de la editorial