El ataque a la cadena de suministro de LiteLLM es una llamada de atención para todo equipo que use herramientas de IA
Qué ocurrió
El 24 de marzo de 2026, alguien publicó versiones maliciosas de LiteLLM (1.82.7 y 1.82.8) directamente en PyPI, saltándose el proceso de publicación habitual del proyecto. Los paquetes comprometidos contenían un ladrón de credenciales que recopilaba claves SSH, credenciales de proveedores en la nube, configuraciones de Kubernetes, claves de API y más, para luego exfiltrarlas a un dominio que parecía pertenecer a LiteLLM, pero no era así.
Los paquetes maliciosos estuvieron activos durante aproximadamente 40 minutos antes de que PyPI los pusiera en cuarentena. No parece mucho. Pero LiteLLM se instala unas 15-20 millones de veces por semana, lo que equivale a unos 1.700 instalaciones por minuto. Durante esa ventana de tiempo, se produjeron más de 119.000 descargas. Se estima que entre el 40 y el 50% de ellas fueron instalaciones sin versión fijada que descargaban la última versión de forma automática.
El ataque tuvo su origen en una dependencia comprometida de Trivy dentro del flujo de trabajo de análisis de seguridad CI/CD de LiteLLM. Se cree que un grupo llamado TeamPCP es el responsable, y hay indicios de que se han asociado con el grupo de extorsión Lapsus$ para monetizar los datos robados. En la RSA Conference de la semana pasada, investigadores de respuesta a incidentes confirmaron que tenían constancia de más de 1.000 entornos SaaS afectados, y los analistas de amenazas estiman que se exfiltraron datos de 500.000 máquinas.
Esta semana, la primera víctima indirecta hizo pública su situación. Una startup de contratación con IA confirmó ser «una de las miles de empresas» afectadas, y el grupo Lapsus$ está ahora subastando lo que afirman son 4 TB de datos robados, incluyendo código fuente, credenciales y configuraciones de VPN.
Por qué este caso importa más que el CVE habitual
Vemos avisos sobre cadenas de suministro con suficiente frecuencia como para que empiecen a confundirse entre sí. Este es diferente por varias razones.
En primer lugar, el vector de ataque. El compromiso no comenzó en LiteLLM. Comenzó en Trivy, un escáner de vulnerabilidades de código abierto que muchos equipos ejecutan dentro de sus pipelines de CI/CD. Piénselo un momento: la herramienta que usted usa para detectar vulnerabilidades fue el punto de entrada. Sus propias herramientas de seguridad comprometieron su seguridad. No es solo irónico, es un recordatorio de que los pipelines de CI/CD son un objetivo de alto valor y que cada herramienta que se ejecuta en ellos necesita el mismo nivel de escrutinio que usted aplicaría a las dependencias en producción.
En segundo lugar, la posición de LiteLLM en el stack. Es una interfaz unificada para llamar a LLMs de múltiples proveedores. Esto significa que normalmente tiene acceso a las claves de API de cada proveedor de IA que usted utilice, además de las variables de entorno y credenciales de nube que existan en el mismo contexto. Comprometer un paquete en esa posición le da a los atacantes un atajo hacia todo.
En tercer lugar, el radio de impacto indirecto. LiteLLM no solo se instala de forma directa. Es una dependencia transitiva que incluyen frameworks de agentes de IA, servidores MCP y herramientas de orquestación de LLMs. Equipos que nunca han oído hablar de LiteLLM podrían haberlo estado ejecutando en sus trabajos de CI.
Lo que seguimos viendo en nuestro propio trabajo
Durante los compromisos de pruebas de penetración para estudios de videojuegos, una de las primeras cosas que analizamos es el pipeline de CI/CD. Sistemáticamente es el objetivo más vulnerable. Los equipos invierten mucho en firewalls, WAFs y monitorización en tiempo de ejecución, pero el pipeline de compilación a menudo funciona con permisos demasiado amplios, descarga dependencias sin fijar versiones y registra secretos de formas que harían que usted se estremeciera.
Hemos visto patrones similares al desarrollar aplicaciones nativas en la nube para clientes empresariales con requisitos estrictos de cumplimiento normativo. Los entornos regulatorios suizos, por ejemplo, exigen demostrar control sobre la cadena de suministro de software. No es un simple ejercicio de marcar casillas. Significa saber exactamente qué versión de cada dependencia está ejecutando, cuándo fue publicada y qué sumas de verificación corresponden. Los equipos que ya tenían esta disciplina establecida fueron los menos expuestos a este ataque.
En nuestros proyectos nativos de iOS y Android, históricamente hemos estado algo más aislados de este tipo de situaciones, porque los ecosistemas de Apple y Google cuentan con herramientas de compilación más centralizadas. Pero el panorama está cambiando. Cada vez más equipos de móvil integran herramientas de generación de código con IA y funcionalidades basadas en LLMs en sus aplicaciones, lo que significa que las herramientas basadas en Python se están introduciendo en pipelines de compilación que nunca las habían utilizado. Si ejecuta algún preprocesamiento de IA/ML como parte de su compilación móvil, revise su árbol de dependencias.
Qué debe hacer realmente
A continuación, se presentan pasos concretos. Algunos puede llevarlos a cabo hoy mismo.
Fije sus dependencias. No solo en requirements.txt, sino en todos lados: Dockerfiles, configuración de CI, GitHub Actions. Use hash-pinning donde su gestor de paquetes lo permita. El hecho de que entre el 40 y el 50% de las instalaciones de LiteLLM descargaran la última versión en cada ejecución es la causa raíz de por qué una ventana de 40 minutos afectó a tantos entornos.
Compruebe si estuvo expuesto. Si instaló o actualizó LiteLLM mediante pip el 24 de marzo entre las 10:39 y las 16:00 UTC, verifique si tiene las versiones 1.82.7 o 1.82.8. Ejecute pip show litellm en cada entorno. Busque ~/.config/sysmon/sysmon.py y pods sospechosos en Kubernetes que coincidan con node-setup-*. LiteLLM y varias empresas de seguridad han publicado scripts de análisis. Úselos.
Rote credenciales de forma agresiva. Si encuentra cualquier indicio de compromiso, asuma que todas las credenciales de esa máquina están quemadas: claves SSH, tokens de nube, contraseñas de bases de datos, claves de API en archivos .env. Eliminar el paquete no es suficiente, porque el malware fue diseñado para establecer persistencia y puede que ya haya desplegado cargas adicionales.
Use períodos de espera para dependencias. PyPI está incorporando «períodos de espera relativos para dependencias» en pip v26.1 (previsto para este mes), lo que le permite configurar pip para que solo instale paquetes que hayan sido publicados durante un período mínimo de tiempo. Esto no le protegerá de todo, pero habría evitado la instalación automática de un paquete que llevaba activo 40 minutos. Ya puede establecer períodos de espera absolutos en pip v26.0 con el flag --uploaded-prior-to.
Audite los permisos de sus herramientas de CI/CD. Su escáner de vulnerabilidades, su linter, su ejecutor de pruebas, todos funcionan con los permisos que tenga su pipeline. Si su pipeline puede publicar en producción, también puede hacerlo un escáner comprometido. Aplique el principio de mínimo privilegio a cada paso.
La incómoda verdad sobre las herramientas de IA y las cadenas de suministro
Esto es lo que me sigue inquietando de este caso. El stack de desarrollo de IA es joven, evoluciona rápidamente y está sostenido por un número relativamente pequeño de paquetes de código abierto de los que todos dependen. LiteLLM, LangChain, varios frameworks de agentes. Estos proyectos avanzan rápido, publican a menudo y son mantenidos por equipos pequeños. No es una crítica. Es simplemente la realidad en la que nos encontramos.
El Informe sobre el Estado de la Modernización de DevOps 2026 encontró que casi una cuarta parte de los despliegues requieren corrección, con tiempos de corrección que promedian más de 7,5 horas. Añada código generado por IA y dependencias gestionadas por IA a esa mezcla, y obtendrá una cadena de suministro que se expande más rápido de lo que la mayoría de los equipos puede auditar.
A partir de nuestro trabajo con PHP y Docker para clientes empresariales, sabemos que la disciplina en la cadena de suministro es aburrida. No tiene glamour. Nadie quiere invertir un sprint en ajustar los pins de dependencias y revisar los permisos de CI. Pero los equipos que lo hacen son los que duermen tranquilos durante incidentes como este, en lugar de apresurarse a rotar cada credencial que poseen.
Si algo de esto le resulta incómodamente familiar, o si no está seguro de si su pipeline de CI/CD sobreviviría a este tipo de ataque, hablemos. Realizamos revisiones de seguridad que cubren específicamente los pipelines de compilación y la gestión de dependencias, no solo el perímetro de producción, y aportamos la experiencia en desarrollo para entender qué es realmente práctico implementar para su equipo.