Más de 2.500 organizaciones y unas 430.000 canalizaciones de CI/CD habrían sido impactadas por un ataque a la cadena de suministro relacionado con LiteLLM, según un informe de CloudSEK. El incidente no se limitó a un fallo puntual: la forma en que se construyó y publicó el software permitió que una credencial filtrada se expandiera por el ecosistema.
El caso llama la atención porque no partió de LiteLLM como objetivo directo. En su lugar, el compromiso se propagó a través del proceso automatizado de build y liberación, conectando herramientas y artefactos en una cadena que amplificó el alcance.
Qué ocurrió en el ataque cadena de suministro
La divulgación del incidente sobre LiteLLM se produjo poco después de otro evento importante: el ataque a la cadena de suministro que afectó al escáner de vulnerabilidades Trivy de código abierto. Según CloudSEK, el actor detrás de múltiples compromisos de software de código abierto (OSS) no habría apuntado específicamente a LiteLLM.
El problema apareció cuando una versión maliciosa de Trivy llegó a la cadena de construcción de LiteLLM. Al instalarse automáticamente dentro del pipeline, esa versión alterada se integró en el proceso de empaquetado y publicación.
De Trivy a la liberación de LiteLLM
CloudSEK describe una secuencia encadenada: primero Trivy, después el sistema de build de LiteLLM y, finalmente, la liberación. En esa estructura, un solo elemento comprometido puede convertirse en exposición amplia para quienes usan el resultado final.
Además, los sistemas de compilación automatizados “comprimen el tiempo”. Cuando un artefacto malicioso entra en un registro, puede replicarse con rapidez en tareas programadas, resolvers de dependencias, entornos de ejecución efímeros, equipos de desarrollo y capas en caché. Por ello, la ventana de análisis forense y la rotación de credenciales no termina cuando se retira el paquete.
Versiones afectadas y cómo se propagó la carga
Según la información reportada, se publicaron en PyPI al menos dos versiones específicas de LiteLLM: 1.82.7 y 1.82.8. Esas cargas llegaron a manos de los atacantes, quienes obtuvieron acceso a la información que el paquete tocaba durante su uso.
Lo relevante es que el código modificado contenía una carga maliciosa que se ejecutaba en cada invocación de Python, sin requerir una importación explícita. En la práctica, el payload se activaba en cualquier sistema donde el paquete estuviera instalado.
Por qué el impacto fue tan amplio (aunque el tiempo fuera corto)
CloudSEK señala que los paquetes afectados estuvieron activos durante aproximadamente 40 minutos. Aun así, ese intervalo resultó suficiente para que el código malicioso se extendiera.
El efecto final se tradujo en la exposición de alrededor de 434.000 canalizaciones de CI/CD y el impacto a más de 2.500 organizaciones. Aquí conviene entender un matiz importante: los números se basan en la reconstrucción del alcance, no en pruebas concluyentes de que todas las entidades enumeradas sufrieran un compromiso exitoso ni de que se robaran todas las credenciales.
En otras palabras, el hecho de haber estado “cerca” puede no significar que el atacante lograra tomar el control en todos los casos. Sin embargo, la probabilidad de exposición existe y debe tratarse como un riesgo real.
Organizaciones mencionadas en el listado
En el informe se citan nombres de diversas empresas, entre ellas: Nvidia, AWS, Samsung, Salesforce, Cisco, ServiceNow, Accenture Federal Services, Siemens, Regeneron Pharmaceuticals, London Stock Exchange Group, FedEx, Volkswagen, Orange, HP, Deutsche Bahn, NGINX y Zscaler, entre otras.
CloudSEK remarca que cualquier verificación de compromiso debe realizarse de manera independiente por cada organización.
Qué secretos pudieron verse comprometidos
El ataque cadena de suministro no solo afectó a un paquete: también abrió la puerta a la comprometión de información sensible. De acuerdo con CloudSEK, los datos expuestos podrían incluir credenciales y llaves de diversos componentes.
Entre los tipos de secretos mencionados se encuentran:
- Credenciales de publicación de paquetes
- Claves de nube
- Claves SSH
- Tokens
- Variables de entorno
- Datos en tiempo de ejecución
- Claves de proveedores de IA
Si el atacante lograba obtener esos elementos, podía usarlos para múltiples objetivos: tomar control de cuentas, robar información, introducir cambios maliciosos en commits, persistir dentro de entornos, moverse lateralmente, interrumpir servicios y desplegar malware.
Qué hacer: validar, rotar y revisar el alcance
CloudSEK recomienda asumir que cualquier secreto accesible para la biblioteca pudo estar comprometido. La exposición no se limita a lo que “se guarda” en disco: también podría residir en memoria del proceso, haberse inyectado en el job, quedar almacenado en el sistema o incluso recuperarse mediante un servicio de metadata de instancia.
En términos prácticos, el plan de respuesta debe contemplar tres líneas de acción:
- Validar los posibles secretos expuestos, para estimar qué se filtró realmente.
- Rotar credenciales, incluidas cuentas de servicio y sesiones relacionadas, no solo los elementos más obvios.
- Revisar registros para determinar el alcance y el periodo de tiempo de la exposición.
También es recomendable revisar dependencias y procesos de build para entender cómo la cadena automatizada permitió que el artefacto comprometido llegara a los entornos de desarrollo y despliegue.
Lecciones para el futuro: por qué la IA es un objetivo de alto valor
CloudSEK advierte que el siguiente gran ataque a la cadena de suministro podría apuntar a la infraestructura de IA. Su argumento es que estos sistemas se han convertido en “puntos de unión” entre datos, identidad, cómputo y acciones autónomas.
El incidente, según CloudSEK, deja una enseñanza clara: no fue únicamente una brecha en la cadena de suministro de software que involucró un producto de IA, sino una demostración de que comprometer un punto de control puede revelar identidades y sistemas alrededor de ese punto.
Por eso, las futuras campañas podrían concentrarse en la capa de IA, precisamente porque está conectada con el resto del entorno.
Conclusión
El ataque cadena de suministro asociado a LiteLLM expone un problema estructural: cuando la construcción y la publicación se automatizan sin controles adicionales, un componente comprometido puede “viajar” a lo largo de toda la cadena de herramientas. Aunque los paquetes afectados estuvieron activos durante un periodo breve, la replicación en procesos de CI/CD hizo que el impacto alcanzara a cientos de miles de canalizaciones.
La recomendación para organizaciones es clara: tratar los secretos relacionados con el uso de la biblioteca como potencialmente comprometidos, rotar credenciales con prioridad y revisar logs para reconstruir qué ocurrió y cuándo. Con ese enfoque, es posible reducir el riesgo y preparar mejor el entorno ante los próximos intentos contra la infraestructura de IA.
Fuente: https://www.securityweek.com/over-2500-organizations-impacted-by-litellm-supply-chain-attack/
