La seguridad de la Inteligencia Artificial y de la cadena de suministro de software acaba de sufrir un impacto histórico. A finales de marzo de 2026, el grupo cibercriminal TeamPCP ejecutó un ataque masivo y coordinado que logró vulnerar infraestructuras críticas a nivel global. No usaron fuerza bruta; utilizaron las propias herramientas de seguridad corporativas en contra de las empresas.

Si trabajas con Inteligencia Artificial, servidores en la nube o flujos de integración continua (CI/CD), necesitas entender cómo una vulnerabilidad en el escáner Trivy terminó comprometiendo LiteLLM, una librería de Python con 97 millones de descargas mensuales.

A continuación, desglosamos todos los detalles técnicos de esta campaña catalogada bajo el CVE-2026-33634, cómo funciona su persistencia indestructible basada en Blockchain, y qué debes hacer para protegerte.

(Si prefieres el formato en video, he subido una explicación completa y detallada a mi canal de YouTube:(https://youtu.be/0o3uvlpGnV4)).

1. El Origen del Desastre: La caída de Aqua Security (Trivy)

Todo comenzó a finales de febrero de 2026. Un bot automatizado llamado hackerbot-claw escaneó repositorios de GitHub en busca de configuraciones inseguras y encontró una mina de oro en el repositorio de Trivy, el popular escáner de vulnerabilidades de Aqua Security.

El bot aprovechó un flujo de trabajo configurado con pull_request_target, un evento en GitHub Actions que, si no se maneja correctamente, otorga permisos elevados al código de terceros. Al enviar una solicitud maliciosa, el código del atacante logró ejecutarse con acceso a los secretos del repositorio.

Para extraer las credenciales sin alertar a los sistemas de seguridad, los hackers utilizaron un script llamado memdump.py. Este código no tocó el disco duro; en su lugar, leyó directamente la memoria RAM del proceso Runner.Worker de GitHub Actions (/proc/<pid>/mem) y exfiltró los tokens de administrador utilizando expresiones regulares para cazar el formato JSON exacto de las claves.

Aunque Aqua Security revocó las credenciales tras descubrir la brecha, la rotación no fue completa. TeamPCP guardó el acceso residual y, el 19 de marzo, regresó para dar el golpe maestro: falsificaron firmas digitales e hicieron force-push para alterar 75 de las 76 “etiquetas de versión” (tags) del repositorio oficial trivy-action, incluyendo la popular versión v0.69.4.

A partir de ese momento, cualquier pipeline corporativo que descargara Trivy mediante esa etiqueta, descargaba en realidad un troyano.

2. El Impacto en la IA: El Hackeo de LiteLLM

El 24 de marzo de 2026, la onda expansiva alcanzó el ecosistema de la Inteligencia Artificial. El proyecto LiteLLM, utilizado como puerta de enlace y proxy para enrutar llamadas a más de 100 modelos de lenguaje (como OpenAI y Anthropic), utilizaba Trivy en sus rutinas de CI/CD para escanear su propio código.

Al ejecutar la versión zombi de Trivy, el malware extrajo silenciosamente el token oficial PYPI_PUBLISH del entorno de LiteLLM. Con estas llaves en su poder, TeamPCP no tuvo que hackear el repositorio de código de LiteLLM; simplemente subieron dos versiones maliciosas (1.82.7 y 1.82.8) directamente a PyPI.

Magia Negra en Python: El archivo .pth y el “Fork Bomb”

La versión 1.82.8 incluyó una técnica de evasión aterradora clasificada como MITRE ATT&CK T1546.018: el abuso de los ganchos de inicio de Python.

El paquete incluía un archivo oculto llamado litellm_init.pth. En Python, si un archivo .pth ubicado en la carpeta site-packages contiene código ejecutable, el intérprete de Python lo arranca automáticamente cada vez que se inicia el entorno.

No era necesario que el programador escribiera import litellm. Solo con tenerlo instalado, abrir cualquier script en Python despertaba al malware.

El descubrimiento de esta brecha fue casi un accidente. El malware en el archivo .pth abría un subproceso en Python para ejecutar su carga, lo que a su vez volvía a invocar el archivo .pth, creando un ciclo infinito conocido como Fork Bomb. Miles de máquinas colapsaron por el agotamiento masivo de la memoria RAM, lo que llevó al investigador Callum McMahon a descubrir el archivo base64 oculto de 34KB.

3. Robo Masivo y la “Infraestructura Inmortal” (ICP Blockchain C2)

Una vez activo, el malware realizaba un barrido completo del sistema de la víctima (hasta seis niveles de profundidad) robando :

• Claves privadas SSH y configuraciones de GitHub.
• Archivos .env y variables de entorno.
• Tokens de administración de la nube (AWS, Azure, GCP).
• Credenciales y tokens de Kubernetes.
• Billeteras de criptomonedas y claves de API de LLMs.

Todo se cifraba localmente usando AES-256-CBC, la llave se envolvía con RSA-4096 (para que solo el atacante pudiera leerlo), y se enviaba al dominio fraudulento models.litellm.cloud.

Pero la verdadera innovación táctica de TeamPCP fue su sistema de persistencia y Comando y Control (C2). Utilizaron un contrato inteligente (un “canister”) alojado en la red descentralizada Internet Computer Protocol (ICP) (tdtqy-oyaaa-aaaae-af2dq-cai[.]raw[.]icp0[.]io). Al estar descentralizado en la blockchain, es inmune a las solicitudes de baja (takedowns) tradicionales de la policía o proveedores de hosting. Los equipos infectados seguían contactando a este C2 cada 50 minutos exactos.

El Wiper Geopolítico (kamikaze.sh)

Si el malware detectaba que estaba operando en servidores ubicados en Irán (verificando la zona horaria Asia/Tehran o el idioma fa_IR), no robaba datos. En su lugar, descargaba un script destructivo (kamikaze.sh) que creaba un contenedor privilegiado en Kubernetes y ejecutaba un borrado absoluto del disco duro (rm -rf / --no-preserve-root) seguido de un reinicio forzado, “brickeando” los clústeres enteros.

4. Última Hora: TeamPCP ataca a Telnyx usando Esteganografía en Audio (27 de Marzo 2026)

Lejos de detenerse tras el descubrimiento en LiteLLM, TeamPCP volvió a golpear apenas tres días después. El 27 de marzo, publicaron versiones maliciosas (4.87.1 y 4.87.2) de la librería oficial de telecomunicaciones Telnyx en PyPI.

Esta vez evolucionaron sus tácticas empleando Esteganografía en archivos WAV. El malware no estaba a simple vista; el sistema descargaba un archivo de audio legítimo (hangup.wav) que pasaba todos los filtros de seguridad, pero que escondía en sus ondas de sonido el código ejecutable del virus. Tras ser decodificado, en Linux robaba credenciales, y en Windows soltaba un ejecutable persistente disfrazado de msbuild.exe en la carpeta de inicio.

¿Cómo proteger tus Agentes Autónomos y tu Infraestructura?

La lección de CVE-2026-33634 es clara: la automatización basada en la confianza implícita ha muerto. Para proteger tu entorno debes:

1. Usar Hashes, NO Etiquetas (Tags): Nunca configures tus pipelines (como GitHub Actions) usando etiquetas de versión mutables como @v1 o @v0.69.4. Ancla siempre tus dependencias a hashes criptográficos SHA-256 inmutables.
2. Verificar tus entornos: Si usaste LiteLLM entre las 10:39 y las 16:00 UTC del 24 de marzo de 2026, asume que fuiste comprometido. Borra el paquete, busca el archivo litellm_init.pth y rota absolutamente todos tus secretos y contraseñas. Las versiones seguras de LiteLLM son la <=1.82.6.
3. Implementar Zero Trust en tus Agentes IA: Los agentes autónomos deben operar bajo el principio de privilegio mínimo. Bloquea sus accesos por defecto y exige validación de “humano en el bucle” (Human-in-the-loop) para cualquier acción destructiva o exfiltración masiva.

🎥 ¿Quieres entender visualmente cómo los hackers ejecutaron este asalto paso a paso y qué significa para el futuro de la Inteligencia Artificial? (https://youtu.be/0o3uvlpGnV4).