El 24 de marzo de 2026, entre las 10:39 y las 16:00 UTC, dos versiones de LiteLLM estuvieron disponibles en PyPI conteniendo malware. El paquete descargado 3,4 millones de veces al día —la capa de abstracción que conecta apps con OpenAI, Anthropic y Google— sirvió durante horas como vector de robo masivo de credenciales. Quien lo instaló sin anclar versión puede haber perdido sus claves SSH, API keys de IA, tokens de Kubernetes, credenciales de AWS, GCP y Azure.
La parte técnica ya fue cubierta. Lo que merece análisis más profundo es lo que el incidente revela sobre un problema de fondo: la infraestructura open source que sostiene el auge de la IA no está protegida de forma proporcional a la confianza que le hemos depositado.
¿Por qué LiteLLM era un blanco tan valioso?
LiteLLM ocupa una posición única en el stack de IA: se sienta entre tu aplicación y todos los proveedores de modelos. No es una librería de utilidades genérica. Tiene acceso directo a tus API keys de OpenAI, a los tokens de autenticación de tu empresa, a las variables de entorno de tus entornos de producción. Comprometer ese paquete es como comprometer el llavero del portero del edificio: das con todo de golpe.
Aprende IA con nosotros
Únete gratis a mi comunidad en Skool, donde compartimos noticias, tutoriales y recursos para seguir aprendiendo juntos.
👥 Únete gratis 🚀Por eso el grupo TeamPCP no lo eligió al azar. Antes de llegar a LiteLLM, comprometió Trivy —el escáner de seguridad que el propio proyecto usaba en su CI/CD— y Checkmarx. Fue un ataque en cadena: primero contaminan las herramientas de defensa, luego usan esas credenciales robadas para publicar directamente en PyPI saltando los flujos oficiales. El payload resultante no era amateur: tres capas cifradas, persistencia como servicio del sistema, y un truco para detectar cuando lo analizaba un sandbox (devolver un video de YouTube en lugar del payload).
El resultado práctico: cualquier desarrollador que ese día hiciera pip install litellm sin anclar versión entregó sus secretos. Cualquier pipeline de CI/CD que hiciera lo mismo, también. Y cualquier framework de agentes de IA que dependa de LiteLLM como transitive dependency —hay varios— también.
El problema más grave: las certificaciones que no certifican nada
LiteLLM contaba con certificaciones SOC 2 e ISO 27001. Para muchos equipos de seguridad corporativa, esas badges son la señal verde para integrar una dependencia externa en producción. El problema es que esas certificaciones habían sido emitidas por Delve, una startup YC que ofrece cumplimiento automatizado —y que ha sido acusada públicamente de fabricar auditorías sin el rigor que los estándares exigen.
Esto no es un problema exclusivo de LiteLLM ni de Delve. Es un patrón sistémico: el ecosistema SaaS de compliance generó un mercado de certificaciones express que da la apariencia de seguridad sin el trabajo que la sustenta. Las empresas que integran dependencias basadas en esos badges están operando con una ilusión de seguridad, no con seguridad real.
Si el ataque a LiteLLM demuestra algo, es que el modelo de confianza que heredamos del software empresarial tradicional —donde un badge SOC 2 significaba algo— no funciona en el ecosistema open source de IA, donde los proyectos escalan a millones de descargas diarias antes de que nadie audite seriamente qué ocurre en su pipeline de publicación.
El stack de IA tiene una superficie de ataque que nadie gestiona bien
El caso LiteLLM es parte de una tendencia que ya documentamos en el auge de startups como Corridor, que levantó $25M específicamente para asegurar el código generado y desplegado por IA. También resonó con lo que señalamos cuando Big Tech invirtió $12,5M en seguridad open source: la inversión es microscópica respecto a la exposición real.
La realidad es que la cadena de dependencias de un proyecto de IA moderno puede tener decenas de paquetes críticos con acceso a secretos de producción, mantenidos por equipos pequeños, con pipelines de publicación poco auditados. LiteLLM tenía 40.000 estrellas en GitHub y 3,4 millones de descargas diarias. No tenía los controles de publicación de un proyecto con esa escala de impacto.
Esto no es culpa del proyecto —lo gestionó bien una vez que detectó el problema, contrató a Mandiant y documentó el incidente con transparencia ejemplar. El problema estructural es que el ecosistema asume que un proyecto popular es un proyecto seguro. No lo es. Popularidad y seguridad son cosas distintas.
¿Qué cambia después de este incidente?
Para los equipos técnicos, la respuesta inmediata es clara: anclar versiones de dependencias críticas con acceso a secretos, auditar pipelines de CI/CD para verificar que no instalen paquetes sin versión fija, rotar credenciales si se estuvo en la ventana afectada. Los indicadores de compromiso están documentados públicamente por LiteLLM y Sonatype.
Pero la pregunta más importante es de segundo orden: ¿cómo se decide en qué open source confiar cuando los proyectos más críticos de tu stack de IA pueden ser comprometidos en una ventana de horas?
Algunas respuestas prácticas:
- Tratar las dependencias de IA con el mismo rigor que las credenciales: Un paquete con acceso a tus API keys de modelos es tan crítico como un módulo de autenticación. Debe auditarse con la misma intensidad.
- Desconfiar de certificaciones automatizadas para dependencias de infra: SOC 2 emitido por un proveedor de compliance express no reemplaza una auditoría de cadena de suministro real.
- Implementar controles de tiempo de ejecución: Herramientas como Sonatype Repository Firewall detectaron y bloquearon las versiones maliciosas en segundos. Ese tipo de protección activa es lo que marca la diferencia en una ventana de horas.
- Monitorear dependencias transitivas: El riesgo no viene solo de los paquetes que instalas directamente, sino de los que tus dependencias instalan a su vez.
El precedente que queda
LiteLLM es un caso de supply chain attack que ya hemos visto antes —SolarWinds, log4j, xz-utils— aplicado al nuevo contexto: el ecosistema de infraestructura de IA. La novedad es la posición que ocupa: no es una utilidad de sistema operativo, sino la capa que conecta tus datos con los modelos de lenguaje más poderosos del mundo.
La tesis que emerje de este incidente no es que el open source de IA sea inherentemente inseguro. Es que la velocidad con que el ecosistema de IA creció no fue acompañada de la madurez de seguridad que ese crecimiento requería. LiteLLM pasó de proyecto de nicho a infraestructura crítica de millones de sistemas sin que el modelo de confianza cambiara en consecuencia.
La pregunta que cada equipo debería hacerse no es “¿estamos usando LiteLLM?” sino “¿cuántas dependencias de nuestro stack de IA tienen acceso a secretos de producción y cuánto sabemos realmente de cómo se publica su código?”
La respuesta honesta, para la mayoría, es incómoda.
Fuentes
- LiteLLM — Security Update: Suspected Supply Chain Incident
- Sonatype — Compromised litellm PyPI Package Delivers Multi-Stage Credential Stealer
- Snyk — How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM
- Ecosistema Startup — LiteLLM: Caso de malware y fallos en certificación de seguridad
