El panorama de amenazas de npm: superficie de ataque y mitigaciones (Actualizado el 21 de mayo)

Resumen ejecutivo

La seguridad del ecosistema de npm alcanzó un punto de inflexión crítico en septiembre de 2025. El gusano Shai-Hulud, un malware autorreplicante que automatizaba la vulneración y la redistribución de paquetes maliciosos, marcó el final de la era de ataques “menores” a npm y el comienzo de un panorama de amenazas de grandes consecuencias.

Desde aquel momento decisivo, Unit 42 ha detectado una agresiva aceleración en la frecuencia y la profundidad técnica de las vulneraciones de la cadena de suministro. Los ataques han pasado de ser una serie de incidentes aislados de “typosquatting” a campañas sistemáticas de varios actores de amenazas para convertir en un arma la confianza que impulsa el desarrollo moderno de software.

Campañas de abril de 2026

En abril vimos dos campañas: la primera comenzó el 22 de abril de 2026 e incluyó la cadena Shai-Hulud: The Third Coming. La segunda comenzó el 29 de abril de 2026 y es conocida como Mini Shai-Hulud.

Campañas de mayo de 2026

En mayo de 2026, la campaña de Mini Shai-Hulud continuó con dos nuevas oleadas atribuidas a TeamPCP. Estas campañas introdujeron dos elementos únicos. En una campaña se utilizó una técnica de acceso inicial sin credenciales. En la otra campaña, se alcanzó el récord de paquetes publicados en una hora de entre todos los gusanos Shai-Hulud hasta la fecha. Las imitaciones han hecho más difícil atribuir futuros ataques a TeamPCP.

La nueva línea de base para las amenazas a npm

El incidente de Shai-Hulud demostró que el registro de npm podía utilizarse como multiplicador de fuerza para la distribución de malware. En los meses siguientes, observamos tres cambios fundamentales en las tácticas, técnicas y procedimientos (TTP) de los adversarios:

• Propagación por gusanos: las cargas maliciosas ahora priorizan el robo de tokens de npm y los tokens de acceso personal (PAT) de GitHub para infectar automáticamente y volver a publicar paquetes legítimos, como se vio en el caso de la vulneración Axios de marzo de 2026.
• Persistencia a nivel de infraestructura: los atacantes ya no se limitan a robar datos. Se están incrustando en los canales de CI/CD para conseguir un acceso indetectable y a largo plazo a los entornos empresariales.
• Cargas útiles multietapa: siguiendo la plantilla de septiembre de 2025, los ataques actuales suelen implementar dependencias “durmientes” latentes que solo se activan en condiciones del entorno específicas para eludir los escáneres automatizados.

Los ataques a npm analizados en su conjunto

Las vulneraciones de npm tienen temas en común. En la era posterior a Shai-Hulud, creemos que es útil considerar la superficie de ataque como un todo.

En este artículo, se combinará lo siguiente:

1. Detalles de incidentes importantes: análisis en tiempo real de paquetes comprometidos significativos (por ejemplo, Shai-Hulud 2.0, Axios, Chalk/Debug)
2. Correlación entre campañas: identificación de la infraestructura o fragmentos de código en común que vinculan ataques dispares a los mismos actores de amenazas.
3. Manuales de remediación: orientación práctica para rotar credenciales y purgar dependencias maliciosas de cachés locales y basadas en la nube.

Shai-Hulud: una nueva ola

Se identificó un paquete de npm malicioso publicado como @bitwarden/cli, versión 2026.4.0, como parte de una campaña más amplia atribuida a TeamPCP que ataca la cadena de suministro. El paquete suplanta el gestor legítimo de contraseñas Bitwarden con interfaz de línea de comandos (CLI).

Luego de la instalación, ejecuta una carga útil multietapa que roba credenciales de proveedores de la nube, sistemas CI/CD y estaciones de trabajo de desarrolladores. Luego, se autopropaga mediante la inserción de puertas traseras en cada paquete de npm que la víctima puede publicar. Se ha observado que dentro de los repositorios públicos de GitHub que se publicaron figuraba la cadena “Shai-Hulud: The Third Coming”.

Los atacantes implementaron la misma carga útil a través de múltiples canales de distribución Checkmarx:

• Imágenes de Docker Hub
• GitHub Actions
• Extensiones de VS Code

Esto indica que se trató de una campaña coordinada para convertir en armas las credenciales comprometidas de herramientas para desarrolladores a fin de maximizar el área de impacto.

Los clientes de Palo Alto Networks están mejor protegidos frente a las amenazas descritas en este artículo por medio de los siguientes productos y servicios:

• Advanced WildFire
• Advanced URL Filtering y Advanced DNS Security
• Cortex Cloud

El equipo de respuesta ante incidentes de Unit 42 también puede involucrarse para ayudar con una intrusión o para proporcionar una evaluación proactiva que permita reducir el riesgo.

Mayo de 2026: continúa la campaña de Mini Shai-Hulud

Dos oleadas adicionales en mayo de 2026 extendieron la campaña de Mini Shai-Hulud:

• Con la primera oleada, se introdujo una técnica de acceso inicial fundamentalmente nueva que no requiere credenciales robadas y que produjo los primeros paquetes npm maliciosos con niveles de cadena de suministro válidos para artefactos de software (trazabilidad con SLSA).
• La segunda oleada alcanzó el récord de paquetes publicados en una hora entre todas las oleadas de Shai-Hulud.

Ambas oleadas se atribuyen a TeamPCP, aunque la publicación del código fuente del gusano realizada el 12 de mayo ya ha generado imitaciones, lo que complica la atribución de autoría en el futuro.

11 de mayo de 2026: Mini Shai-Hulud ataca de nuevo

El 11 de mayo, TeamPCP lanzó un ataque coordinado a la cadena de suministro en los ecosistemas de npm y PyPI. El vector de acceso inicial fue el canal de CI de GitHub Actions de TanStack. En seis minutos, se publicaron 84 artefactos de paquetes maliciosos en 42 paquetes @tanstack/*.

El mecanismo de autorreplicación del gusano se expandió rápidamente. Al finalizar el día, habíamos documentado 373 versiones maliciosas en 169 paquetes de npm más los paquetes de PyPI comprometidos.

El impacto se expandió mucho más allá de TanStack. La autorreplicación del gusano propagó la vulneración a paquetes en múltiples industrias y ecosistemas:

• Infraestructura empresarial: @opensearch-project/opensearch (el cliente oficial de OpenSearch para JavaScript; versiones 3.5.3–3.8.0) y 57 paquetes de automatización empresarial @uipath/*.
• Herramientas de IA: @mistralai/mistralai y sus variantes de Azure/GCP, que es el cliente oficial de Mistral AI para TypeScript.
• Ecosistemas especializados: 19 paquetes de datos de aviación @squawk/*, intercom-client@7.0.4 (mensajería del cliente) y docenas de otros a través de @tallyui, @draftlab, @beproduct, @mesadev y varios paquetes no especificados.

Solo @tanstack/react-router tiene más de 12.7 millones descargas por semana. Estimamos que en la ventana de tiempo afectada hubo 520 millones de descargas acumuladas. Palo Alto Networks proporciona XDR y consultas XQL para detectar esta actividad.

Un nuevo acceso inicial: no se necesitan credenciales robadas

Todas las oleadas anteriores de Shai-Hulud habían comenzado con una credencial robada u obtenida mediante phishing. El ataque de TanStack no necesitó ninguna de las dos. En cambio, se encadenaron tres debilidades de GitHub Actions, ya que ninguna era suficiente por sí sola.

Paso 1: solicitud PWN

El 10 de mayo, el atacante creó un fork de TanStack/router bajo la cuenta zblgg/configuration, nombrado deliberadamente para que no apareciera en búsquedas de listas de forks. Se creó un commit malicioso bajo la identidad falsificada de claude <claude@users.noreply.github.com>, haciéndose pasar por la aplicación de Claude para GitHub desarrollada por Anthropic, y se agregó el prefijo [skip ci] para evitar que se ejecutara el CI en el push.

Luego, una solicitud de pull (PR #7378) contra TanStack/router#main activó bundle-size.yml, un flujo de trabajo que utilizaba el disparador pull_request_target, y obtuvo la referencia de fusión del fork. Esto permitió la ejecución del código del fork en el contexto del runner del repositorio base, con acceso completo a su ámbito de caché.

Los actores de amenazas utilizaron Bun, que es un entorno de ejecución de JavaScript ligero y un administrador de paquetes alternativo a Node.js y npm, como se muestra en la Figura 1. En el ataque se utilizó Bun para ejecutar la carga útil maliciosa tanstack_runner.js. Esto a su vez intentó enumerar el sistema en busca de credenciales sensibles, incluida la invocación de CLI de GitHub para capturar el token de autenticación de GitHub (gh auth token).

Kubernetes

En un entorno de Kubernetes alojado en Linux, Unit 42 observó una actividad legítima de creación de contenedores runc asociada con un canal de compilación que posteriormente recuperó y ejecutó el paquete de JavaScript comprometido. La invocación de creación de runc fue una actividad legítima del runtime de Kubernetes asociada con el proceso de compilación en contenedores.

Durante la compilación:

• El proyecto nuevamente recuperó y ejecutó de manera dinámica el runtime de Bun a través de su cadena de dependencias pnpm.
• Posteriormente, ejecutó la carga útil maliciosa de JavaScript tanstack_runner.js.
• Luego, continuó como en el entorno de Windows.

La línea de proceso se muestra en la Figura 2.

Paso 2: envenenamiento de la caché de GitHub Actions

El código del fork escribió un almacén de pnpm envenenado de 1.1 GB usando exactamente la misma clave de caché que release.yml buscaría posteriormente. La clave fue precomputada a partir del pnpm-lock.yaml público utilizando la misma fórmula hashFiles() que usa el flujo de trabajo. La entrada de caché envenenada permaneció inactiva durante ocho horas.

Un detalle crítico: el guardado posterior al trabajo de actions/cache@v5 utiliza un token interno del runner, no el GITHUB_TOKEN del flujo de trabajo, por lo que establecer permissions: contents: read en el flujo de trabajo no previene la escritura en la caché.

Paso 3: extracción del token OpenID Connect (OIDC) de la memoria del runner

Cuando un mantenedor legítimo hizo push en main, se activó release.yml, se restauró la caché envenenada y se ejecutaron binarios controlados por el atacante durante la fase de compilación. Esos binarios leyeron /proc/<Runner.Worker>/mem y extrajeron el token OIDC, creado únicamente en la memoria del runner cuando está habilitado id-token: write, y luego lo enviaron directamente a registry.npmjs.org.

El paso Publicar paquetes del flujo de trabajo nunca se alcanzó; las pruebas fallaron y ese paso fue omitido. De todos modos, npm recibió 84 publicaciones de paquetes válidas, firmadas y con atestación de trazabilidad.

Esta es la misma técnica de extracción de memoria /proc documentada en la vulneración de tj-actions/changed-files de marzo de 2025, que se reutilizó en las oleadas de SAP y Bitwarden en abril de 2026.

El problema de la trazabilidad con SLSA

Este es el primer caso documentado de un gusano que publica paquetes maliciosos de npm con una trazabilidad válida de SLSA Build Level 3. Sigstore atestiguó correctamente que los paquetes fueron construidos por release.yml desde refs/heads/main de TanStack/router, porque así fue. La trazabilidad de SLSA confirma qué canal compiló un paquete, pero no si el estado interno de ese canal estaba limpio.

La causa raíz es el mismo error de configuración del ámbito de confianza de OIDC que se explotó en la oleada @cap-js wave del 29 de abril. El enlace de editor de confianza confiaba en todo el repositorio, y no en un flujo de trabajo específico en una rama protegida.

La verificación de la trazabilidad es necesaria, pero ya no es suficiente. Por eso, resulta esencial analizar el comportamiento en el momento de la instalación.

Carga útil y propagación

La carga útil maliciosa, router_init.js (2.3 MB con ofuscación), no se entregó a través de un gancho de preinstalación en los paquetes comprometidos. En cambio, cada tarball recibió una entrada inyectada de optionalDependencies que apunta a un commit huérfano en el fork del atacante.

Este es un commit que GitHub muestra bajo la URL legítima TanStack/router debido al almacenamiento compartido de objetos de commit en la red de forks:

La dependencia está diseñada para fallar silenciosamente durante la instalación. El código malicioso se ejecuta en segundo plano mientras el proceso de instalación parece normal, lo que deja un rastro casi nulo en los registros. La carga útil utiliza múltiples capas de ofuscación y cifrado para resistir el análisis automatizado. Comparte el mismo cifrado personalizado que se documentó en las secciones de Bitwarden del 22 de abril y SAP del 29 de abril, lo que confirma la autoría compartida en las tres oleadas.

En el caso de las víctimas secundarias infectadas a través de la propagación del gusano (por ejemplo, UiPath, Mistral AI y OpenSearch), el mecanismo de entrega volvió al gancho de preinstalación familiar de la oleada de SAP de abril.

El patrón ahora está bien establecido. Una vez que el gusano logra infiltrarse en un ecosistema, utiliza credenciales robadas para republicarse en los otros paquetes que mantiene la víctima, expandiendo rápidamente su alcance a través de proyectos y organizaciones no relacionados.

El interruptor del hombre muerto: una advertencia crítica sobre el orden de remediación

La carga útil del 11 de mayo instala un servicio de fondo persistente que consulta api.github.com/user con el token de GitHub robado cada 60 segundos. Si se revoca el token (HTTP 40x), el servicio ejecuta rm -rf ~/, destruyendo el directorio personal del usuario. El demonio se cierra automáticamente después de 24 horas.

12 de mayo de 2026: lanzamiento público del gusano

En la noche del 12 de mayo de 2026, el código fuente completamente convertido en arma de Mini Shai-Hulud se publicó en repositorios públicos de GitHub antes de ser retirado. La cadena de herramientas que incluye los scripts de envenenamiento de caché de CI, el extractor de tokens OIDC y el ladrón de credenciales con su lógica de propagación ahora está disponible públicamente.

Mini Shai-Hulud ya no se limita a TeamPCP. Los futuros incidentes que utilicen esta cadena de herramientas podrían no compartir la infraestructura o las técnicas de TeamPCP y no deben atribuirse únicamente en base a la línea de gusanos.

19 de mayo de 2026: oleada @antv

El 19 de mayo de 2026, la cuenta del mantenedor de npm atool se vio comprometida como parte de una nueva oleada de Mini Shai-Hulud. En aproximadamente una hora, se publicaron 639 versiones de paquetes maliciosos en 323 paquetes únicos. Este es el mayor recuento de paquetes en una sola hora contabilizado en las oleadas de Shai-Hulud hasta la fecha.

El alcance afectado abarca el ecosistema de visualización de datos @antv y bibliotecas relacionadas:

• @antv/g2, g6, x6, l7, s2, f2, g, g2plot, graphin, data-set y s2-vue
• Paquetes fuera del espacio de nombres @antv, incluidos echarts-for-react (aproximadamente 1.1 millones de descargas semanales), timeago.js, size-sensor y canvas-nest.js

Resulta significativa el área potencial de impacto en visualización de datos, graficación, mapeo, creación de cuadros y ecosistemas de componentes de React.

Mecanismo de infección

A diferencia de la técnica de secuestro de canales de la oleada de TanStack, esta oleada regresa a un modelo más simple. Implica comprometer una cuenta del mantenedor y usarla para republicar paquetes directamente. Es el mismo enfoque visto en las campañas de septiembre y noviembre de 2025.

El atacante modificó el package.json de cada paquete de tres maneras:

• Agregando un gancho de preinstalación ("preinstall": "bun run index.js") que ejecuta la carga útil maliciosa a través del entorno de ejecución de Bun.
• Agrupando Bun como una dependencia para asegurar que esté disponible en cualquier máquina.
• Insertando una dependencia opcional basada en git que apunta a un commit huérfano en el repositorio legítimo de antvis/G2 como una ruta de ejecución de respaldo.

A fin de garantizar que las versiones maliciosas llegaran a la mayor cantidad de objetivos posible, el atacante también aumentó los números de versión más allá del último lanzamiento legítimo (por ejemplo, @antv/s2-vue saltó de la versión real 2.2.0 a 2.4.0). Cualquier proyecto que use un rango de versión permisivo como ^2.x automáticamente descargará la versión maliciosa en la próxima instalación.

Capacidades de la carga útil

La carga útil ofuscada de 499 KB ejecuta seis recolectores de credenciales en paralelo, abarcando un amplio rango de objetivos:

• Credenciales de desarrollador: tokens de GitHub, tokens de npm, claves SSH, credenciales de Git y claves privadas
• Nube e infraestructura: credenciales y parámetros de AWS, tokens de cuenta de servicio de Kubernetes, secretos de HashiCorp Vault y autenticación de Docker
• Plataformas de CI/CD: tokens de más de 18 plataformas, como GitHub Actions, GitLab CI, CircleCI, Vercel y Netlify
• Servicios de terceros: cadenas de conexión de bases de datos, claves API de Stripe, Slack y Twilio
• Gestores de contraseñas (nuevos en esta oleada): la carga útil consulta directamente 1Password, Bitwarden, pass y gopass a través de sus CLI locales

Todos los datos robados están cifrados y se envían a un endpoint C2 disfrazados como ingesta de trazas de OpenTelemetry (t.m-kosche[.]com), lo que significa que las herramientas de monitoreo de la red podrían clasificar el tráfico como telemetría de observabilidad legítima.

Un canal de respaldo exfiltra datos a repositorios de GitHub creados bajo la cuenta de la víctima, utilizando nombres temáticos de Dune y el marcador de campaña revertido Shai-Hulud: Here We Go Again como la descripción.

Abril de 2026 - Shai-Hulud: una nueva ola

La ola de Mini Shai-Hulud de fines de abril

Desde el 29 de abril de 2026, una nueva ola de ataques a la cadena de suministro (apodada Mini Shai-Hulud) está atacando activamente el ecosistema de desarrolladores de SAP mediante cuatro paquetes de npm comprometidos. Las versiones afectadas son las siguientes:

• @cap-js/sqlite@2.2.2
• @cap-js/postgres@2.2.2
• @cap-js/db-service@2.10.1
• mbt@1.2.48

Estos paquetes combinados tienen aproximadamente 570,000 descargas semanales, siendo @cap-js/sqlite y @cap-js/db-service los que acumulan unas 250,000 y 260,000 descargas, respectivamente.

Los cuatro paquetes forman parte del modelo de programación de aplicaciones en la nube (CAP) de SAP y de la cadena de herramientas de compilación de aplicaciones multiobjetivo (MTA). Esto hace que los objetivos de este ataque sean los desarrolladores empresariales y los canales de CI/CD con acceso a credenciales en la nube, tokens de GitHub y secretos de implementación.

La campaña es una continuación estructural estrecha de la vulneración @bitwarden/cli@2026.4.0 de abril de 2026. Utiliza la misma cadena de herramientas, la misma ofuscación y la misma lógica de propagación, que ahora se vuelve contra el ecosistema SAP.

Mecanismo de ataque

Cada paquete comprometido recibió dos archivos nuevos:

• setup.mjs
• execution.js

Estos archivos llegaron junto con un package.json modificado que añade un hook de ciclo de vida de preinstalación (“preinstall”: “node setup.mjs”).

Esto significa que el código malicioso se ejecuta automáticamente durante el proceso de instalación de npm, antes de que se complete la instalación. El bootstrapper setup.mjs detecta el sistema operativo y la arquitectura del anfitrión, y luego realiza las siguientes actividades:

• Descarga el tiempo de ejecución de Bun JavaScript (v1.3.13) desde la versión oficial github[.]com/oven-sh/bun.
• Extrae el tiempo de ejecución a un directorio temporal.
• Lo usa inmediatamente para ejecutar execution.js.

Capacidades de carga útil

El ladrón de credenciales ofuscado de un solo archivo de 11.7 MB, execution.js, es un marco de propagación. Realiza las siguientes actividades:

• Usa una capa de codificación de cadenas personalizada denominada ctf-scramble-v2 para ocultar cadenas sensibles del análisis estático.
• Incluye un mecanismo de desactivación basado en configuración regional rusa (salida silenciosa si la configuración regional del sistema es ‘ru’).
• Se ejecuta como un demonio en máquinas que no son CI para ejecutarse en segundo plano.

Recoge la siguiente información:

• Tokens de GitHub (incluida la salida del token gh auth)
• Tokens de npm de .npmrc
• Bloques completos de variables de entorno
• Secretos de GitHub Actions
• Identidad AWS STS
• Parámetros de Secrets Manager y SSM
• Secretos de Azure Key Vault
• Valores de GCP Secret Manager
• Tokens de cuenta de servicio de Kubernetes
• Archivos de configuración de Claude y MCP
• Billeteras Electrum
• Configuraciones de VPN

Una ruta CI particularmente agresiva utiliza un ayudante Python incrustado que lee la memoria /proc del proceso GitHub Actions Runner.Worker para extraer valores secretos enmascarados. Todos los datos recogidos están:

• Comprimidos
• Cifrados con AES-256-GCM, con una clave encapsulada mediante una clave pública RSA integrada
• Exfiltrados a repositorios GitHub públicos recién creados con nombres aleatorios de temática Dune y la descripción “Ha aparecido un Mini Shai-Hulud”

Propagación y dead drop de GitHub

La campaña utiliza la API pública de búsqueda de commits de GitHub como canal encubierto de comando y control (C2). El malware realiza las siguientes actividades:

• Buscar commits que contengan la palabra clave OhNoWhatsGoingOnWithGitHub.
• Descodificar mensajes de commit coincidentes como dead drop de tokens para recuperar tokens robados de GitHub.
• Utilizarlos para difundir.

Una vez que se obtiene un token utilizable, la carga útil realiza lo siguiente:

• Se copia a sí misma en execution[.]js.
• Escribe setup.mjs.
• Establece “preinstall”: “node setup.mjs” en package.json.
• Incrementa la versión del parche.
• Vuelve a empaquetar el tarball para publicarlo.

El malware también introduce los siguientes archivos directamente en los repositorios de la víctima:

• .vscode/setup.mjs
• .claude/execution.js
• .claude/settings.json

El malware empuja los archivos anteriores utilizando commits cuyo autor es claude <claude@users.noreply.github.com> con el mensaje “chore: update dependencies”.

Los tres enlaces forenses a @bitwarden/cli@2026.4.0 son lo suficientemente precisos como para indicar una autoría compartida o una cadena de herramientas directamente reutilizada.

1. El bootstrapper de preinstalación setup.mjs. En la campaña Bitwarden, setup.mjs era el artefacto de autorreplicación que el gusano (bw1.js) inyectaba en cada paquete de npm que la víctima podía publicar. Los paquetes SAP utilizan el mismo nombre de archivo como bootstrapper, y los dos tienen un claro linaje en común: la misma versión de Bun (1.3.13), la misma lógica de detección Alpine/musl y el mismo método de descarga que sigue redirecciones.

2. El método de ofuscación decodeScramble / ctf-scramble-v2. La carga útil de Bitwarden codifica todas las cadenas sensibles utilizando un cifrado personalizado de permutación ASCII con valor inicial. Se trata de una permutación Fisher-Yates sobre una tabla ASCII de 128 caracteres controlada por un PRNG congruente lineal con valor inicial 0x3039 (12345). El SAP execution.js utiliza una capa explícitamente denominada ctf-scramble-v2, que es el mismo esquema de sustitución determinista. Esto no es una biblioteca, es una implementación a medida. Se reutiliza en ambas cargas útiles.

3. El patrón de dead drop de commits de GitHub. El malware Bitwarden utilizaba la API pública de búsqueda de commits de GitHub como canal C2 encubierto. Incrustó tokens robados en mensajes de commit que coincidían con LongLiveTheResistanceAgainstMachines:<base64> y los utilizó para iniciar nuevos canales de exfiltración sin una infraestructura controlada por el atacante.

Esta ola aplica exactamente el mismo patrón bajo una nueva palabra clave (OhNoWhatsGoingOnWithGitHub) con mensajes de commit coincidentes decodificados como un dead drop de tokens. El mecanismo es idéntico en su implementación:

• Buscar en la API de GitHub commits que contengan la palabra clave.
• Analizar el cuerpo del mensaje de commit.
• Descodificar el token incrustado.
• Validarlo para acceder al repositorio.

Rotar la palabra clave manteniendo intacta la técnica es un sello distintivo del mismo operador que actualiza una base de código reutilizada.

El contexto más amplio de la campaña Shai-Hulud

Según la actualización de seguridad oficial de Checkmarx, este paquete de npm es un componente de una campaña más amplia de la cadena de suministro que comprometió simultáneamente múltiples canales de distribución de Checkmarx:

• Docker Hub: Imágenes checkmarx/kics envenenadas (v2.1.20, v2.1.21, latest, alpine, debian).
• GitHub Actions: checkmarx/ast-github-action v2.3.35 malicioso.
• Extensiones de VS Code: checkmarx/ast-results (v2.63, v2.66) y checkmarx/cx-dev-assist (v1.17, v1.19) con puerta trasera.
• npm: el paquete @bitwarden/cli analizado en este informe.

Según la revelación de Checkmarx, todos los artefactos tienen la misma infraestructura C2 (audit.checkmarx[.]cx), las mismas técnicas de ofuscación y la misma lógica de recolección y propagación de credenciales. La variante de la extensión VS Code entregaba su carga útil (mcpAddon.js) desde un commit huérfano con fecha anterior en el propio repositorio GitHub de Checkmarx, por lo que la URL de descarga parecía confiable.

TeamPCP (@pcpcats) se atribuyó públicamente el mérito de la vulneración. Según el análisis de Socket, el grupo ya había atacado la infraestructura de Checkmarx en marzo de 2026, junto con Trivy y LiteLLM, lo que sugiere una campaña en curso contra los proveedores de herramientas de seguridad.

Descripción general del ataque

En la Tabla 1, se muestran los atributos del ataque.

Tabla 1. Atributos del ataque.

El equipo de seguridad de Bitwarden proporcionó la siguiente información. Identificaron y contuvieron el paquete malicioso descrito en la Tabla 1, que se distribuyó brevemente a través de la ruta de entrega de npm para @bitwarden/cli@2026.4.0 entre las 5:57 p. m. y las 7:30 p. m. EST del 22 de abril de 2026, en relación con el incidente más amplio de la cadena de suministro.

Su investigación no encontró pruebas de que se hubiera accedido a datos de bóvedas de usuarios finales o de que estos estuvieran en peligro, ni de que se hubieran puesto en peligro datos o sistemas de producción. Una vez detectado el problema, se realizó lo siguiente:

• Se revocó el acceso comprometido.
• Se volvió obsoleta la versión maliciosa de npm.
• Se iniciaron medidas correctoras de inmediato.

El problema afectaba el mecanismo de distribución de npm para la CLI durante esa ventana limitada, no la integridad de la base de código legítima de la CLI de Bitwarden ni los datos almacenados en la bóveda.

Las personas que no descargaron el paquete de npm durante esa ventana de tiempo no se vieron afectadas. Bitwarden completó una revisión de los entornos internos, las rutas de lanzamiento y los sistemas relacionados. Por el momento, no encontraron más productos o entornos afectados.

Se está realizando una CVE para la versión 2026.4.0 de la CLI de Bitwarden en relación con este incidente.

Etapa 1: Bootstrap - bw_setup.js

El package.json proporciona dos rutas de ejecución para el script malicioso, como se muestra en la Figura 3.

El hook de preinstall se ejecuta automáticamente durante npm install. El campo ‘bin’ registra bw_setup.js como el comando ‘bw’, enlazándolo simbólicamente en el PATH del usuario.

Como la CLI legítima de Bitwarden también utiliza ‘bw’ como su nombre binario, esto sirve como un disparador secundario. Incluso si se bloquea la preinstall (por ejemplo, mediante --ignore-scripts), el malware se ejecuta la próxima vez que el usuario o cualquier script invoque ‘bw’. La línea shebang #!/usr/bin/env node al inicio de bw_setup.js garantiza que se ejecute como un script Node.js cuando se llama directamente.

El script bootstrap realiza tres acciones:

1. Detección de plataformas: identifica el sistema operativo y la arquitectura (Linux, macOS, Windows; x64 o arm64), incluida la detección de musl frente a glibc en Linux.
2. Descarga del entorno de ejecución Bun: descarga el tiempo de ejecución de Bun JavaScript (v1.3.13) desde la versión oficial github[.]com/oven-sh/bun. Esto es necesario porque la carga útil principal utiliza API específicas de Bun (ejecución de shell, E/S de archivos, gzip) no disponibles en Node.js.
3. Ejecución de la carga útil: ejecuta bw1.js usando el binario Bun recién descargado.

Se incluye una implementación de extracción ZIP personalizada para evitar cualquier dependencia, por lo que el bootstrap es totalmente autónomo.

Etapa 2: la carga útil - bw1.js

La carga útil es un archivo JavaScript de una sola línea de aproximadamente 10 MB que contiene unas 285,000 líneas una vez formateado. Incluye kits de desarrollo de software (SDK) legítimos (por ejemplo, AWS SDK, bibliotecas de cliente de Google Cloud, Azure Identity, Octokit, jsonwebtoken, tar) junto con el código de orquestación malicioso.

Técnicas de ofuscación

El código emplea múltiples capas de ofuscación:

• Rotación de la tabla de cadenas: la función _0x214e resuelve índices hexadecimales a cadenas de una gran matriz rotada (_0x1ee1), rompiendo el análisis estático y simple de cadenas.
• Cifrado de permutación ASCII con valor inicial: las cadenas sensibles (dominios, rutas de archivos, comandos del shell) se codifican como matrices de índices numéricos en una tabla ASCII permutada mediante Fisher-Yates. La permutación utiliza un PRNG congruente con valor inicial 0x3039 (12345), como se muestra en la Figura 4.

El conjunto ASCII de 128 caracteres se permuta de forma determinista, produciendo una tabla de sustitución en la que un índice con el valor hexadecimal 0x42 corresponde al carácter ASCII ‘a’ y 0x6e a ‘u’. Por ejemplo, el dominio C2 se almacena como [0x42, 0x6e, 0x36, 0x4b, 0x2b, 0x5c, 0xd, 0x57, 0x0, 0xd, 0x7, 0x26, 0x42, 0x3, 0x2a, 0x5c, 0xd, 0x2a], que decodifica una cadena ASCII para el dominio audit.checkmarx[.]cx.

• Cargas útiles incrustadas Gzip y Base64: varios blobs se almacenan como cadenas Base64 comprimidas con gzip, entre ellos una clave pública RSA, un flujo de trabajo YAML de GitHub Actions, el cargador setup.mjs del gusano y una cadena manifesto.
• Identificadores confusos: todos los nombres de variables y funciones se sustituyen por patrones hexadecimales como _0x3865d8.

Recogida de credenciales

La carga útil implementa múltiples clases de provider, cada una dirigida a una fuente de credenciales diferente. Cada proveedor escanea sus resultados con patrones regex para extraer tokens de npm y GitHub, como se muestra en la Figura 5.

Proveedor del sistema de archivos (Cn)

Lee los archivos sensibles de la estación de trabajo del desarrollador, con listas de rutas por SO decodificadas a través del codificador, como se muestra a continuación en la Tabla 2.

Tabla 2. Listas de rutas del SO del malware.

Se omiten los archivos de más de 5 MB, aproximadamente. Todos los demás se leen en su totalidad y se incluyen en la carga útil de exfiltración.

Proveedor de Shell (un)

Esto ejecuta gh auth token a través de execSync para obtener el token activo de la CLI de GitHub, y luego recoge el bloque de entorno process.env completo. Ambos son devueltos para el escaneo y la exfiltración de token-regex. A diferencia de los proveedores en la nube que aparecen a continuación, Shell Provider no utiliza ningún SDK, sino que se basa únicamente en el comando shell único y las variables del entorno.

Proveedor de GitHub Actions (Co)

Esto detecta entornos de CI/CD a través de process.env.GITHUB_ACTIONS === "true" y extrae todos los secretos configurados analizando patrones {"value":"...","isSecret":true} del contexto del ejecutor de acciones.

Proveedor AWS SSM (ku)

Utiliza el SDK de AWS incluido (SSMClient, DescribeParameters, GetParameter) para enumerar y leer parámetros del almacén de parámetros de AWS Systems Manager.

Proveedor de Azure Key Vault (Rn)

Utiliza los SDK de Azure Identity y Key Vault para llamar a getSecretsFromVault, listando y leyendo secretos de todas las bóvedas accesibles.

Proveedor de Google Cloud Secret Manager (uo)

Utiliza el cliente Google Cloud Secret Manager para listSecrets y accessSecretVersion, leyendo todos los secretos accesibles en todos los proyectos.

Exfiltración

Todas las credenciales recolectadas se procesan a través de un sistema de exfiltración de dos niveles.

Principal: HTTPS a C2 (Clase Cy)

1. Los resultados se serializan en JSON y se comprimen con gzip.
2. Se genera una clave simétrica AES-256-GCM aleatoria de 32 bytes.
3. Los datos se cifran con AES-256-GCM.
4. La clave simétrica se cifra mediante RSA con una clave pública de 4096 bits codificada (Fr).
5. El sobre cifrado se envía a través de POST hxxps[:]//audit.checkmarx[.]cx:443/v1/telemetry.

Secundaria: repositorios públicos de GitHub (Clase ky)

Usando tokens robados de GitHub, el malware realiza lo siguiente:

1. Crea un nuevo repositorio público en la cuenta de la víctima con la descripción "Checkmarx Configuration Storage" y un nombre temático de Dune (por ejemplo, gesserit-melange-813).
2. Consigna los archivos de resultados encriptados en un directorio results/.
3. Incrusta los tokens robados en mensajes de commit con el formato LongLiveTheResistanceAgainstMachines:<base64_token>.

Esta doble exfiltración garantiza que los datos lleguen al atacante, aunque el dominio C2 esté bloqueado.

Inyección de flujo de trabajo de GitHub Actions (Clase u_)

Cuando el malware obtiene un token de GitHub con ámbitos de repositorio y flujo de trabajo, la clase u_ valida los ámbitos y, a continuación:

• Enumera los repositorios a los que la víctima puede enviar mensajes, dando prioridad a los activos recientemente.
• Comprueba si cada repositorio tiene configurados los secretos de GitHub Actions (omite los repositorios que no los tengan).
• Crea una nueva rama y confirma .github/workflows/format-check.yml, un flujo de trabajo malicioso que vuelca todos los secretos, como se muestra a continuación en la Figura 6.

• Descarga el artefacto resultante que contiene todos los secretos serializados.
• Elimina la rama y el flujo de trabajo ejecutado para cubrir sus huellas.

Propagación del gusano en npm

Este es el componente autorreplicante. Cuando el malware encuentra un token de npm (npm_...), realiza las siguientes actividades.

Validación de tokens

Llama a la API de tokens de npm con Authorization: Bearer <token>, verifica que el token tiene permiso de publish (escritura) en el ámbito del paquete y que omite la autenticación de dos factores (2FA).

Enumeración de paquetes

Utiliza el token validado para realizar las siguientes actividades:

• Obtener del nombre de usuario de npm.
• Recorrer los recursos permitidos del token (orgs, ámbitos, paquetes específicos).
• Consultar /-/org/<user>/package para los paquetes con permisos de escritura.
• Volver a /-/v1/search?text=maintainer:<user> para los paquetes públicos.

Descarga de tarballs y puertas traseras

Con cada paquete objetivo, realiza lo siguiente:

• Descarga el último tarball del registro de npm.
• Extrae a un directorio temporal.
• Copia el binario Bun en el paquete.
• Reescribe el package.json.
  • Borra todos los scripts.
  • Establece "preinstall": "node setup.mjs" (decodificado del codificador).
  • Aumenta la versión del parche (por ejemplo, 1.2.3 → 1.2.4).
• Escribe setup.mjs con la carga útil completa del gusano (K$, una copia codificada en gzip+Base64 del malware).
• Vuelve a empaquetar el tarball.

Publicación

Escribe un .npmrc con la línea auth del token robado (//registry.npmjs[.]org/:_authToken=<token>) y ejecuta bun publish <tarball>.

Cada nuevo paquete infectado activará la misma cadena de preinstalación en cualquier desarrollador que lo instale, creando un vector de propagación exponencial.

Resiliencia de C2: el dead drop de GitHub

El malware implementa un mecanismo de respaldo para la resiliencia de C2 utilizando la API de búsqueda pública de GitHub como canal de comando encubierto.

Si el servidor C2 primario (audit.checkmarx[.]cx) es inalcanzable, el malware realiza lo siguiente:

1. Busca en los commits de GitHub la palabra clave beautifulcastle a través de la API de búsqueda pública.
2. Encuentra un commit coincidente en [helloworm00/hello-world](hxxps[:]//github[.]com/helloworm00/hello-world) (commit bc544f4, fechado el 21 de abril, un día antes del ataque principal).
3. Analiza el cuerpo del mensaje de commit con la regex /beautifulcastle ([A-Za-z0-9+/=]{1,30})\.([A-Za-z0-9+/=]{1,700})/.
4. Decodifica el primer grupo de captura de Base64 para obtener un dominio.
5. Verifica el segundo grupo de captura como una firma digital (RSA-4096 de 512 bytes) contra la clave pública codificada Er. Esto garantiza que solo el atacante pueda dirigir el malware a un nuevo servidor C2.

En el momento del análisis, el dead drop contenía un valor de marcador de posición (hxxps[:]//ejemplo[.]com), lo que indicaba que estaba preparado para un uso futuro. El atacante puede rotar la infraestructura C2 en cualquier momento creando un nuevo commit firmado en cualquier repositorio público de GitHub.

Un segundo mecanismo de respaldo (función Hr) busca commits que coincidan con LongLiveTheResistanceAgainstMachines:<base64> para recuperar tokens de GitHub previamente robados de repos de exfiltración, iniciando nuevos canales de exfiltración basados en GitHub sin una infraestructura controlada por el atacante.

Medidas antidetección

• Mecanismo de desactivación basado en configuración regional rusa: La función mz0 comprueba Intl.DateTimeFormat().resolvedOptions().locale, LC_ALL, LC_MESSAGES, LANGUAGE y LANG detectar configuraciones regionales rusas (ru). Si alguna coincide, el malware llama a process.exit(0) inmediatamente sin ejecutar.
• Ejecución como demonio: la función Ml0 reinicia el proceso separado con __DAEMONIZED=1 en el entorno, permitiendo que el proceso principal salga limpiamente mientras la carga útil se ejecuta en segundo plano.
• Archivo de bloqueo basado en PID: $l0 escribe process.pid en un archivo temporal y comprueba si una instancia anterior sigue viva mediante process.kill(pid, 0), evitando que se ejecuten varias instancias en simultáneo.
• Controladores de señales: captura SIGINT/SIGTERM con callbacks sin operación (() => {}) para impedir las interrupciones.
• Limpieza de directorios temporales: tras la manipulación del tarball, se eliminan los artefactos forenses.
• Todas las cadenas sensibles: codificado mediante el codificador o gzip+Base64.
• Gestión silenciosa de errores: los fallos se detectan y suprimen.
• Nombramiento inocuo: la ruta de C2 v1/telemetry imita endpoints de análisis legítimos.

Guías provisionales

1. Bloquee los dominios C2 y las IP enumeradas anteriormente en el perímetro de la red.
2. Rote todas las credenciales que puedan haber estado expuestas: tokens de npm, PAT de GitHub, claves de AWS/Azure/Google Cloud, claves SSH y secretos CI/CD.
3. Audite los paquetes de npm que mantiene en busca de cambios de versión no autorizados o nuevos hooks de preinstall.
4. Revise GitHub para detectar la creación de repositorios no autorizada, archivos de flujo de trabajo inesperados y descargas de artefactos.
5. Busque el artefacto format-results en los registros de GitHub Actions de la organización.
6. Busque la ejecución inesperada de procesos Bun y conexiones salientes a la infraestructura de indicadores de vulneración (IoC).
7. Vincule las dependencias a versiones buenas conocidas mediante archivos de bloqueo y hashes de integridad.

Consultas de búsqueda de amenazas gestionada de Unit 42

El equipo de búsqueda de amenazas gestionada de Unit 42 continúa rastreando cualquier intento de explotar esta CVE entre nuestros clientes utilizando Cortex XDR y las consultas XQL que se muestran a continuación. Los clientes de Cortex XDR también pueden usar estas consultas XQL para buscar signos de explotación.

La siguiente consulta XQL se ha utilizado para identificar con éxito la ejecución de un archivo JavaScript a través de Bun que, luego, llama a la CLI de GitHub probablemente en un intento de recopilar tokens de autenticación almacenados localmente. Si bien Bun es legítimo en muchos entornos de desarrollo, su uso como entorno de ejecución para malware de instalación de paquetes en esta campaña hace que valga la pena investigar este comportamiento cuando se observa con comandos de acceso a credenciales como gh auth token:

Conclusión

Unit 42 ha sido testigo de un cambio desde el incidente de Shai-Hulud de septiembre de 2025, lo que demostró que no se trataba de un pico temporal, sino de la nueva línea de base para el riesgo que corre la cadena de suministro de software. En un ecosistema en el que el código se comparte a la velocidad del pensamiento, una sola dependencia comprometida puede desencadenar una cascada global.

En última instancia, los compromisos de npm comparten aspectos y las organizaciones pueden navegar por esta volatilidad teniendo en cuenta determinadas prácticas recomendadas. A medida que continuamos supervisando, analizando y actualizando los hallazgos sobre los paquetes de npm, le recomendamos ir más allá de las defensas estáticas y adoptar una cultura de verificación continua. Quizás la cadena de suministro sea el nuevo objetivo principal, pero con inteligencia colectiva y visibilidad implacable, no tiene por qué ser la vulnerabilidad principal.

Mitigación para paquetes de npm comprometidos

Aplicar periodos de enfriamiento: implemente una política (a través de un registro privado o proxy como Artifactory) que bloquee cualquier versión de paquete publicada en las últimas 24 a 72 horas. La mayoría de los paquetes maliciosos se identifican y eliminan del registro público dentro de esta ventana de tiempo.

Desactivación de los scripts del ciclo de vida: muchas vulneraciones se basan en hooks de preinstalación o postinstalación para exfiltrar secretos. Utilice lo siguiente en su .npmrc: ignore-scripts=true.

Fijación de versiones y npm ci: utilice package-lock.json y asegúrese de que sus canales de CI/CD utilicen npm ci en lugar de npm install. Esto evita la actualización “oculta” de dependencias durante una compilación.

Proxy de registro privado: nunca permita que las máquinas de los desarrolladores o los ejecutores de CI se comuniquen directamente con registry.npmjs[.]org. Dirija todo el tráfico a través de un registro privado.

Ocultamiento de espacios de nombres (prevención de la confusión de dependencias): los atacantes suelen publicar en el registro público paquetes con el mismo nombre que sus bibliotecas internas. Utilice siempre paquetes con ámbito definido (por ejemplo, @myorg/internal-lib) y configure su registro privado para que solo resuelva ese ámbito internamente.

Verificación de la procedencia: verifique el certificado de OpenID Connect. Muchos paquetes importantes proporcionan “procedencia”, lo que demuestra que el código se construyó en un ejecutor específico de GitHub/GitLab. Utilice herramientas como slsa-verifier para comprobarlo durante la compilación.

Filtrado de salida en CI/CD: La mayoría del malware basado en npm intenta enviar tokens ~/.npmrc o claves ~/.ssh a un servidor C2. Aplique estrictas políticas de red de salida a sus ejecutores de CI. Solo permita conexiones a su registro privado y a objetivos de implementación conocidos.

Lista de materiales de software (SBOM): genere automáticamente una lista de materiales de software para cada versión de producción. Esto le permite a su equipo de seguridad realizar un análisis de impacto instantáneo cuando se anuncia un nuevo día cero.

Palo Alto Networks ha compartido nuestros resultados con nuestros compañeros de Cyber Threat Alliance (CTA). Los miembros de CTA utilizan esta inteligencia para implementar rápidamente medidas de protección para sus clientes y desarticular sistemáticamente a los ciberdelincuentes. Obtenga más información sobre Cyber Threat Alliance.

Los clientes de Palo Alto Networks están mejor protegidos gracias a nuestros productos, como se indica a continuación. Actualizaremos este resumen de amenazas a medida que dispongamos de más información pertinente.

Protecciones de productos de Palo Alto Networks relacionadas con paquetes de npm comprometidos

Los clientes de Palo Alto Networks pueden aprovechar varias protecciones y actualizaciones de productos para identificar y defenderse contra esta amenaza.

Si cree que podría haber resultado vulnerado o tiene un problema urgente, póngase en contacto con el equipo de respuesta ante incidentes de Unit 42 o llame al:

• Norteamérica: llamada gratuita: +1 (866) 486-4842 (866.4.UNIT42)
• Reino Unido: +44.20.3743.3660
• Europa y Oriente Medio: +31.20.299.3130
• Asia: +65.6983.8730
• Japón: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 000 800 050 45107
• Corea del Sur: +82.080.467.8774

Advanced WildFire

Los modelos de aprendizaje automático y las técnicas de análisis de Advanced WildFire se han revisado y actualizado a la luz de los indicadores asociados con las vulneraciones de npm, incluido el paquete malicioso Bitwarden.

Servicios de seguridad entregados en la nube para el firewall de nueva generación

Advanced URL Filtering yAdvanced DNS Security identifican los dominios y las direcciones IP conocidas que se asocian con esta actividad como maliciosos.

Cortex Cloud

El Módulo de Seguridad de Aplicaciones (ASPM) de Cortex Cloud admite el escaneo de paquetes de npm instalados en recursos en la nube, así como el monitoreo de registros de auditoría de terceros proveedores de SaaS, incluido GitHub, como se discute en este artículo. Cortex Cloud prioriza las alertas, los problemas, las políticas y los activos en función de las aplicaciones ingeridas y de su uso. Esto les permite a los equipos de seguridad seguir siendo conscientes de la seguridad en las instalaciones y en el entorno de nube mediante la identificación y la remediación de los recursos en la nube afectados y la respuesta activa a las operaciones en tiempo de ejecución asociadas de las amenazas analizadas en este artículo a través del agente XDR y de las operaciones sin servidor de Cortex Cloud. Para conocer con más detalle cómo protegerse contra esta amenaza utilizando Cortex Cloud, consulte el blog.

Seguridad de endpoints agéntica de Koi

Koi Agentic Endpoint Security les permite a los clientes retrasar las actualizaciones automáticas de todos los paquetes instalados por un período de tiempo establecido, por lo que las versiones recién lanzadas ganan una reputación y son sometidas a escrutinio público antes de que las implementen en su entorno.

Indicadores de vulneración

Actividad de los indicadores a partir del 29 de abril de 2026

Paquetes afectados

• @cap-js/sqlite@2.2.2
• @cap-js/postgres@2.2.2
• @cap-js/db-service@2.10.1
• mbt@1.2.48

SHA256 Hashes

• setup.mjs: 4066781fa830224c8bbcc3aa005a396657f9c8f9016f9a64ad44a9d7f5f45e34
• execution.js: 6f933d00b7d05678eb43c90963a80b8947c4ae6830182f89df31da9f568fea95

URL

• hxxps[:]//github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/ (descarga de Bun)
• hxxps[:]//api.github[.]com/search/commits?q=OhNoWhatsGoingOnWithGitHub (dead drop)

Actividad de los indicadores a partir del 22 de abril de 2026

Indicadores de red

En la Tabla 3, se presentan los indicadores de red de esta actividad.

Tabla 3. Indicadores de red.

Indicadores de GitHub

En la Tabla 4, se enumeran los indicadores de GitHub de esta actividad.

Tabla 4. Indicadores de GitHub.

Indicadores de proceso y archivos

En la Tabla 5, se enumeran los indicadores de archivos y procesos de esta actividad.

Tabla 5. Indicadores de proceso y archivos.

Indicadores de npm

En la Tabla 6, se presentan los indicadores de npm de esta actividad.

Tabla 6. Indicadores de npm.

Referencias adicionales

• Checkmarx Security Update: April 22, 2026 (Actualización de seguridad de Checkmarx: 22 de abril de 2026), Checkmarx.
• Malicious Checkmarx Artifacts Found in Official KICS Docker Repository and Code Extensions (Artefactos maliciosos de Checkmarx encontrados en el repositorio oficial de Docker de KICS y en extensiones de código), Socket.
• Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure (Armar a los protectores: ataque multifase de TeamPCP a la cadena de suministro dirigido contra la infraestructura de seguridad)
• Threat Brief: Widespread Impact of the Axios Supply Chain Attack (Informe de amenazas: el impacto generalizado del ataque a la cadena de suministro de Axios)
• “Shai-Hulud” Worm Compromises npm Ecosystem in Supply Chain Attack (Updated November 26) (El gusano “Shai-Hulud” compromete el ecosistema de npm en un ataque a la cadena de suministro [actualizado el 26 de noviembre])
• Bitwarden CLI Impersonation Attack Steals Cloud Credentials and Spreads Across npm Supply Chains (El ataque de Bitwarden de suplantación de CLI roba credenciales en la nube y se extiende por las cadenas de suministro de npm), Cortex Cloud, Palo Alto Networks

Actualizado el 27 de abril de 2026 a las 2.15 p. m. PT para añadir información sobre Bitwarden y enlazar con el artículo de Cortex Cloud en la sección “Referencias adicionales”.

Actualizado el 1 de mayo de 2026 a las 5:55 p m. PT para añadir información sobre la campaña de Mini Shai-Hulud.

Actualizado el 20 de mayo de 2026 a las 12:30 p. m. PT para actualizar el Resumen Ejecutivo con información sobre dos nuevas oleadas y agregar una nueva sección sobre las oleadas de Mini-Shai Hulud de mayo de 2026.

Actualizado el 21 de mayo de 2026 a las 8:45 a. m. PT para agregar consultas de búsqueda de amenazas gestionada y protección adicional del producto.