Gusano testmetest: payloads de 13 MB en 42 repositorios GitHub

La campaña npm llamada testmetest, que parecía una simple prueba sin víctimas, en realidad ya había armado 42 repositorios reales de GitHub de 11 propietarios. Lo documentó JFrog Security Research en un informe del 26 de octubre, recogido por The Register y CSO Online. El detalle que hace difícil encontrar la campaña: los archivos con el payload pesan entre 12,9 y 13,7 MB, por encima de los límites de la búsqueda de código y de la API de contenidos de GitHub. heise Security también publicó la noticia, pero su texto no estaba disponible para este análisis.

Hace pocos días contamos el caso de Gheist, que con tokens de GitHub robados extrae los secretos de los logs de Actions. testmetest es una campaña distinta: un gusano que se propaga a través de npm, roba credenciales y se esconde dentro de los repositorios de las víctimas.

Del «test» a víctimas reales

Según The Register, la empresa SafeDep fue la primera en detectar la campaña, con 18 paquetes npm publicados por el mismo operador entre el 19 y el 25 de octubre. En su análisis del 22 de octubre, que decodificaba event-bus-lite-testmetest@0.0.1, SafeDep no había encontrado paquetes de terceros comprometidos: toda la actividad parecía proceder de las cuentas de prueba del operador. SafeDep vinculaba el payload a la familia Miasma, aunque señalaba dudas sobre su origen. The Register informa de que el código se comparte con el gusano Miasma Phantom Gyp de junio y añade el wiper de Mini Shai-Hulud, que borra la carpeta home de la víctima cuando esta revoca el token de GitHub robado.

JFrog, cuyos sistemas habían detectado paquetes de tipo Shai-Hulud en npm el 21 de octubre, encontró en cambio robos de cuentas desde julio, cronologías de commits falsificadas, ramas de publicación de corta duración y credenciales npm expuestas.

Cómo funciona la cadena

Instalación del paquete npm. Según el informe citado por CSO Online, las versiones maliciosas usan una expansión de comandos en binding.gyp para ejecutar index.js durante la instalación, sin declarar un script de instalación. El loader aplica en cada build una transformación César a un array de códigos de carácter, descifra una etapa AES-128-GCM y localiza o descarga Bun 1.2.18; el payload se pasa a bun run - o se escribe en una carpeta temporal .b-* que se elimina tras la ejecución. El payload completo recopila credenciales, modifica repositorios y configuraciones de CI y se propaga a través de los registros de paquetes.

Repositorios armados. En los repositorios secuestrados la campaña deja marcadores inofensivos o payloads reales: hooks de ejecución para asistentes de IA y entornos de desarrollo (un hook SessionStart de Claude Code, ajustes de Gemini, configuración MCP y reglas de Cursor, tareas de VS Code al abrir la carpeta) y wrappers polimórficos de 12,9 a 13,7 MB que se decodifican todos en el mismo payload oculto. Basta con abrir el proyecto con una de estas herramientas para ejecutarlo. Los archivos ci.js armados contienen publicadores pensados para ejecutarse en GitHub Actions y usar tokens npm o el trusted publishing para publicar nuevas versiones maliciosas: el ciclo se cierra.

El tamaño como camuflaje. Los wrappers superan lo que la búsqueda de código de GitHub indexa y lo que la API de contenidos devuelve: por eso, según un analista citado por CSO Online, los primeros análisis encontraron los hooks pero dieron por vacíos los archivos del payload.

Addon nativo y evasión. Un addon compilado no contiene payload propio: descifra en tiempo de ejecución un archivo .napi_cache. Antes de arrancar, el loader busca runners de CI, contenedores, sandboxes y depuradores y, si los encuentra, sale sin hacer nada. Una segunda build se salta el archivo cifrado y descarga un loader de un repositorio de la cuenta de GitHub del operador, CementBeetleSteeple, que alojaba 17 repositorios de la campaña; según JFrog, un repositorio del atacante es también un punto activo de recogida de datos cifrados.

Vínculo con cPanel. JFrog relaciona la misma cuenta con un escáner «shellpanel», ya descrito por Socket en una campaña que usaba GitHub Actions en repositorios comprometidos para explotar CVE-2026-41940, un bypass de autenticación de cPanel y WHM (en el catálogo KEV de CISA desde abril, con versiones corregidas disponibles), y robar credenciales de servidores. JFrog precisa que no ha confirmado compromisos derivados de servidores cPanel.

En nuestra lectura, las técnicas MITRE ATT&CK pertinentes son T1195.002 (Compromise Software Supply Chain), T1078 (Valid Accounts), T1027 (Obfuscated Files or Information), T1497 (Virtualization/Sandbox Evasion), T1552.001 (Credentials In Files) y T1485 (Data Destruction) para el wiper.

Impacto para las empresas europeas e italianas

El riesgo afecta a cualquiera que desarrolle con paquetes npm o trabaje con repositorios de GitHub de terceros: el portátil de un desarrollador contiene tokens de GitHub y npm, claves de la nube y claves de proveedores de IA. Con los hooks de los asistentes de IA, el momento peligroso ya no es solo la instalación, sino también la simple apertura de un proyecto. Para las entidades sujetas a NIS2, la seguridad de la cadena de suministro del software es una medida obligatoria, y el uso de credenciales robadas en sistemas de producción debe evaluarse como posible incidente notificable.

Qué hacer ahora

Recomendaciones de JFrog recogidas por CSO Online, salvo indicación contraria:

1. Trata como comprometida cualquier máquina en la que se haya instalado una versión completa del gusano.
2. Antes de revocar los tokens (recomendación nuestra): el wiper descrito por The Register se activa al revocar el token de GitHub. Aísla la máquina y pon a salvo los datos de la carpeta home, y después continúa.
3. Revoca y rota las credenciales de GitHub, GitLab, npm, PyPI, RubyGems, nube, SSH, Vault, Kubernetes y proveedores de IA.
4. Revisa todos los repositorios accesibles para las identidades afectadas: .github/init.js, .claude/settings.json, .gemini/settings.json, .cursor/mcp.json, .cursor/rules/setup.mdc, .vscode/tasks.json, hooks inesperados en composer.json o Makefile, commits con skip-checks:true. Recorre directamente el árbol de archivos: no confíes en la búsqueda de código ni en la API de contenidos.
5. Limpia: borra las ramas no autorizadas chore/ci-* y deps/upd-*, desactiva los workflows maliciosos y elimina los falsos artefactos de CodeQL llamados scan-output.
6. Bloquea hxxp[:]//43[.]228[.]157[.]68:80 y la infraestructura relacionada.
7. Busca en los logs y runners de GitHub Actions /tmp/.svc, ipscan, referencias a CVE-2026-41940, peticiones /api/dl/<arch> y escaneos inusualmente amplios; en las máquinas, archivos .napi_cache.
8. Actualiza cPanel y WHM a las versiones corregidas para CVE-2026-41940, si los usas.

Cómo ayuda ARXDOME

ARX Sentry recoge con su agente logs, eventos, inventario de procesos y control de integridad de archivos en las carpetas definidas, también en los equipos de los desarrolladores y en los runners self-hosted. Con ARX Trace nuestros analistas pueden lanzar recolecciones y búsquedas en varias máquinas para localizar los indicadores enumerados, y ARX Shield permite aislar de la red una máquina sospechosa antes de revocar los tokens.

Última actualización: 29 de octubre de 2026