Millones de canalizaciones de desarrollo de software automatizadas dependen de herramientas de seguridad (como Trivy y Checkmarx AST), que est\u00e1n integradas en el proceso de creaci\u00f3n. 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<\/u> m\u00e1s grandes y peligrosos de la actualidad. En esta publicaci\u00f3n, hablamos sobre c\u00f3mo auditar los flujos de trabajo automatizados y proteger la infraestructura corporativa en la nube.<\/p>\nL\u00ednea de tiempo del ataque y consecuencias conocidas<\/h2>\n
El 19 de marzo se llev\u00f3 a cabo con \u00e9xito un ataque a la cadena de suministro a trav\u00e9s de Trivy, una herramienta de an\u00e1lisis de vulnerabilidades de c\u00f3digo 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\u00e1genes Docker asociadas con Trivy. Como resultado, cada an\u00e1lisis 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\u00edtica del incidente, se le asign\u00f3 el identificador CVE-2026-33634<\/a> con la puntuaci\u00f3n CVSS4B casi m\u00e1xima de 9,4.<\/p>\n M\u00e1s tarde ese mismo d\u00eda, el equipo de Trivy detect\u00f3 el ataque y elimin\u00f3 los artefactos maliciosos de los canales de distribuci\u00f3n, y as\u00ed detuvo esta fase del ataque. Sin embargo, los atacantes ya hab\u00edan obtenido acceso a los entornos de muchos usuarios de Trivy.<\/p>\n El 23 de marzo, se descubri\u00f3 un incidente similar<\/a> en otra herramienta de seguridad para aplicaciones: una acci\u00f3n de GitHub Actions para Checkmarx KICS, as\u00ed como Checkmarx AST. Tres horas despu\u00e9s, se elimin\u00f3 el c\u00f3digo malicioso de all\u00ed tambi\u00e9n. TeamPCP tambi\u00e9n logr\u00f3 poner en riesgo las extensiones de OpenVSX<\/a> compatibles con Checkmarx: cx-dev-assist<\/em> 1.7.0 y ast-results<\/em>. Las declaraciones sobre cu\u00e1ndo se resolvi\u00f3 esta parte del incidente var\u00edan.<\/p>\n El 24 de marzo, un proyecto popular que utilizaba el an\u00e1lisis de c\u00f3digo de Trivy (la puerta de enlace de IA de LiteLLM, una biblioteca universal para acceder a varios proveedores de LLM) sufri\u00f3 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\u00fablico durante unas cinco horas.<\/p>\n 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\u00f3digo malicioso podr\u00eda haberse ejecutado miles de veces, incluso dentro de la infraestructura de empresas muy grandes.<\/p>\n Esto permiti\u00f3 a los atacantes implementar puertas traseras (backdoors) persistentes en cl\u00fasteres de Kubernetes, as\u00ed como ejecutar un CanisterWorm<\/a> autorreplicante en todo el ecosistema npm de JavaScript.<\/p>\n El c\u00f3digo de los atacantes tiene capacidades destructivas<\/a> que eliminan cl\u00fasteres de Kubernetes y todos sus nodos si detecta la zona horaria de Teher\u00e1n o el farsi como idioma principal en el sistema vulnerado. En otras regiones, el malware simplemente roba datos con CanisterWorm.<\/p>\n Seg\u00fan los expertos, se considera que m\u00e1s de 20\u00a0000 repositorios podr\u00edan estar en riesgo. Los atacantes afirman haber robado cientos de gigabytes de datos y m\u00e1s de medio mill\u00f3n de cuentas<\/a>.<\/p>\n Para poner en riesgo a Trivy, los atacantes utilizaron credenciales robadas en un incidente anterior. Lo m\u00e1s probable es que el incidente anterior<\/a>, que ocurri\u00f3 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<\/a> que debido a que las credenciales se eliminaron de forma gradual despu\u00e9s del incidente anterior, los atacantes pudieron generar nuevos tokens de acceso para ellos mismos antes de que los antiguos que hab\u00edan sido vulnerados fueran revocados.<\/p>\n 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\u00f3n 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\u00e1cticas que se vieron en la campa\u00f1a Shai-Hulud 2.0<\/a>. Como resultado, los flujos de trabajo a lo largo de la canalizaci\u00f3n comenzaron a ejecutar el c\u00f3digo de los atacantes, mientras que los metadatos de la versi\u00f3n no mostraban cambios evidentes.<\/p>\n Al mismo tiempo, los atacantes publicaron un binario de Trivy infectado (v0.69.4) en los canales de distribuci\u00f3n oficiales, incluidos los lanzamientos de GitHub y los registros de contenedores.<\/p>\n El ataque a la popular herramienta de acceso a modelos de lenguaje LiteLLM podr\u00eda en s\u00ed 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\u00f3 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\u00edan malware que robaba credenciales. Estaba integrado en el archivo proxy_server.py<\/em>, y la versi\u00f3n 1.82.8 tambi\u00e9n conten\u00eda un archivo litellm_init<\/em> malicioso. Los datos robados se exfiltraron al servidor models.litellm[.]cloud<\/em>.<\/p>\n 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\u00f3n, mientras que los desarrolladores y los proyectos posteriores que instalaron versiones no ancladas a trav\u00e9s de pip durante la ventana de tiempo especificada se vieron vulnerados.<\/p>\n En un plazo de tres horas, los paquetes maliciosos se eliminaron del repositorio de PyPI y el equipo de LiteLLM suspendi\u00f3 los nuevos lanzamientos, rot\u00f3 las credenciales y emprendi\u00f3 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\u00f3n litellm_init.pth<\/em> y roten de forma rutinaria todos los secretos que puedan haber sido vulnerados.<\/p>\n Los atacantes a\u00f1adieron nueva l\u00f3gica a GitHub Actions y al ejecutable de Trivy al tiempo que preservaron la funcionalidad original. Los resultados del an\u00e1lisis de vulnerabilidades a trav\u00e9s de Trivy parec\u00edan normales, pero al mismo tiempo se buscaban y extra\u00edan datos valiosos. El c\u00f3digo malicioso hac\u00eda lo siguiente:<\/p>\n Los datos recopilados se cifraron y se cargaron en un servidor con un nombre similar al de los desarrolladores de Trivy (scan.aquasecurtiy[.]org<\/em>). Como mecanismo de respaldo, los atacantes proporcionaron un m\u00e9todo para cargar datos a un repositorio llamado docs-tpcp<\/em>.<\/p>\n El ataque a CheckMarx y LiteLLM utiliz\u00f3 una t\u00e1ctica similar con otros dominios de typosquatting: models.litellm[.]cloud<\/em> y checkmarx[.]zone<\/em>.<\/p>\n Puedes encontrar un an\u00e1lisis t\u00e9cnico detallado del malware, junto con los indicadores de vulneraci\u00f3n, en el art\u00edculo de nuestro experto en el blog de Securelist<\/a>.<\/p>\n Ya no son suficientes las comprobaciones basadas en firmas existentes y el an\u00e1lisis de dependencias en los registros p\u00fablicos, ya que el c\u00f3digo malicioso se insert\u00f3 directamente en acciones firmadas de confianza y evit\u00f3 que lo detecten hasta que se aplic\u00f3 la supervisi\u00f3n de comportamiento. Las canalizaciones de CI\/CD se han convertido en el \u201cnuevo per\u00edmetro\u201d de seguridad.<\/p>\n Acciones inmediatas. <\/strong>Aseg\u00farate 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).<\/p>\n Los administradores de la canalizaci\u00f3n 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\u00f3n en lugar de a un hash SHA espec\u00edfico, revisa detenidamente los registros de ejecuci\u00f3n de tu flujo de trabajo durante el ataque activo a la cadena de suministro.<\/p>\n Tambi\u00e9n debes verificar los registros de tu red para ver si hay tr\u00e1fico hacia los dominios scan.aquasecurtiy[.]org<\/em>, checkmarx[.]zone<\/em> y models.litellm[.]cloud<\/em>. La presencia de este tr\u00e1fico indica que los datos confidenciales se han exfiltrado con \u00e9xito.<\/p>\n Si ha aparecido un repositorio llamado docs-tpcp en el GitHub de la organizaci\u00f3n, esto tambi\u00e9n puede indicar que ha habido una filtraci\u00f3n de datos exitosa.<\/p>\n Revisa los hosts y los cl\u00fasteres en busca de se\u00f1ales de vulneraci\u00f3n: la presencia de archivos ~\/.config\/sysmon\/sysmon.py o pods sospechosos en Kubernetes, etc.<\/p>\n Borra la cach\u00e9 y realiza un inventario de los m\u00f3dulos de PyPI, comprueba si hay maliciosos y vuelve a versiones anteriores limpias.<\/p>\nC\u00f3mo fue el ataque a Trivy<\/h2>\n
LiteLLM en riesgo<\/h2>\n
Caracter\u00edsticas del malware TeamPCP Cloud Stealer<\/h2>\n
\n
Estrategias de respuesta y defensa para CVE-2026-33634<\/h2>\n