El 24 de marzo de 2026, a las 10:52 UTC, alguien publicó la versión 1.82.8 de LiteLLM en PyPI. La librería tiene más de 50 millones de descargas. Es el proxy que millones de desarrolladores usan para hablar con OpenAI, Anthropic, Gemini y docenas de otros proveedores de IA. Y en esa versión venía escondido un ladrón de credenciales que no necesitaba que lo ejecutaras para activarse.
En pocas horas, PyPI aisló el paquete. Pero la ventana de exposición existe, y el vector es tan elegante como preocupante: un archivo .pth que Python ejecuta automáticamente al arrancar, sin import, sin que nadie lo invoque.
¿Cómo funciona el ataque exactamente?
Los archivos .pth en el directorio site-packages/ son un mecanismo de Python para extender el path de módulos al arrancar el intérprete. Es un feature legítimo, documentado, antiguo. El problema es que si una línea del archivo empieza por import, Python la ejecuta directamente.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀El archivo litellm_init.pth (34.628 bytes, listado en el propio RECORD del paquete) contenía esto:
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...'))"])El payload estaba codificado en base64 doble —invisible a cualquier grep simple— y al decodificarse ejecutaba un script en dos fases:
Fase 1 — recolección: El script aspiraba todo lo que encontraba. Variables de entorno (donde viven las API keys), claves SSH, credenciales de AWS, configuración de Kubernetes, tokens de GCP y Azure, archivos Docker, historial de shell, credenciales de bases de datos, URLs de webhooks de Slack y Discord, y hasta wallets de criptomonedas (Bitcoin, Ethereum, Solana, Cardano y varios más).
Fase 2 — cifrado y exfiltración: Los datos se comprimían en tpcp.tar.gz, se cifraban con AES-256-CBC usando una clave de sesión aleatoria de 32 bytes, y esa clave a su vez se cifraba con una clave RSA de 4096 bits controlada por el atacante. El resultado se enviaba vía POST a https://models.litellm.cloud/ —nótese: litellm.cloud, no litellm.ai, el dominio oficial. El dominio falso fue registrado el día anterior, 23 de marzo.
Por qué este ataque es especialmente peligroso para proyectos de IA
LiteLLM no es una librería cualquiera. Es la capa de abstracción que usan muchos equipos para no depender de un solo proveedor de modelos: los que construyen con ella suelen tener claves de API activas de OpenAI, Anthropic, Google, Cohere, Mistral y otros simultáneamente en su entorno. Un solo desarrollador comprometido puede exponer acceso a decenas de servicios de IA de pago.
Además, LiteLLM se despliega frecuentemente en infraestructura de producción y CI/CD pipelines. Un contenedor Docker que instaló la versión maliciosa sin ser un humano que “importó” la librería es igualmente vulnerable: el .pth se activa con cualquier proceso Python en ese entorno.
Es el tercer ataque de supply chain atribuido al mismo actor (identificado como TeamPCP) en marzo de 2026. El patrón se repite: dominio typosquatting registrado días antes, paquete publicado en horario de baja vigilancia, payload cifrado para evadir análisis superficial.
No es la primera vez que un ataque de este tipo golpea el ecosistema de herramientas para desarrolladores de IA. En 2025, el incidente de Clinejection comprometió 4.000 máquinas de desarrolladores a través de una inyección de prompt en el título de un GitHub issue procesado por un agente de código. El vector es distinto, el resultado parecido: atacantes aprovechan la confianza implícita que el ecosistema IA pone en sus propias herramientas.
Qué hacer si tienes litellm instalado
La comprobación inmediata es directa: buscar el archivo comprometido en tu entorno.
find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") -name "litellm_init.pth" 2>/dev/nullSi aparece, el daño potencial ya ocurrió. La respuesta debe ser:
- Rotar todas las credenciales del entorno — API keys, tokens SSH, configuraciones cloud, variables de entorno. No solo las de LiteLLM: todo lo que estuviera accesible en ese sistema.
- Revisar logs de red del período de exposición buscando conexiones salientes a
models.litellm.cloud. - Reinstalar desde una versión limpia: 1.82.6 es la última confirmada sin compromiso. Pin a versiones explícitas y verifica hashes con
pip download --hasho usa herramientas comopip-audit. - Auditar el pipeline CI/CD: si tu infraestructura ejecutó un job que instaló paquetes Python durante la ventana de compromiso, asumir compromiso y rotar credenciales de pipeline.
El problema estructural que esto expone
PyPI no tiene revisión de código. El modelo de confianza del ecosistema Python —y de npm, y de la mayoría de gestores de paquetes— es publicar-y-confiar, con verificación post-hoc cuando alguien reporta. El atacante en este caso usó las propias cuentas de publicación de LiteLLM (la auditoría de BerriAI está en curso al momento de publicar este artículo), lo que significa que el paquete venía firmado con credenciales legítimas. Los hash checks no habrían ayudado: el archivo malicioso tenía su propio hash correcto en el RECORD.
La industria de IA tiene una dependencia enorme de paquetes Python gestionados por equipos pequeños. LiteLLM es open source y mantenido activamente, pero como todo proyecto con más de 50 millones de descargas y pocas personas con acceso de publicación, es un objetivo valioso. El perímetro de seguridad de una empresa que construye con IA no termina en su código: termina en cada dependencia transitiva de su entorno de desarrollo.
La deuda de verificación en proyectos de IA no es solo sobre tests: es también sobre quién controla los paquetes que tu pipeline instala y si tienes visibilidad sobre qué se ejecuta en tu infraestructura.
Ataques como este son el argumento más concreto para lockfile estricto, auditoría de dependencias en CI, y ambientes de build aislados. No como buenas prácticas opcionales, sino como medidas mínimas para cualquier equipo que maneje credenciales de valor.
Por qué importa
Lo que hace a este incidente notable no es su sofisticación técnica —los ataques de supply chain en PyPI llevan años— sino el target. LiteLLM vive en el núcleo del stack de IA de muchas empresas. Comprometer un entorno de desarrollo con esta librería no es robar una contraseña: es potencialmente obtener acceso a las API keys que mueven los modelos de producción de una startup completa, las claves AWS de su infraestructura, y los tokens de sus pipelines de deployment.
PyPI actuó rápido. La ventana fue de horas. Pero el tiempo suficiente para que cualquier máquina o pipeline que hiciera pip install litellm sin pin —o actualizara automáticamente— fuera comprometida sin dejar rastro visible.
