El 24 de marzo de 2026, mientras los desarrolladores de IA aún estaban programando, LiteLLM en PyPI fue comprometido silenciosamente. El repositorio PyPI de LiteLLM, una biblioteca de código abierto de Python con 97 millones de descargas mensuales, fue modificado maliciosamente en la madrugada, y dos versiones infectadas (1.82.7 y 1.82.8) se publicaron silenciosamente. En tan solo tres horas, decenas de miles de entornos de desarrollo y sistemas empresariales quedaron potencialmente expuestos a filtraciones de datos. A diferencia de los ataques comunes, este incidente no fue una inyección maliciosa aislada, sino un ataque en cadena cuidadosamente planificado por el grupo de hackers TeamPCP. MistEye, la herramienta de inteligencia de amenazas Web3 y monitoreo de seguridad dinámico desarrollada por SlowMist, también envió de inmediato alertas de inteligencia de amenazas relevantes a los clientes pertinentes. El origen de este ataque a LiteLLM no fue una vulnerabilidad en la propia biblioteca, sino que el escáner de seguridad de código abierto Trivy, utilizado en su canalización de CI/CD, ya había sido comprometido. Cronología del ataque: El 19 de marzo, TeamPCP manipuló la etiqueta de GitHub Action de Trivy, inyectando código malicioso; el 23 de marzo, los atacantes comprometieron la herramienta de escaneo de seguridad Checkmarx KICS, allanando el camino para un ataque posterior; el 24 de marzo, mientras la canalización de CI/CD de LiteLLM ejecutaba la versión corrupta de Trivy, se robó el token de lanzamiento de PyPI. Los atacantes lo utilizaron para eludir el proceso de lanzamiento normal, enviando directamente dos versiones maliciosas a PyPI, "envenenando" efectivamente la biblioteca de dependencias principal de la IA. La exposición de este ataque fue bastante dramática: los atacantes inicialmente pretendían permanecer en silencio, pero se produjo un descuido en su código malicioso: el archivo litellm_init.pth, inyectado en la versión 1.82.8, se ejecutaba automáticamente cada vez que se iniciaba un proceso de Python, activándose repetidamente a través de procesos secundarios, lo que provocaba directamente que las máquinas de prueba de los ingenieros de FutureSearch se quedaran sin memoria y fallaran. Fue esta vulnerabilidad inesperada la que expuso prematuramente un ataque que podría haber permanecido latente durante días o incluso semanas; de lo contrario, las consecuencias habrían sido inimaginables. El malware de TeamPCP para LiteLLM emplea una estrategia de ejecución por fases, lo que resulta en una alta discreción, un amplio alcance de daños y capacidades de propagación persistente y lateral, que superan con creces el daño causado por los ataques típicos a la cadena de suministro. La primera fase implica la recopilación de información; el malware escanea sistemáticamente todos los datos confidenciales del host infectado, abarcando una amplia gama de áreas: desde las claves privadas SSH de los desarrolladores, las configuraciones de Git y el historial de la shell, hasta las credenciales del proveedor de servicios en la nube de la empresa (AWS/GCP/Azure), las configuraciones de Kubernetes, las contraseñas de la base de datos e incluso los archivos de monederos de criptomonedas y las frases mnemotécnicas. Cabe destacar que LiteLLM, como puerta de enlace para el acceso unificado a varias API de modelos grandes, suele almacenar claves de múltiples proveedores de modelos. Una vez comprometido, esencialmente abre la puerta a la infraestructura de IA de la empresa directamente a los atacantes.La segunda fase implicó la fuga de datos cifrados. Todos los datos recopilados se cifraron utilizando el algoritmo AES-256-CBC, con una clave pública RSA de 4096 bits para proteger la clave de sesión. Estos datos se empaquetaron en un archivo tar y se enviaron al dominio falso models.litellm.cloud, controlado por el atacante, registrado el día anterior al ataque y completamente ajeno a la infraestructura oficial de LiteLLM, lo que lo hacía altamente engañoso. Se reveló que los atacantes robaron aproximadamente 300 GB de credenciales comprimidas, que incluían 500 000 credenciales confidenciales. La tercera fase implicó la persistencia y el movimiento lateral, que también es la fuente más peligrosa de las consecuencias del ataque. En la máquina local, un código malicioso creó un script de puerta trasera, sysmon.py, en el directorio del usuario y lo habilitó para que se iniciara automáticamente a través del servicio systemd. Incluso después de desinstalar LiteLLM, la puerta trasera podía seguir ejecutándose. Si se detectaba un entorno Kubernetes, los atacantes utilizaban tokens de cuentas de servicio para desplegar Pods privilegiados en todos los nodos del clúster, logrando una propagación por toda la red y transformando una infección en un único host en una crisis de seguridad para todo el clúster. Los atacantes también intentaron encubrir su ataque utilizando bots maliciosos para enviar spam y robando cuentas de mantenedores para cerrar incidencias en GitHub. Actualmente, PyPI ha retirado la versión infectada y se ha levantado la zona de cuarentena. Los mantenedores de LiteLLM están gestionando las consecuencias, pero los efectos posteriores de este ataque están lejos de haber terminado. En primer lugar, está el reto de limpiar la puerta trasera persistente. Algunos usuarios podrían haber desinstalado LiteLLM y asumido que el riesgo había desaparecido, sin saber que la puerta trasera seguía recopilando datos en segundo plano. En segundo lugar, está la reacción en cadena de las filtraciones de credenciales; las 500.000 credenciales robadas podrían crear un efecto dominó. Por último, está el riesgo de propagación a través de cadenas de dependencias. LiteLLM es referenciado por más de 2000 paquetes, incluidos DSPy, MLflow y Open Interpreter, y muchos desarrolladores introdujeron indirectamente versiones maliciosas mediante el uso de otras herramientas. El ataque LiteLLM recuerda al incidente de seguridad de Trust Wallet. En este ataque LiteLLM, también se incluyeron en el robo archivos de billeteras de criptomonedas y frases mnemotécnicas, y los atacantes poseían capacidades de latencia a largo plazo y movimiento lateral. De hecho, la organización TeamPCP había ridiculizado públicamente a los proveedores de seguridad por "no poder proteger ni siquiera sus propias cadenas de suministro" y afirmó tener planes a largo plazo para robar secretos comerciales. Este ataque LiteLLM es solo una parte de su intrusión sistemática en el ecosistema de código abierto. Ante este ataque y sus consecuencias, tanto los desarrolladores individuales como las empresas deben tomar medidas inmediatas: 1. Compruebe inmediatamente si hay infecciones; si es la versión 1.82.7 o 1.82.8, desinstálela inmediatamente y borre la caché; 2. Rote completamente las credenciales sensibles, incluidas las claves SSH, las credenciales del proveedor de servicios en la nube, las contraseñas de la base de datos, las claves API, especialmente las claves privadas de la billetera de criptomonedas y las frases mnemotécnicas; 3.Estandarizar la gestión de dependencias, restringir LiteLLM a las versiones de seguridad 1.82.6 e inferiores, y reforzar la seguridad del pipeline de CI/CD. El ataque a la cadena de suministro de LiteLLM no solo reveló la vulnerabilidad del ecosistema de código abierto, sino que también nos recordó que, en el panorama actual de la IA, en constante evolución, la seguridad de las bibliotecas de dependencias principales está directamente relacionada con la estabilidad de todo el ecosistema. Solo tomando en serio la seguridad de la cadena de suministro, identificando rápidamente los riesgos potenciales y mejorando los sistemas de protección podremos evitar pérdidas importantes similares y salvaguardar nuestros datos y activos. [SlowMist Technology]