El incidente de LiteLLM: Una llamada de atención para la seguridad de infraestructura AI
El ataque a la cadena de suministro de LiteLLM comprometió claves API de OpenAI, Anthropic y Azure en el 36% de los entornos cloud. Flintworks no fue afectado — esto es lo que pasó y por qué importa la seguridad de la infraestructura AI.
El 24 de marzo, un grupo de atacantes conocido como TeamPCP publicó dos versiones con backdoor de LiteLLM — una de las bibliotecas proxy de IA más utilizadas en el ecosistema Python — en PyPI. En lo que se considera el mayor ataque a la cadena de suministro en la historia de la IA, cualquiera que instaló la versión 1.82.7 o 1.82.8 durante una ventana de tres horas desplegó sin saberlo un ladrón de credenciales dirigido a claves API de OpenAI, Anthropic, Azure, credenciales cloud, llaves SSH y secretos de Kubernetes.
¿Qué es LiteLLM y por qué importa?
LiteLLM es un gateway de IA que se ubica entre tus aplicaciones y los proveedores de LLM. Por diseño, tiene acceso a cada clave API que configuras. Está presente en aproximadamente el 36% de los entornos cloud y se descarga 3.4 millones de veces al día. Comprometer esta sola biblioteca dio a los atacantes un camino directo a las credenciales más sensibles de la infraestructura AI.
¿Cómo ocurrió?
El ataque fue un compromiso en cascada de la cadena de suministro. Primero, los atacantes envenenaron Trivy — un escáner de seguridad open source muy popular — reescribiendo las etiquetas de Git en su repositorio de GitHub Actions. Cuando el pipeline CI/CD de LiteLLM ejecutó Trivy como parte de su proceso de build, el escáner comprometido exfiltró el token de publicación de PyPI del mantenedor. Con ese token, TeamPCP publicó las versiones con backdoor directamente en PyPI.
El payload: un ataque en tres etapas
El código malicioso desplegó un recolector de credenciales que barría llaves SSH, credenciales cloud, archivos .env y wallets de criptomonedas; un kit de movimiento lateral en Kubernetes desplegando pods privilegiados en cada nodo; y un backdoor persistente vía systemd para acceso remoto continuo. Todos los datos robados fueron encriptados y exfiltrados a un dominio que imitaba la infraestructura legítima de LiteLLM.
Flintworks no fue afectado
No usamos LiteLLM en nuestra infraestructura. Nos conectamos a proveedores LLM directamente o a través de gateways confiables como Amazon Bedrock — no dependemos de capas proxy open source de terceros que concentren todas las credenciales en un solo punto de falla. Este incidente refuerza por qué elegir tu infraestructura AI con cuidado y gestionar su seguridad no es algo que quieras dejar al azar.
El panorama general
Este ataque es una llamada de atención para todo negocio que ejecuta IA en producción. Si tu equipo instaló paquetes sin versiones fijas, si tu pipeline CI/CD descarga dependencias sin verificación, o si no sabes exactamente qué bibliotecas de IA están corriendo en tu entorno — podrías estar más expuesto de lo que crees. La seguridad de la infraestructura AI no es opcional. Es fundamental.