El 24 de marzo de 2026, alguien envenenó LiteLLM en PyPI.

Si no conoces LiteLLM, es el paquete de Python más popular para gestionar API keys de múltiples proveedores de IA. Un solo proxy que se sienta entre tu aplicación y OpenAI, Anthropic, Google, Amazon — todos a la vez. Tiene más de 40.000 estrellas en GitHub y ~97 millones de descargas mensuales. Según Wiz, está presente en el 36% de los entornos cloud.

Las versiones 1.82.7 y 1.82.8 contenían un archivo .pth que se ejecutaba automáticamente cada vez que Python arrancaba en esa máquina. No necesitabas importar LiteLLM. No necesitabas llamar a ninguna función. Bastaba con que Python existiera en tu sistema para que el malware empezara a trabajar.

¿Qué recolectaba? SSH keys, credenciales de AWS, GCP y Azure, configuraciones de Kubernetes, tokens de git, archivos .env con todas tus API keys, historial de shell, wallets de criptomonedas, llaves privadas de SSL, secretos de CI/CD y contraseñas de bases de datos. Todo encriptado con AES-256 y enviado a un dominio controlado por los atacantes.

¿Cómo se detectó? Porque el malware era tan ineficiente que crasheó una máquina. Andrej Karpathy lo amplificó: un investigador de FutureSearch estaba usando un plugin MCP dentro de Cursor que tenía LiteLLM como dependencia transitiva. Cuando la versión 1.82.8 se instaló, su máquina se quedó sin RAM. Investigó, y encontró el payload.

Ninguna herramienta de seguridad lo detectó. Lo descubrió un accidente.

El escáner de seguridad fue el vector de entrada

Los atacantes — un grupo llamado TeamPCP — no fueron directo a LiteLLM. Primero comprometieron Trivy, el escáner de vulnerabilidades de Aqua Security. El 28 de febrero, un bot automatizado explotó una vulnerabilidad en el workflow de CI/CD de Trivy y robó un token de acceso personal.

Aqua remedió el daño superficial, pero no rotó todas las credenciales. TeamPCP mantuvo el acceso.

LiteLLM usaba Trivy en su propio pipeline de CI/CD para escanear vulnerabilidades. Cuando el pipeline corrió con la versión comprometida de Trivy, el token de publicación de PyPI quedó expuesto. Con ese token, TeamPCP publicó las versiones maliciosas directamente en PyPI — sin tocar el repositorio de GitHub, sin dejar rastro en el código fuente.

Lo que asumes	Lo que pasó
El escáner de seguridad protege tu supply chain	El escáner de seguridad fue el punto de entrada
El paquete en PyPI es el mismo código que en GitHub	El paquete fue reemplazado sin modificar el repositorio
pip install solo descarga código	pip install ejecutó malware automáticamente
Tu herramienta de gestión de credenciales las protege	Tu herramienta de gestión de credenciales las recolectó

Y no fue un incidente aislado. Según SecurityWeek, TeamPCP cruzó 5 ecosistemas en 5 días: GitHub Actions, Docker Hub, npm, OpenVSX y PyPI. Cada compromiso les daba las credenciales para desbloquear el siguiente. El incidente fue registrado como CVE-2026-33634 con una puntuación CVSS de 9.4.

Por qué esto es diferente de XZ Utils

En febrero escribimos sobre los riesgos de IA open-source y vibe coding, usando el backdoor de XZ Utils (CVE-2024-3094) como ejemplo de ataque a la cadena de suministro. Era un buen ejemplo. Pero LiteLLM es un caso distinto en tres formas que importan.

XZ Utils era infraestructura general de Linux — una librería de compresión presente en millones de servidores. LiteLLM es infraestructura específica de IA. No gestiona datos genéricos; gestiona las credenciales que conectan tu organización con cada proveedor de IA que usas. El atacante de XZ Utils quería acceso a servidores. TeamPCP quería las llaves de tu infraestructura de IA.

El atacante de XZ Utils pasó dos años ganándose la confianza del proyecto antes de actuar. TeamPCP cruzó cinco ecosistemas en cinco días. La infraestructura de IA es tan nueva y está tan poco vigilada que la velocidad, no la paciencia, es la estrategia ganadora.

Ninguno de los dos fue detectado por herramientas de seguridad. XZ Utils fue descubierto por un desarrollador que notó 500ms de latencia extra. LiteLLM fue descubierto porque el malware era tan mal escrito que crasheó una máquina. Si el payload hubiera sido 10% más eficiente, nadie se entera por semanas.

Lo que aprendí cuando Google hizo irrelevante mi empresa

A los 15 años cofundé Word Magic Software con mi padre — un software de traducción y diccionarios que evolucionó de DOS a Windows y fue destacado por Apple a nivel mundial. El día que Google Translate se hizo viable, Word Magic seguía funcionando perfectamente. Nuestro código no tenía un solo bug nuevo. Pero el ecosistema del que dependíamos — usuarios instalando software de escritorio para traducir — se evaporó.

El caso de LiteLLM es distinto en la causa pero idéntico en la estructura: el paquete funcionaba bien. Lo que falló fue la capa que lo entregaba a tu máquina. En ambos casos, la herramienta no fue el problema. Lo fue el eslabón que nadie estaba mirando.

Las herramientas son temporales. Las cadenas de confianza que las entregan también.

La mayoría de las empresas no tiene quién audite esto

La misma semana del ataque a LiteLLM, Jason Shuman, GP del fondo Primary VC, publicó datos que lo ponen en contexto: el 54% de las pymes carecen de experiencia interna en IA. El 41% tiene datos de calidad tan baja que la IA no sirve. Y el 41% ya prefiere comprar IA a través de un proveedor local de TI en lugar de hacerlo directamente.

Su tesis: mientras el marketing masivo vende agentes de IA como suscripciones de $20 al mes, las empresas reales están pagando $10,000 para que alguien los configure bien.

Eso es exactamente lo que hacemos en IQ Source para empresas en América Latina. La tecnología de IA es la misma en San José, Costa Rica, que en San Francisco — los mismos modelos, las mismas APIs, los mismos frameworks. Lo que cambia es quién la implementa, quién audita las dependencias, y quién responde cuando algo como LiteLLM pasa en tu stack.

No puedes hacer un “1-click install” de seguridad de IA. Si tu postura de seguridad para infraestructura de IA es “instalamos el paquete popular y seguimos adelante”, estás en la mayoría. Y la mayoría acaba de recibir un golpe.

Anatomía de una cadena de confianza de IA

Tu aplicación no habla directamente con OpenAI o Anthropic. Entre tu código y tus proveedores de IA hay una cadena de intermediarios, y cada uno es una suposición de confianza:

Tu app → LiteLLM (proxy) → Proveedores de IA (OpenAI, Anthropic, Google...)
Tu app → pip install → PyPI → mantenedor del paquete → su pipeline de CI/CD
Tu pipeline → escáner de seguridad → las dependencias del escáner

Cada flecha es un eslabón que puede romperse. La mayoría de las empresas auditan la primera cadena: qué proveedores de IA usan, qué modelos, qué SLAs tienen. Casi nadie audita la segunda ni la tercera.

Estas preguntas son distintas de las que ya cubrimos en el artículo sobre open-source. Aquellas eran sobre el proyecto en sí. Estas son sobre los intermediarios:

• ¿Quién mantiene los paquetes que están entre tu código y tu proveedor de IA?
• ¿Qué pasa si uno de esos intermediarios se compromete?
• ¿Fijas versiones exactas con hashes, o siempre instalas la última versión?
• ¿Cuándo fue la última vez que alguien en tu equipo verificó que pip install paquete realmente instala el código del repositorio de GitHub?
• ¿Tu herramienta de escaneo de seguridad es una dependencia más en tu pipeline, o la evalúas con el mismo rigor que el código que escanea?

Si no puedes responder a más de dos, tu cadena de confianza tiene eslabones ciegos.

Lo que hacemos en IQ Source cuando un cliente usa proxies de IA

Este no es un consejo genérico de “actualiza tus dependencias”. Es lo que específicamente revisamos cuando una empresa usa LiteLLM, o cualquier proxy que centralice credenciales de IA:

Lockdown de dependencias. Fijamos versiones exactas con hashes verificados. Nada se actualiza automáticamente en paquetes que gestionan credenciales. Cada actualización pasa por revisión manual del diff entre versiones antes de entrar a producción.

Aislamiento de credenciales. Ningún paquete accede a todas tus API keys de IA al mismo tiempo. Segmentamos por entorno (desarrollo, staging, producción) y por caso de uso. Si un entorno se compromete, el blast radius queda contenido.

Auditoría de la cadena de confianza. Mapeamos cada intermediario entre tu código y tus proveedores. ¿Cuántos paquetes hay en medio? ¿Cuáles auto-ejecutan código al instalar? ¿Cuáles dependen de herramientas de seguridad que, irónicamente, pueden ser el vector de ataque?

Detección que no depende de la suerte. El malware de LiteLLM se detectó porque crasheó una máquina. Eso no es una estrategia. Implementamos monitoreo de comportamiento: ¿cómo se ve el tráfico normal desde tu proxy de IA? Alertas cuando el patrón cambia — no cuando el atacante comete un error.

Si tu equipo usa LiteLLM o cualquier paquete de Python que gestione credenciales de IA, escribimos sobre los riesgos de desplegar frameworks de IA en producción que aplican directamente a este escenario.

Envíanos tu requirements.txt a contacto. Auditamos tu cadena de confianza en 2 horas y te decimos exactamente qué eslabones son vulnerables.