Qué pasó dentro de la cadena de compilación de LiteLLM en marzo

La intrusión no comenzó en LiteLLM. TeamPCP comprometió primero el escáner de seguridad de código abierto Trivy explotando un token de automatización filtrado, lo que le dio una ventana de unos 20 días dentro del propio repositorio de Trivy antes de que nadie lo notara. Durante esa ventana, el grupo forzó la subida de código malicioso a las etiquetas de versión de Trivy, los marcadores específicos de lanzamiento a los que apuntan los proyectos posteriores cuando obtienen una dependencia.

La pipeline de integración continua de LiteLLM instalaba Trivy sin fijarlo a una versión verificada y estable, por lo que incorporó automáticamente la versión envenenada la siguiente vez que se ejecutó la pipeline. Esa única dependencia sin fijar fue toda la puerta que TeamPCP necesitaba: el código malicioso viajó hasta el propio proceso de compilación de LiteLLM y de ahí a dos paquetes publicados, las versiones 1.82.7 y 1.82.8 de LiteLLM, subidas al Python Package Index.

La defensa en la que todos confían, y cómo fue evadida

La mayoría de los desarrolladores que temen a los paquetes maliciosos de PyPI confían en la bandera --ignore-scripts, que impide que los scripts de instalación de un paquete ejecuten código arbitrario. La carga útil de TeamPCP no necesitaba un script de instalación. Viajaba dentro de un archivo .pth, un archivo de configuración de rutas de Python que el propio intérprete ejecuta automáticamente al iniciarse, en cada ejecución, sin importar cómo se instalara el paquete. Ese detalle de diseño es el que todos los titulares sobre esta brecha omitieron, y es el que más importa a cualquier equipo de ingeniería que creyera que --ignore-scripts los protegía de esta clase exacta de ataque.

Una vez en ejecución, la carga útil recolectaba claves SSH, credenciales en la nube de AWS, Google Cloud y Azure, tokens de Kubernetes, el contenido de archivos .env y claves de API de proveedores de IA de cualquier máquina que hubiera instalado el paquete envenenado. Los datos robados se cifraban con AES-256 y se enviaban a un dominio de typosquatting diseñado para parecer un recurso legítimo de LiteLLM o Trivy, o se subían directamente a repositorios en la propia cuenta de GitHub de la víctima - un detalle que permitía que la operación se mezclara con la actividad normal de un desarrollador en lugar de disparar una alerta evidente de tráfico saliente.

2.500 empresas, ocho nombradas en Europa y una brecha de cinco meses

CloudSEK publicó su investigación el 11 de agosto de 2026, cinco meses después del compromiso de marzo, identificando a más de 2.500 organizaciones y aproximadamente 434.000 pipelines de CI/CD como potencialmente expuestas - lo que la firma califica como la mayor brecha de cadena de suministro de IA descubierta hasta ahora en 2026. Entre las coincidencias de alta confianza que nombra CloudSEK están Siemens AG, Siemens Energy, Deutsche Bahn AG, Orange S.A., Vodafone Group Plc, London Stock Exchange Group, la energética finlandesa Fortum Oyj y la reaseguradora Munich Re, abarcando manufactura, telecomunicaciones, ferrocarriles, finanzas y seguros en varias jurisdicciones europeas.

CloudSEK es explícito al señalar que la aparición de una empresa en su conjunto de datos no es prueba automática de una brecha exitosa - el hallazgo significa que credenciales, dominios, repositorios o infraestructura vinculados a esa organización surgieron en los datos de exposición recolectados, y cada organización necesita su propia investigación para confirmar qué, si acaso, se sustrajo o se usó indebidamente. Lo que no está en duda es la brecha de cinco meses entre la intrusión de marzo y la divulgación de agosto, una ventana en la que cualquiera de las organizaciones nombradas pudo haber operado con credenciales comprometidas sin ninguna advertencia pública de que el compromiso había ocurrido.

Qué significa esto para quien opera infraestructura de IA

La alerta FLASH del FBI de julio de 2026 añade un detalle incómodo a la cronología: las credenciales recolectadas en marzo se siguen considerando activas y utilizables meses después, y la agencia espera que TeamPCP o actores afiliados las utilicen en futuras intrusiones no relacionadas en lugar de dejarlas caducar. Para cualquier organización que ejecutó las versiones 1.82.7 o 1.82.8 de LiteLLM en producción o CI durante marzo de 2026, la respuesta correcta no es esperar una confirmación individual de CloudSEK o LiteLLM - es tratar toda credencial que haya tocado esa cadena de compilación como comprometida y rotarla ahora, cinco meses tarde o no.

La lección estructural va más allá de LiteLLM. Cualquier organización que permita que su pipeline de CI incorpore una dependencia de herramientas de seguridad, como un escáner, sin fijarla a una versión verificada tiene la misma puerta que utilizó TeamPCP aquí, y --ignore-scripts no es la salvaguarda que la mayoría de los equipos cree que es frente a una carga útil entregada mediante un archivo .pth. Los responsables de seguridad europeos que operan infraestructura de IA construida sobre la misma cadena de suministro de código abierto deberían ver esto menos como una historia de LiteLLM y más como un adelanto de cómo se entregará probablemente el próximo compromiso de herramientas de IA.

Leer a continuación: 141.006 pruebas, tres intrusiones reales  |  Micron: 2027 será más ajustado que 2026