Envenenaron LiteLLM: Un Plugin MCP en Cursor Lo Descubrió

El 24 de marzo de 2026, el grupo TeamPCP publicó dos versiones troyanizadas de LiteLLM en PyPI (1.82.7 y 1.82.8) con malware que roba credenciales SSH, API keys de LLMs, secretos cloud y wallets crypto. El ataque cadena suministro LiteLLM afecta a una librería con 95 millones de descargas mensuales y se descubrió porque un plugin MCP en Cursor crasheó una máquina con un fork bomb accidental.

Qué es LiteLLM y por qué le apuntaron

LiteLLM es una librería Python que unifica el acceso a modelos de lenguaje de OpenAI, Anthropic, Azure, Google y otros proveedores bajo una sola interfaz. Vos escribís tu código una vez y LiteLLM se encarga de traducir las llamadas a la API que corresponda.

Con 95 millones de descargas mensuales, LiteLLM es dependencia transitiva de frameworks de agentes IA, servidores MCP, herramientas de orquestación y prácticamente cualquier proyecto serio que trabaje con múltiples LLMs. Eso la convierte en un blanco ideal: comprometés un paquete y llegás a miles de entornos de desarrollo, servidores de producción y pipelines de CI/CD de una sola vez. La diferencia con otros ataques a PyPI es que acá no hablamos de un paquete de nicho con 200 descargas. Hablamos de infraestructura crítica del ecosistema IA.

Cronología del ataque cadena suministro LiteLLM: de Trivy al fork bomb

TeamPCP no arrancó por LiteLLM. Arrancó por Trivy, el escáner de seguridad de Aqua Security. Y eso es lo más perverso de todo el asunto: comprometieron una herramienta de seguridad para comprometer todo lo demás.

19 de marzo: cae Trivy

TeamPCP explota CVE-2026-33634 (CVSS 9.4) en Trivy. Defacean 44 repositorios y, lo que importa, capturan secretos del CI/CD de Trivy, incluyendo tokens de PyPI de maintainers que tenían LiteLLM como dependencia en sus pipelines.

23 de marzo: se expanden

Con los secretos capturados, comprometen KICS y Checkmarx GitHub Actions entre las 12:58 y 16:50 UTC. Van escalando.

24 de marzo, 10:52 UTC: LiteLLM cae

Publican litellm 1.82.7 y 1.82.8 en PyPI usando las credenciales robadas del maintainer. El paquete troyanizado empieza a distribuirse a los 95 millones de descargas mensuales. Tres horas después, PyPI pone ambas versiones en cuarentena. La ventana de exposición real fue de 10:39 a 16:00 UTC (si, unas 5 horas donde cualquiera que hiciera pip install litellm se comía el malware). Si te interesa, podés leer más sobre estrategias de segmentación y firewalls perimetrales.

Cómo lo descubrieron: un bug en el malware lo delató

Acá viene lo bueno. Un desarrollador estaba usando un plugin MCP dentro de Cursor IDE. El plugin tenía a LiteLLM como dependencia transitiva, así que al actualizar paquetes se instaló la versión 1.82.8 con el archivo .pth malicioso.

Los archivos .pth en Python se ejecutan automáticamente cada vez que arranca el intérprete. El malware de TeamPCP usaba subprocess.Popen para lanzar un proceso hijo desde el .pth, pero como el hijo también ejecuta Python (y el .pth se carga en cada inicio), el hijo dispara otro hijo, que dispara otro hijo, que dispara otro hijo. Fork bomb exponencial. La máquina se quedó sin RAM y crasheó.

Irónico: un bug en el código del atacante terminó revelando toda la operación. Si el malware hubiera funcionado silenciosamente como estaba diseñado, probablemente habría pasado más tiempo hasta que alguien lo notara.

Análisis técnico: dos vectores de infección

TeamPCP no se conformó con un solo mecanismo. Publicaron dos versiones con vectores diferentes, como para cubrirse.

Versión 1.82.7: payload embebido en proxy_server.py

El archivo litellm/proxy/proxy_server.py contenía un bloque base64 que se decodificaba y ejecutaba al importar litellm.proxy. Si tu aplicación usaba el proxy de LiteLLM (que es el caso de uso más común en producción), el malware se activaba automáticamente. Sin interacción del usuario, sin permisos especiales.

Versión 1.82.8: archivo .pth en site-packages

Esta versión metía un archivo litellm_init.pth en el directorio site-packages/. El tema con los .pth es que Python los ejecuta en CADA inicio del intérprete, sin necesidad de que nadie haga import litellm. Solo con tener el paquete instalado, el malware corría. Ni siquiera tenías que usar LiteLLM en tu código. Si te interesa, podés leer más sobre el reciente ataque a Trivy en GitHub Actions.

Qué robaba el malware

Te llega el aviso de que algo anda raro, revisás los procesos, ves conexiones salientes que no reconocés, chequeás qué archivos se modificaron y descubrís que el malware ya recopiló tus SSH keys, las credenciales de AWS, GCP y Azure, los configs de Kubernetes, cada archivo .env que encontró, las API keys de OpenAI y Anthropic, el historial completo del shell, wallets de criptomonedas, passwords de bases de datos, claves SSL y todos los secretos de tu pipeline CI/CD.

Además consultaba endpoints de metadata cloud (EC2 en AWS, GKE en Google) para extraer tokens de servicio temporales. Si corrías LiteLLM en un pod de Kubernetes, el atacante podía obtener credenciales del nodo completo.

Quién es TeamPCP

Tres ataques supply chain en marzo de 2026. Cinco ecosistemas comprometidos: GitHub Actions, Docker Hub, npm, Open VSX y PyPI. El patrón siempre es el mismo: comprometer una herramienta de seguridad, capturar secretos, usarlos para comprometer la siguiente herramienta en la cadena.

Según el análisis de Wiz, TeamPCP tiene capacidad operativa para moverse entre ecosistemas con rapidez. En cinco días pasaron de Trivy a KICS a Checkmarx a LiteLLM. No son improvisados.

Lo que llama la atención es la elección de blancos. No apuntan a paquetes random. Apuntan a herramientas de seguridad y de infraestructura IA, donde saben que van a encontrar credenciales de alto valor. Y el componente «Kamikaze» que Snyk identificó en la campaña (un wiper destructivo dirigido a clusters Kubernetes específicos) sugiere que no todo es robo de credenciales. Hay un componente de sabotaje geopolíticamente orientado.

Cómo verificar si estás afectado

Primero lo obvio: corré pip show litellm y verificá que la versión no sea 1.82.7 ni 1.82.8. Pero ojo, LiteLLM puede ser dependencia transitiva. Vos no la instalaste directamente pero está ahí porque otro paquete la necesita.

• Revisá la ventana de exposición: 24 de marzo de 2026, entre las 10:39 y las 16:00 UTC
• Buscá archivos de persistencia del malware: ~/.config/sysmon/sysmon.py y ~/.config/systemd/user/sysmon.service
• En Kubernetes: auditá pods con nombre node-setup-* en el namespace kube-system
• Revisá si tenés litellm_init.pth en tu directorio site-packages/
• Chequeá pip cache list por versiones 1.82.7 o 1.82.8 cacheadas

Y alguien reviso las dependencias transitivas de su proyecto? Exacto, casi nadie. Corrés pip freeze | grep litellm y te sorprendés.

Pasos de remediación inmediata

Andrej Karpathy lo puso en perspectiva: un simple pip install litellm bastaba para exfiltrar todo lo que tenías en la máquina. Cada credencial, cada key, cada secreto. En una línea de terminal. Si te interesa, podés leer más sobre herramientas de protección como Wordfence.

El paso 5 es el más doloroso pero el más crítico. Si el malware corrió en tu máquina aunque sea una vez, tenés que asumir que TODAS las credenciales presentes fueron comprometidas. No alcanza con desinstalar el paquete y seguir como si nada.

Qué significa esto para proyectos WordPress con IA

Si estás integrando IA en tu WordPress (chatbots, generación de contenido, asistentes) y usás LiteLLM como capa de abstracción para hablar con múltiples LLMs, tu servidor pudo haber sido afectado. Un entorno WordPress conectado a servicios cloud tiene credenciales de base de datos, API keys, y posiblemente acceso a servicios de hosting que el malware recolectaría sin discriminar.

Los archivos .env de WordPress suelen tener credenciales de la DB, keys de plugins premium, tokens de APIs externas. Todo eso entra en la lista de lo que el malware exfiltraba.

Lecciones para la cadena de suministro en el ecosistema IA

Los archivos .pth de Python son un vector de ataque poco conocido. La mayoría de los desarrolladores ni sabe que existen, mucho menos que se ejecutan automáticamente. Python los diseñó para configurar paths, pero nada impide meter código arbitrario ahí.

El patrón de TeamPCP expone algo preocupante: comprometer una herramienta de seguridad te da acceso a los secretos de toda la cadena. Trivy escanea vulnerabilidades en contenedores, así que los pipelines que lo usan tienen tokens de registros Docker, credenciales de PyPI, tokens de GitHub. Comprometés Trivy y tenés las llaves de todo lo demás.

Recomendaciones concretas:

• Pineá versiones en requirements.txt o pyproject.toml (nada de >=)
• Usá lock files (pip-compile, poetry.lock, uv.lock) y verificá hashes
• Monitoreá dependencias transitivas, no solo las directas
• Habilitá 2FA en PyPI si mantenés paquetes
• Auditá qué secretos tienen acceso tus pipelines CI/CD
• Revisá periódicamente qué archivos .pth hay en tu site-packages/

Errores comunes

Confiar en que PyPI valida los paquetes por vos

PyPI no hace análisis de malware antes de publicar. Cualquiera con credenciales válidas de un maintainer puede subir una versión nueva. La "seguridad" del repositorio depende de que la cuenta del maintainer no esté comprometida. En este caso, TeamPCP tenía credenciales legítimas robadas de un pipeline CI/CD.

No auditar dependencias transitivas

Ponele que vos instalás un framework de agentes IA. Ese framework depende de LiteLLM. Vos nunca escribiste pip install litellm, pero ahí está, corriendo en tu entorno. Si no revisás pip freeze regularmente, ni te enterás de que tenés un paquete comprometido instalado. Si te interesa, podés leer más sobre los parches críticos de marzo en AWS.

Asumir que desinstalar alcanza como remediación

Desinstalás LiteLLM y listo? No. Si el malware corrió, ya exfiltró tus credenciales. Desinstalar el paquete no revierte eso. Tenés que rotar cada secreto que estaba presente en la máquina. Cada SSH key, cada token de cloud, cada API key. Todo. Y auditar los logs de acceso para ver si ya usaron esas credenciales.

Preguntas Frecuentes

Cómo saber si tengo una versión afectada de LiteLLM?

Corré pip show litellm en tu entorno. Las versiones comprometidas son la 1.82.7 y la 1.82.8 publicadas el 24 de marzo de 2026. También revisá dependencias transitivas con pip freeze | grep litellm porque puede estar instalada sin que la hayas agregado directamente.

Qué credenciales roba el malware de LiteLLM?

SSH keys, credenciales de AWS, GCP y Azure, configuraciones de Kubernetes, archivos .env, API keys de OpenAI y Anthropic, historial de shell, wallets de criptomonedas, passwords de bases de datos, claves SSL y secretos de CI/CD. También consulta endpoints de metadata cloud para obtener tokens de servicio temporales.

Cuál es la relación entre el ataque a Trivy y el de LiteLLM?

TeamPCP primero comprometió Trivy explotando CVE-2026-33634 (CVSS 9.4) el 19 de marzo. Desde los pipelines CI/CD de Trivy robaron credenciales de PyPI de un maintainer de LiteLLM. Con esas credenciales publicaron las versiones troyanizadas cinco días después. Es un ataque en cascada: comprometés una herramienta de seguridad para llegar a las demás.

Qué pasa si LiteLLM solo estuvo instalada pero nunca la usé en mi código?

Si tenías la versión 1.82.8, el malware corría igual. El archivo .pth se ejecuta con cada inicio del intérprete Python, sin necesidad de importar nada. Con la versión 1.82.7 necesitabas importar litellm.proxy para activar el payload, pero muchas herramientas lo hacen automáticamente.

Conclusión

El ataque a LiteLLM no es un incidente aislado. Es el tercer eslabón de una campaña coordinada por TeamPCP que en menos de una semana comprometió cinco ecosistemas de software. El patrón (comprometer herramienta de seguridad, capturar secretos, comprometer herramientas downstream) es reproducible y probablemente lo veamos de nuevo.

Si usás LiteLLM (directa o transitivamente), verificá las versiones, buscá los archivos de persistencia y rotá credenciales si caíste en la ventana de exposición. Y más allá de este caso puntual, revisá cómo manejás las dependencias de tus proyectos Python. Los lock files, el pinning de versiones y el monitoreo de dependencias transitivas dejaron de ser "buenas prácticas opcionales" para convertirse en medidas de supervivencia.

Fuentes

• LiteLLM - Comunicado oficial de seguridad sobre el incidente de marzo 2026
• Wiz - Análisis de la campaña TeamPCP y la troyanización de LiteLLM
• Snyk - Investigación sobre el escáner de seguridad envenenado que comprometió LiteLLM
• The Hacker News - TeamPCP instala backdoors en versiones de LiteLLM
• ARMO - Análisis técnico del backdoor en el ataque supply chain a LiteLLM