Un paquete infectado podía abrir la puerta a GitHub, AWS y sistemas de producción, advierte reporte

Un informe técnico reveló que múltiples paquetes npm del ámbito @redhat-cloud-services distribuyeron malware capaz de robar secretos de GitHub Actions, credenciales cloud y tokens npm. La carga maliciosa también intentaba propagarse de forma autónoma republicando paquetes comprometidos.
***

• El malware se ejecutaba mediante un hook preinstall durante cada npm install y usaba varias capas de ofuscación.
• La carga apuntaba a secretos de GitHub Actions, AWS, GCP, Azure, Kubernetes, Vault, npm, CircleCI, SSH, Docker y archivos .env.
• El ataque incluía capacidades de gusano, persistencia en estaciones de trabajo y exfiltración mediante api.github.com.

Un nuevo incidente de cadena de suministro volvió a poner bajo presión al ecosistema de desarrollo JavaScript. Varios paquetes npm bajo el ámbito @redhat-cloud-services distribuyeron una carga maliciosa que se activaba de forma automática durante la instalación.

Según un análisis publicado por StepSecurity y firmado por Rohan Prabhu el 1 de junio de 2026, el malware se ejecutaba mediante un hook preinstall en cada npm install. Eso significa que el ataque podía comenzar antes de que la aplicación del usuario ejecutara su propio código.

La carga no se limitaba a una simple extracción de tokens. El informe la describe como un recolector de credenciales de múltiples etapas, diseñado para buscar secretos de GitHub Actions, AWS, GCP, Azure, Kubernetes, HashiCorp Vault, npm, CircleCI y otros entornos usados por desarrolladores.

El caso resulta especialmente relevante para empresas que dependen de pipelines de CI/CD. En esos flujos, los paquetes de software pueden instalarse de forma automática con permisos amplios y acceso temporal a secretos críticos.

Un ataque que comenzó en npm install

El punto de entrada estaba en el archivo package.json de los paquetes afectados. Cada versión maliciosa declaraba un script preinstall que ejecutaba node index.js, una rutina que npm invoca durante la instalación.

Ese archivo index.js medía 4,2 MB, un tamaño anómalo para una biblioteca de este tipo. La carga real quedaba enterrada bajo varias capas de ofuscación, lo que dificultaba el análisis estático y la detección temprana.

La primera capa usaba ROT-21 sobre un gran arreglo de códigos numéricos reconstruidos con String.fromCharCode. Además, el código quedaba envuelto en un bloque try y catch silencioso, para evitar errores visibles en la consola del desarrollador.

La segunda capa revelaba un archivo JavaScript de 1,27 MB con dos blobs cifrados mediante AES-128-GCM. Uno correspondía a un descargador del runtime Bun y otro al implante principal de la carga.

El análisis también identificó una tercera capa basada en obfuscator.io, con alfabeto base64 personalizado y rotación de una tabla de 2.219 entradas. La cuarta capa usaba un cifrado personalizado descrito como B5, con PBKDF2 de 200.000 iteraciones, Fisher-Yates y cadenas sensibles cifradas.

Credenciales cloud, tokens npm y secretos de GitHub en la mira

La carga apuntaba de forma directa a secretos vivos dentro de GitHub Actions. Una de sus capacidades más graves consistía en leer /proc/<pid>/mem para extraer datos desde la memoria del proceso Runner.Worker.

El malware consultaba la API de runtime de GitHub Actions mediante ACTIONS_RUNTIME_TOKEN. Con esa información, enumeraba variables de entorno y detectaba cuáles tenían la marca isSecret: true, la misma que GitHub usa para ocultar valores en los registros.

Esta técnica buscaba evadir el mecanismo de enmascaramiento de logs. Aunque un secreto nunca apareciera impreso en consola, el malware podía intentar leerlo desde el espacio de memoria del runner.

El barrido también incluía variables y archivos locales. Entre los objetivos figuraban GITHUB_TOKEN, ACTIONS_ID_TOKEN_REQUEST_TOKEN, NPM_TOKEN, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, credenciales predeterminadas de GCP, secretos de Azure, VAULT_TOKEN y configuraciones de Kubernetes.

La lista se extendía a ~/.npmrc, ~/.pypirc, claves SSH como id_rsa e id_ed25519, ~/.docker/config.json, directorios GPG y archivos .env en el sistema. Para equipos de infraestructura, esa amplitud eleva el riesgo más allá de npm.

Paquetes y versiones afectadas

El compromiso abarcó múltiples paquetes del ecosistema frontend de Red Hat Cloud Services. Todas las versiones afectadas habrían sido publicadas mediante GitHub Actions OIDC desde el repositorio RedHatInsights/javascript-clients.

Ese detalle apunta a un posible compromiso del pipeline upstream de CI/CD, no solo a credenciales aisladas de publicación. La firma indicó que abrió issues de divulgación en RedHatInsights/javascript-clients#492, RedHatInsights/frontend-components#2329 y RedHatInsights/platform-frontend-ai-toolkit#57.

La recomendación central para organizaciones expuestas es asumir compromiso si instalaron cualquiera de estas versiones. En ese escenario, los equipos deben rotar credenciales, revisar ejecuciones de CI/CD y analizar estaciones de trabajo de desarrolladores.

La cantidad de paquetes afectados amplía el radio potencial del incidente. También complica la respuesta, porque una organización puede haber instalado una dependencia directa o haberla recibido como dependencia transitiva.

Un gusano capaz de republicar paquetes en npm

El informe describe una capacidad de autopropagación. Con tokens npm robados, la carga intentaba enumerar paquetes publicables por la cuenta víctima y subir versiones troyanizadas.

Un elemento clave era el uso del parámetro bypass_2fa de npm. Ese mecanismo puede operar con tokens de automatización y, en este caso, servía para evadir requisitos de autenticación de dos factores durante la publicación.

La consecuencia es grave. Una sola máquina infectada podía sembrar la siguiente ola de paquetes comprometidos, sin requerir nuevas acciones del atacante.

Este patrón convierte el incidente en algo más cercano a un gusano de cadena de suministro que a una intrusión puntual. En ecosistemas con dependencias automáticas, versiones rápidas y CI/CD distribuido, esa dinámica puede crecer con rapidez.

Para proyectos vinculados a Web3, fintech o infraestructura de pagos, el riesgo adquiere otra dimensión. Las mismas máquinas que construyen software pueden almacenar tokens de despliegue, llaves cloud o credenciales que protegen servicios críticos.

Exfiltración por GitHub y persistencia en herramientas de desarrollo

La infraestructura de comando y control usaba https://api.github.com con el agente de usuario python-requests/2.31.0. En la capa de red, ese tráfico podía parecer una llamada legítima a la API de GitHub.

La carga seleccionaba al azar una cuenta de un pool de 16 nombres: typhonian, tartarean, erebean, stygian, orphic, nemean, spartan, basilisk, manticore, styx, aegis, thunderbolt, tempest, cataclysm, onslaught y havoc.

El malware también implementaba un canal encubierto mediante GitHub. Con un GITHUB_TOKEN recolectado, podía crear referencias y commits con datos robados codificados en base64 dentro de repositorios controlados por la víctima.

Esa técnica aprovecha que api.github.com suele estar permitido en políticas de red de CI. Para muchos sistemas de monitoreo, la exfiltración podía parecer una operación normal de desarrollo.

La persistencia en estaciones de trabajo tampoco quedó fuera del diseño. La carga podía inyectar un hook SessionStart en la configuración de Claude Code y crear una tarea folderOpen en VS Code, para ejecutar comandos cuando el desarrollador iniciara sesiones o abriera carpetas.

Cómo deben responder los equipos afectados

La respuesta inicial debe partir de una premisa conservadora. Si un pipeline o una estación de trabajo instaló cualquiera de las versiones afectadas, el entorno debe tratarse como comprometido hasta completar la investigación.

Los equipos deberían rotar tokens de GitHub, npm, AWS, GCP, Azure, Vault, Kubernetes y CircleCI que hayan estado presentes en los entornos expuestos. También conviene revisar claves SSH, archivos .env, credenciales Docker, GPG y configuraciones locales.

En CI/CD, la revisión debe incluir ejecuciones recientes, dependencias instaladas, paquetes publicados por cuentas internas y actividad inusual en repositorios. Cualquier publicación inesperada en npm merece análisis inmediato.

También resulta prudente buscar archivos de persistencia en estaciones de trabajo. En particular, las rutas de configuración de Claude Code y las tareas de VS Code pueden revelar intentos de supervivencia tras borrar el paquete malicioso.

El caso recuerda una lección central de la seguridad moderna. En la cadena de suministro de software, una dependencia puede convertirse en una vía directa hacia secretos cloud, repositorios de código y sistemas de producción.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín