Miasma Regresa: Compromiso de la Plataforma Leo en npm

TL;DR La campaña Shai-Hulud Miasma tiene una nueva serie de paquetes maliciosos tras la violación de la cuenta de mantenimiento de czirker, que afecta tanto a los ecosistemas de RStreams como de Leo Platform. Sonatype está implicando 23 versiones de paquetes maliciosos en esta campaña. Esta ola se basa directamente en el manual de Miasma que Sonatype informó recientemente: moviéndose más allá de scripts preinstalación y postinstalación obvios para abusar de binding.gyp, robar credenciales, validar acceso y propagarse a través de flujos de trabajo de publicación de paquetes de confianza. Las organizaciones que instalaron versiones afectadas deberían tratar las estaciones de trabajo de desarrolladores, los runners de CI/CD, los contenedores de construcción y los entornos adyacentes a producción como potencialmente comprometidos. Eliminar versiones maliciosas, investigar la ejecución durante la instalación y rotar credenciales solo después de haber eliminado la persistencia. Cómo la Compromiso de npm de Leo Platform Transformó la Confianza en un Ataque de Ejecución Los atacantes no solo están publicando nuevos paquetes sospechosos y esperando que alguien se equivoque. Cada vez más, están comprometiendo los paquetes en los que los desarrolladores ya confían. El 25 de junio de 2026, investigadores de la industria comenzaron a informar sobre otro compromiso de la cadena de suministro de npm vinculado a la campaña de paquetes maliciosos Shai-Hulud Miasma. Los primeros informes apuntaron a una cuenta de mantenimiento comprometida utilizada para publicar versiones maliciosas de paquetes asociados con el ecosistema de Leo Platform. Hemos visto este patrón antes: comprometer un mantenedor o flujo de trabajo de publicación confiable, modificar paquetes legítimos y dejar que la automatización descendente haga el resto. Lo que hace que esta ola sea especialmente importante es dónde ocurre la ejecución. El malware continúa utilizando binding.gyp, un archivo normalmente asociado con complementos nativos de Node.js. En lugar de depender únicamente de scripts de ciclo de vida obvios en package.json, el malware puede ejecutarse durante la instalación a través de node-gyp. Examinar solo los metadatos del paquete no captará este tipo de ataque. Un paquete puede parecer limpio a simple vista, mantener su nombre legítimo y aún así ejecutar código malicioso antes de que la aplicación lo importe. Esa es la lección más amplia de esta campaña: un paquete confiable es solo tan confiable como su última versión. El Compromiso de la Plataforma Leo: Lo Que Ve Sonatype Los informes públicos difieren en el número exacto de paquetes maliciosos del ecosistema Leo. Algunos informes iniciales enumeraron 23 paquetes, mientras que otros documentos técnicos enumeraron 20 paquetes maliciosos confirmados y omitieron tres paquetes de pre-lanzamiento o candidatos a lanzamiento de Leo. Para ayudar a los equipos de seguridad a evitar perseguir falsas alarmas y mantener eficientes los flujos de trabajo de remediación, el análisis en profundidad de Sonatype miró más allá de las banderas iniciales de metadatos. Nuestro análisis preliminar encontró que tres paquetes incluidos en algunos informes públicos tempranos no parecen contener código malicioso: leo-connector-common@4.0.11-rc, leo-connector-postgres@4.0.19-beta, leo-connector-entity-table@3.0.22-rc. Estos paquetes aún deben ser revisados por los equipos afectados porque son parte de la actividad del incidente circundante. Sin embargo, según el análisis actual de Sonatype, no parecen llevar la carga maliciosa observada en los paquetes confirmados de Leo y RStreams. Sonatype identificó paquetes adicionales que no fueron incluidos en los informes públicos, pero que contienen la misma carga ofuscada, utilizan el método de ejecución binding.gyp y fueron todos publicados por una cuenta que probablemente fue comprometida: hexo-deployer-wrangler@1.0.4, hexo-shoka-swiper@0.1.10, prism-silq@1.0.1. La investigación de seguridad de Sonatype continúa siguiendo esta campaña y actualizará sus hallazgos según sea apropiado. ¿Qué Intenta Robar Miasma? Basado en el análisis actual de Sonatype y los informes anteriores de Miasma, las organizaciones afectadas deberían revisar los entornos para la exposición de: tokens de GitHub y secretos de GitHub Actions, tokens de publicación de npm, credenciales de nube, variables de entorno de CI/CD, credenciales de registro de paquetes, claves SSH, historial de shell y archivos de configuración de desarrolladores, configuración de repositorios, archivos de configuración del IDE y asistente de codificación AI. Este no es solo un problema de estaciones de trabajo de desarrolladores. La instalación de dependencias a menudo ocurre dentro de sistemas CI/CD con acceso a secretos, claves de despliegue, tokens de registro y credenciales de nube. ¿Cómo Deberían Responder las Organizaciones al Ataque npm Shai-Hulud Miasma? Las organizaciones que pueden verse afectadas por la última campaña Miasma deberían investigar si las versiones afectadas confirmadas fueron instaladas en estaciones de trabajo de desarrolladores, runners de CI/CD, agentes de construcción, espejos de paquetes internos, cachés de dependencias, imágenes de contenedores, archivos de bloqueo o sistemas adyacentes a producción. Comience revisando: package.json y package-lock.json, yarn.lock, pnpm-lock.yaml, instalación de dependencias de CI/CD y registros de construcción de contenedores, cachés del administrador de paquetes, registros del administrador de repositorios internos, SBOMs y manifiestos de dependencias, y telemetría de proxy o firewall npm. Si se instaló una versión de paquete malicioso confirmada, no simplemente elimine el paquete y continúe. Preserve los registros, isle los sistemas afectados, elimine las versiones maliciosas de los manifiestos y cachés, regenere los archivos de bloqueo a partir de versiones conocidas y buenas, e inspeccione los registros de instalación en busca de node-gyp, binding.gyp, ejecución de JavaScript ofuscado, archivos temporales inesperados y actividad de red saliente. La rotación de credenciales es esencial, pero el momento importa. Rote las credenciales de GitHub, npm, nube, CI/CD, registro de paquetes, SSH y otras credenciales expuestas solo después de que se hayan investigado y limpiado los entornos afectados. Si permanece la persistencia, las nuevas credenciales rotadas pueden ser expuestas nuevamente. ¿Qué Revela Acerca del Riesgo en la Cadena de Suministro de npm? Este incidente refuerza un patrón que Sonatype continúa siguiendo en los ataques a npm: los atacantes no solo están publicando nuevos paquetes sospechosos. Están comprometiendo paquetes de confianza, mantenedores de confianza y flujos de trabajo de confianza. Un nombre de paquete puede ser legítimo mientras que una versión específica es maliciosa. Una cuenta de mantenedor puede ser confiable hasta que su token sea robado. Un paquete puede tener años de un historial limpio y volverse peligroso en un solo lanzamiento. El compromiso de la Plataforma Leo también muestra cuán rápidamente evolucionan las campañas en torno a la respuesta de la comunidad de seguridad. Una vez que los defensores aprenden un marcador, los atacantes cambian las cadenas. Una vez que los defensores inspeccionan postinstall, los atacantes mueven la ejecución a binding.gyp. Una vez que los investigadores publican detecciones, pueden aparecer engaños ruidosos y paquetes de referencia de proveedores. Los equipos de seguridad necesitan buscar comportamientos, no marcas. La Confianza es el Vector de Ataque; Los Desarrolladores son el Objetivo El compromiso de la Plataforma Leo es otro recordatorio de que el riesgo de código abierto ya no se limita a nuevos paquetes sospechosos o errores tipográficos obvios. Cada vez más, los atacantes están apuntando a los paquetes, mantenedores y flujos de trabajo de publicación en los que los desarrolladores ya confían. Eso cambia la forma en que las organizaciones deben pensar sobre la seguridad de las dependencias. Un paquete con un nombre legítimo, un historial limpio y una base de usuarios establecida puede convertirse en malicioso en un solo lanzamiento comprometido. Los equipos de seguridad necesitan visibilidad sobre lo que cada versión hace en el momento de la instalación, no solo si el paquete ha sido confiable anteriormente. La investigación de seguridad de Sonatype continúa analizando el compromiso de la Plataforma Leo, la actividad relacionada de Shai-Hulud Miasma, y paquetes que pueden haber sido pasados por alto o mal clasificados en informes públicos tempranos. Las organizaciones deberían tratar las instalaciones confirmadas como eventos potenciales de compromiso, revisar la telemetría de dependencias y construcción, y rotar credenciales solo después de que los entornos afectados hayan sido investigados y limpiados.