Ataques a la cadena de suministro a través de Trivy y LiteLLM: cómo proteger la canalización de CI/CD de CVE-2026-33634x

Millones de canalizaciones de desarrollo de software automatizadas dependen de herramientas de seguridad (como Trivy y Checkmarx AST), que están integradas en el proceso de creación. Y fueron estas soluciones de confianza las que recientemente se convirtieron en el punto de entrada para uno de los ataques a la cadena de suministro más grandes y peligrosos de la actualidad. En esta publicación, hablamos sobre cómo auditar los flujos de trabajo automatizados y proteger la infraestructura corporativa en la nube.

Línea de tiempo del ataque y consecuencias conocidas

El 19 de marzo se llevó a cabo con éxito un ataque a la cadena de suministro a través de Trivy, una herramienta de análisis de vulnerabilidades de código abierto ampliamente utilizada en las canalizaciones de CI/CD. Los atacantes, un grupo conocido como TeamPCP, lograron insertar malware en flujos de trabajo oficiales de GitHub Actions e imágenes Docker asociadas con Trivy. Como resultado, cada análisis de las canalizaciones automatizadas activaba malware que robaba claves SSH, tokens de acceso a la nube, carteras de criptomonedas y otros datos valiosos de los sistemas vulnerados. Dada la naturaleza crítica del incidente, se le asignó el identificador CVE-2026-33634 con la puntuación CVSS4B casi máxima de 9,4.

Más tarde ese mismo día, el equipo de Trivy detectó el ataque y eliminó los artefactos maliciosos de los canales de distribución, y así detuvo esta fase del ataque. Sin embargo, los atacantes ya habían obtenido acceso a los entornos de muchos usuarios de Trivy.

El 23 de marzo, se descubrió un incidente similar en otra herramienta de seguridad para aplicaciones: una acción de GitHub Actions para Checkmarx KICS, así como Checkmarx AST. Tres horas después, se eliminó el código malicioso de allí también. TeamPCP también logró poner en riesgo las extensiones de OpenVSX compatibles con Checkmarx: cx-dev-assist 1.7.0 y ast-results. Las declaraciones sobre cuándo se resolvió esta parte del incidente varían.

El 24 de marzo, un proyecto popular que utilizaba el análisis de código de Trivy (la puerta de enlace de IA de LiteLLM, una biblioteca universal para acceder a varios proveedores de LLM) sufrió un ataque. Las versiones 1.82.7 y 1.82.8, cargadas al repositorio de PyPI, se vieron vulneradas. Estas versiones estuvieron disponibles para el público durante unas cinco horas.

Pero el hecho de que el ataque haya durado solo unas horas no es motivo para restarle importancia. Dada la popularidad de los proyectos afectados, el código malicioso podría haberse ejecutado miles de veces, incluso dentro de la infraestructura de empresas muy grandes.

Esto permitió a los atacantes implementar puertas traseras (backdoors) persistentes en clústeres de Kubernetes, así como ejecutar un CanisterWorm autorreplicante en todo el ecosistema npm de JavaScript.

El código de los atacantes tiene capacidades destructivas que eliminan clústeres de Kubernetes y todos sus nodos si detecta la zona horaria de Teherán o el farsi como idioma principal en el sistema vulnerado. En otras regiones, el malware simplemente roba datos con CanisterWorm.

Según los expertos, se considera que más de 20 000 repositorios podrían estar en riesgo. Los atacantes afirman haber robado cientos de gigabytes de datos y más de medio millón de cuentas.

Cómo fue el ataque a Trivy

Para poner en riesgo a Trivy, los atacantes utilizaron credenciales robadas en un incidente anterior. Lo más probable es que el incidente anterior, que ocurrió a fines de febrero, no se haya contenido por completo y los atacantes (el mismo grupo de TeamPCP) regresaron con un nuevo ataque. Los desarrolladores de Trivy, Aqua Security, especulan que debido a que las credenciales se eliminaron de forma gradual después del incidente anterior, los atacantes pudieron generar nuevos tokens de acceso para ellos mismos antes de que los antiguos que habían sido vulnerados fueran revocados.

Por lo tanto, TeamPCP pudo poner en riesgo las acciones de GitHub Actions utilizadas en las canalizaciones de CI/CD. Usando credenciales con privilegios de escritura de etiquetas, los atacantes invalidaron por la fuerza 76 de las 77 etiquetas de versión en aquasecurity/trivy-action y las siete etiquetas en aquasecurity/setup-trivy, y redirigieron las versiones de confianza existentes a commits maliciosos. Esto se asemeja a las tácticas que se vieron en la campaña Shai-Hulud 2.0. Como resultado, los flujos de trabajo a lo largo de la canalización comenzaron a ejecutar el código de los atacantes, mientras que los metadatos de la versión no mostraban cambios evidentes.

Al mismo tiempo, los atacantes publicaron un binario de Trivy infectado (v0.69.4) en los canales de distribución oficiales, incluidos los lanzamientos de GitHub y los registros de contenedores.

LiteLLM en riesgo

El ataque a la popular herramienta de acceso a modelos de lenguaje LiteLLM podría en sí mismo desencadenar una gran ola de ataques en la cadena de proyectos que la utilizan. El ataque tuvo lugar el 24 de marzo de 2026, cuando TeamPCP publicó directamente versiones maliciosas de la biblioteca (1.82.7 y 1.82.8) en PyPI. Entre las 10:39 y las 16:00 (UTC), estos paquetes vulnerados contenían malware que robaba credenciales. Estaba integrado en el archivo proxy_server.py, y la versión 1.82.8 también contenía un archivo litellm_init malicioso. Los datos robados se exfiltraron al servidor models.litellm[.]cloud.

Los clientes que usaban LiteLLM Cloud o la imagen Docker oficial de LiteLLM Proxy no se vieron afectados debido al bloqueo estricto de la versión, mientras que los desarrolladores y los proyectos posteriores que instalaron versiones no ancladas a través de pip durante la ventana de tiempo especificada se vieron vulnerados.

En un plazo de tres horas, los paquetes maliciosos se eliminaron del repositorio de PyPI y el equipo de LiteLLM suspendió los nuevos lanzamientos, rotó las credenciales y emprendió un proceso de respuesta a incidentes externo. Se recomienda a los equipos que usan LiteLLM en sus proyectos que comprueben de inmediato el indicador de vulneración litellm_init.pth y roten de forma rutinaria todos los secretos que puedan haber sido vulnerados.

Características del malware TeamPCP Cloud Stealer

Los atacantes añadieron nueva lógica a GitHub Actions y al ejecutable de Trivy al tiempo que preservaron la funcionalidad original. Los resultados del análisis de vulnerabilidades a través de Trivy parecían normales, pero al mismo tiempo se buscaban y extraían datos valiosos. El código malicioso hacía lo siguiente:

• realizar un reconocimiento (recopilar datos de red y variables de entorno);
• buscar tokens y credenciales para acceder a los entornos de nube de AWS y GCP;
• analizar la memoria (/proc/*/mem) para extraer los secretos almacenados en la memoria de los procesos Runner.Worker y Runner.Listener;
• extraer secretos de Kubernetes (/run/secrets/kubernetes.io/serviceaccount);
• recopilar datos para conectarse a servidores de bases de datos (MySQL, PostgreSQL, MongoDB, Redis, Vault);
• recopilar cualquier otra clave de API y secretos de archivos de entorno y archivos de configuración de CI/CD (.env, .json, .yml);
• buscar webhooks para canales de Slack y Discord;
• buscar datos relacionados con las carteras de criptomonedas (variables relacionadas con la plataforma de blockchain Solana, así como datos de rpcuser y rpcpassword).

Los datos recopilados se cifraron y se cargaron en un servidor con un nombre similar al de los desarrolladores de Trivy (scan.aquasecurtiy[.]org). Como mecanismo de respaldo, los atacantes proporcionaron un método para cargar datos a un repositorio llamado docs-tpcp.

El ataque a CheckMarx y LiteLLM utilizó una táctica similar con otros dominios de typosquatting: models.litellm[.]cloud y checkmarx[.]zone.

Puedes encontrar un análisis técnico detallado del malware, junto con los indicadores de vulneración, en el artículo de nuestro experto en el blog de Securelist.

Estrategias de respuesta y defensa para CVE-2026-33634

Ya no son suficientes las comprobaciones basadas en firmas existentes y el análisis de dependencias en los registros públicos, ya que el código malicioso se insertó directamente en acciones firmadas de confianza y evitó que lo detecten hasta que se aplicó la supervisión de comportamiento. Las canalizaciones de CI/CD se han convertido en el “nuevo perímetro” de seguridad.

Acciones inmediatas. Asegúrate de que todos los flujos de trabajo utilicen versiones seguras (Trivy binary 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6).

Los administradores de la canalización de CI/CD y los equipos de seguridad deben revisar inmediatamente sus dependencias con las soluciones Checkmarx (kics-github-action, ast-github-action) y Trivy (setup-trivy y trivy-action). Si los flujos de trabajo hicieron referencia a una etiqueta de versión en lugar de a un hash SHA específico, revisa detenidamente los registros de ejecución de tu flujo de trabajo durante el ataque activo a la cadena de suministro.

También debes verificar los registros de tu red para ver si hay tráfico hacia los dominios scan.aquasecurtiy[.]org, checkmarx[.]zone y models.litellm[.]cloud. La presencia de este tráfico indica que los datos confidenciales se han exfiltrado con éxito.

Si ha aparecido un repositorio llamado docs-tpcp en el GitHub de la organización, esto también puede indicar que ha habido una filtración de datos exitosa.

Revisa los hosts y los clústeres en busca de señales de vulneración: la presencia de archivos ~/.config/sysmon/sysmon.py o pods sospechosos en Kubernetes, etc.

Borra la caché y realiza un inventario de los módulos de PyPI, comprueba si hay maliciosos y vuelve a versiones anteriores limpias.

En cualquier caso, deberías realizar una búsqueda de amenazas proactiva, asumiendo que el ataque a los sistemas ha sido exitoso y que los atacantes han avanzado rápidamente dentro de los sistemas afectados.

Se recomienda restaurar los entornos afectados a partir de copias de seguridad verificadas.

Fijación de dependencias y administración de secretos. Asegúrate de que las versiones de dependencia exactas estén fijadas mediante hashes criptográficos en todas las canalizaciones y Dockerfiles. Recomendamos hacer la transición de tokens de larga duración a credenciales de corta duración usando una herramienta de administrador de secretos e implementar integraciones de OIDC donde sea compatible. Minimiza la inserción de secretos en el entorno de ejecución (hazlo solo cuando sea absolutamente necesario). Asegúrate de que los secretos no se almacenen en un disco o en archivos temporales, y que no se reutilicen en diferentes procesos.

Rota todas las credenciales que puedan haber sido vulneradas: claves de API, variables de entorno, claves SSH, tokens de cuentas de servicio de Kubernetes y otros secretos.

Otras medidas de seguridad. Permite solo acciones de GitHub Actions de una lista aprobada por la organización; bloquea los procesos nuevos y no verificados. Configura GITHUB_TOKEN y otras claves de acceso de acuerdo con el principio de privilegio mínimo. No concedas permisos de escritura a menos que sea absolutamente necesario.

Para mejorar la seguridad de GitHub Actions, hay varias herramientas de código abierto disponibles:

• zizmor: una herramienta para el análisis estático y la detección de errores de configuración en GitHub Actions.
• gato y Gato-X: dos versiones de una herramienta que ayuda a identificar canalizaciones con estructuras vulnerables.
• allstar: una aplicación de GitHub, desarrollada por OpenSSF, para configurar y hacer cumplir las directivas de seguridad en las organizaciones y los repositorios de GitHub.

Si deseas obtener más información sobre los ataques a la cadena de suministro, te invitamos a consultar nuestro informe analítico Supply chain reaction: securing the global digital ecosystem in an age of interdependence. Se basa en los conocimientos de expertos técnicos y revela con qué frecuencia las organizaciones se enfrentan a riesgos de la cadena de suministro y de las relaciones de confianza, dónde persisten las brechas de protección y qué estrategias emplear para mejorar la resiliencia frente a este tipo de amenazas.