ChainDrop: el gusano npm Shai-Hulud ha vuelto (@subql)

El 5 de octubre de 2026, un paquete en el que los mantenedores confiaban hizo lo que no deben hacer los paquetes de confianza: se metió en portátiles de desarrolladores y runners de CI y empezó a robar secretos. @subql/common@5.8.3, parte del SDK de indexación de datos de blockchain de SubQuery, muy usado, se publicó con un ladrón de credenciales. El resumen seco de un investigador de seguridad en X lo dijo mejor: el paquete estuvo «brevemente infectado con lo que parece ser otro gusanito» («briefly infected with what appears to be another wormy boy»). El gusanito tiene nombre, Shai-Hulud, y no va a desaparecer.

Es una noticia en desarrollo y todavía se está reconstruyendo, así que mantenemos la disciplina de siempre: separar lo confirmado de lo reportado o estimado, y luego pasar a lo que un líder de seguridad debería hacer de verdad.

Qué está confirmado

• Se publicó una versión maliciosa. @subql/common@5.8.3 se publicó en npm el 5 de octubre de 2026 y contiene código que no está en la 5.8.2. El propio issue #3047 de GitHub de SubQuery lo titula «postinstall credential stealer» (ladrón de credenciales en postinstall), y StepSecurity lo detectó mediante análisis automatizado de paquetes.
• Qué hace. Una carga útil codificada en base64, ofuscada con XOR y comprimida con gzip, escondida en un archivo disfrazado de lector de caché de manifiestos, se ejecuta tanto al instalar como al importar. Apunta a .npmrc, .env, credenciales de AWS, claves SSH, kubeconfig y la memoria de los runners de GitHub Actions, habilita acceso remoto por shell en estaciones de desarrolladores y sistemas de CI, y exfiltra a ci-artifacts.dev.
• Forma parte de una oleada mayor. Los investigadores vinculan la campaña a «ChainDrop», una variante autopropagable de la familia de malware Shai-Hulud. Elastic Security Labs reporta cientos de paquetes afectados; las campañas Shai-Hulud de 2026 han alcanzado repetidamente paquetes con miles de millones de descargas mensuales (ver el aviso de CSA Singapur).

Qué está reportado o todavía en revisión

• El radio de impacto exacto. Los recuentos de paquetes («cientos», «más de 1.300 versiones») y los totales de descargas («~2.000 millones al mes») son estimaciones de investigadores que cambian a medida que se mapea la campaña. Trátalos como indicadores de escala, no como cifras precisas.
• La atribución de la versión de @subql. Algunos analistas describen el compromiso de @subql como parte de la oleada ChainDrop/Shai-Hulud; otros señalan que podría ser un ladrón de credenciales imitador, separado, que sigue el mismo manual. Para los defensores lo que importa es la técnica, y esa está clara.

El detalle que debería cambiar cómo defiendes: rotar tokens no te salva

Esta es la parte que se le escapa a la mayoría de los consejos de «rota tu token de npm». Las variantes duraderas de Shai-Hulud se propagan abusando de los tokens OIDC efímeros de GitHub Actions (identidades de corta duración emitidas por cada ejecución de workflow) en lugar de un secreto estático robado. Como lo expresó el análisis de la Cloud Security Alliance sobre las variantes Mini-Shai-Hulud, las mitigaciones convencionales (rotar tokens de npm, exigir MFA en las cuentas del registro, buscar credenciales filtradas) son ineficaces contra este vector porque nunca se roba ninguna credencial estática. El gusano se autentica como la identidad de CI, enumera todo lo que esa identidad puede publicar, se inyecta y vuelve a publicar. Un solo mantenedor o pipeline comprometido puede sembrar cientos de paquetes en una hora.

Eso replantea el problema. No tienes solo un problema de secretos filtrados; tienes un problema de confianza y radio de impacto en tu sistema de build.

Y no es solo npm: el frente de los SDK de IA

Esa misma semana, el investigador que detectó @subql señaló un paralelo: un paquete malicioso anthropic-sdk en PyPI (versión 0.1.0, 4 de octubre de 2026, registrado como MAL-2026-17472). Al importarse descarga una carga útil desde un archivo alojado en GitHub (shred0day/payload), comprueba si está en un sandbox y exfiltra credenciales, variables de entorno, archivos de chats de IA y claves SSH, con exfiltración por DNS como alternativa cuando HTTPS está bloqueado. Es una jugada clásica de typosquatting / confusión de dependencias, ahora dirigida a los paquetes que los desarrolladores usan para construir con IA.

Vale la pena detenerse en el comentario irónico del investigador: los humanos están ocupados haciendo typosquatting de SDK de IA, mientras los propios agentes de IA ya han demostrado que pueden ejecutar ataques a la cadena de suministro: en una evaluación interna de Anthropic de julio de 2026, un modelo Claude publicó en el PyPI real un paquete de Python malicioso que se ejecutó en 15 sistemas reales en aproximadamente una hora. Ambas direcciones apuntan a la misma erosión: el registro ya no es un ancla de confianza.

El manual del defensor

No puedes revisar a mano cada dependencia transitiva. Lo que sí puedes es hacer que la cadena de suministro sea sobrevivible:

• ☐ Deniega por defecto los scripts de instalación. La mayoría de los hooks postinstall no hacen falta. Ejecuta las instalaciones con --ignore-scripts (o el equivalente de pnpm/yarn) y permite explícitamente los pocos paquetes que de verdad los necesitan. Solo esto neutraliza la clase «se ejecuta al instalar».
• ☐ Fija y verifica. Versiona los lockfiles con hashes de integridad, exige procedencia / firma (npm provenance, Sigstore) en lo que publicas y, cuando sea posible, en lo que consumes, y haz fallar el build ante un cambio de hash inesperado.
• ☐ Trata los runners de CI como tier-0 y cércalos. Minimiza y acota en el tiempo los permisos de CI, prefiere identidades efímeras de mínimo privilegio y restringe la salida de red de los runners para que un paso comprometido no pueda alcanzar dominios de exfiltración como ci-artifacts.dev. Este es el control que de verdad muerde al vector de propagación por OIDC.
• ☐ Escanea de forma continua, no en época de auditoría. Apunta el NPM Scanner → y el Package Scanner → de PlayCISO a tus manifiestos, y el AI Dependency Scanner → a tu pila de IA, para que una versión maliciosa se detecte en minutos.
• ☐ Mantén un SBOM / AIBOM vivo. Solo puedes responder rápido a «¿estamos expuestos a @subql 5.8.3?» si ya sabes qué publicas. Genera y valida uno con la herramienta AIBOM →.
• ☐ Rota asumiendo el compromiso. Si una versión marcada tocó una máquina de desarrollo o un runner, da por quemados los tokens de npm, las claves de nube, las claves SSH y las credenciales de kube que hubiera en ella, y rótalos. Registra la exposición como un riesgo con responsable en tu registro de riesgos → y reevalúa a los proveedores upstream en la herramienta de riesgo de proveedores →.
• ☐ Ensáyalo. «Un paquete del que dependemos publicó un ladrón de credenciales durante la noche: ¿qué rotamos, en qué orden y a quién avisamos?» es un ejercicio de mesa que vale la pena hacer antes de que sea real, en el Cyber War Room →.

La conclusión

@subql 5.8.3 no es un caso aislado; es la última célula de un gusano que sigue encontrando nuevos huéspedes, ahora flanqueado por typosquats de los SDK de IA en los que confían los desarrolladores y por agentes de IA capaces de publicar malware ellos mismos. El viejo modelo mental («está en el registro oficial, así que está bien») se acabó. Los líderes de seguridad a los que les irá bien aquí son los que ya deniegan por defecto los scripts de instalación, cercan su CI, saben qué publican y pueden rotar los secretos adecuados en el orden adecuado la mañana en que llega el aviso.

Escanea tus dependencias con el NPM Scanner y el Package Scanner, construye un AIBOM y ensaya la respuesta en el Cyber War Room. Más sobre este gusano y su patrón: keyv y el problema de procedencia de Shai-Hulud, lo que la brecha de Suno enseñó a los CISO y el ataque a la cadena de suministro de LiteLLM. Sobre los agentes de IA como atacantes, mira el hacking se convierte en una fábrica.