LiteLLM, un ataque a la cadena de suministro expone las credenciales de miles de organizaciones

Las versiones maliciosas publicadas en PyPI

Un ataque a la cadena de suministro de LiteLLM, gateway de código abierto para aplicaciones basadas en inteligencia artificial, habría provocado la distribución de la puerta trasera SANDCLOCK y la exposición de numerosas credenciales operativas.

La operación se atribuye al grupo TeamPCP, que, según las reconstrucciones disponibles, habría sustraído las credenciales de los administradores del proyecto. Posteriormente, los atacantes habrían cargado en PyPI las versiones comprometidas 1.82.7 y 1.82.8, publicadas alrededor de marzo de 2026.

Por tanto, la ventana de exposición podría haberse prolongado durante al menos varios meses. Algunas organizaciones quizá todavía no hayan detectado la instalación del componente alterado ni el uso posterior de las credenciales robadas.

LiteLLM se utiliza como biblioteca y capa de integración para enrutar solicitudes hacia más de un centenar de proveedores de modelos de lenguaje. Entre los entornos compatibles se encuentran OpenAI, Anthropic, Google Gemini y los modelos locales gestionados mediante Ollama.

La compromisión de un componente instalado en pipelines automatizados puede ampliar considerablemente el perímetro del ataque. No es necesario atacar directamente a cada empresa: basta con introducir código malicioso en un elemento compartido por numerosas aplicaciones y procesos de desarrollo.

SANDCLOCK y la posible ruta de las credenciales

El informe disponible identifica SANDCLOCK como una puerta trasera, pero no revela su funcionamiento interno ni indica qué datos recopila directamente o hacia qué infraestructuras los envía.

El aspecto más relevante es el contexto de ejecución de LiteLLM. El software puede estar presente en entornos de desarrollo, sistemas de integración y entrega continuas, herramientas de automatización y servicios que necesitan autenticarse frente a proveedores cloud o API de inteligencia artificial.

En estas condiciones, un paquete alterado puede acceder a variables de entorno, archivos de configuración y secretos utilizados por los pipelines. Entre las credenciales potencialmente expuestas se incluyen:

• claves para infraestructuras de AWS, GCP y Firebase;
• tokens para registros como Amazon ECR y JFrog;
• tokens personales de acceso a GitHub, o PAT;
• claves privadas de las GitHub App;
• credenciales SSH;
• secretos de clústeres Kubernetes;
• contraseñas de firma;
• claves API para servicios de IA, incluidas las de OpenAI y Anthropic.

Un acceso de este tipo puede permitir leer o modificar repositorios, manipular pipelines de build y deployment, acceder a registros de imágenes o paquetes e intervenir en infraestructuras cloud. Si existen permisos elevados, el riesgo puede extenderse a los clústeres Kubernetes y a los servicios publicados desde esos entornos.

No se sabe si todas las credenciales recopiladas se utilizaron para actividades posteriores. Sin embargo, la mera exposición exige revocar y sustituir los secretos, ya que no basta con asumir que una clave no ha sido utilizada.

El alcance de la exposición

Resecurity analizó un archivo de 150 GB atribuido a la actividad de TeamPCP. En su interior, los manifiestos owners.txt y repos.txt recogerían 898 propietarios de GitHub distintos, entre organizaciones y cuentas, distribuidos en 2.038 repositorios.

La compromisión está fragmentada: 631 propietarios tendrían un solo repositorio en la lista. El sujeto con mayor número de repositorios afectados sería Cencosud-Cencommerce, con 64.

Entre los nombres presentes figuran Microsoft, Azure, IBM, NVIDIA, PayPal (Zettle), Deloitte, Bosch, S&P Global, Elevance Health, 84.51° (Kroger), Adeo (Leroy Merlin), Kärcher, Dräger, ID.me y 1inch.

Resecurity contabilizó 2.146 registros basándose en los nombres de las claves. Los valores no se habrían examinado más allá del enmascaramiento estructural; por tanto, la cifra indica los elementos identificados en el archivo, no necesariamente credenciales aún válidas o utilizadas con éxito.

Según la reconstrucción, el incidente habría afectado a más de 2.500 organizaciones y a cientos de miles de entornos CI/CD. La diferencia entre el número total de organizaciones y el de propietarios de GitHub enumerados puede deberse a la estructura de los datos analizados y a los criterios de inventario.

Tecnología, finanzas y sanidad entre los sectores expuestos

El sector más representado es el de la tecnología y el software, donde el uso de herramientas de código abierto y pipelines automatizados está especialmente extendido.

Le siguen la banca, las finanzas y los seguros, y después la sanidad, la industria farmacéutica y la tecnología médica. La presencia de organizaciones reguladas aumenta la relevancia del incidente: una compromisión puede afectar a la continuidad operativa, la protección de datos y las obligaciones de gestión de accesos.

Los demás sectores identificados son:

1. retail y comercio electrónico;
2. medios, gaming y adtech;
3. manufactura e industria;
4. servicios profesionales;
5. ciberseguridad;
6. criptomonedas;
7. administración pública.

El riesgo concreto varía en función de los privilegios asignados a LiteLLM y de los pipelines en los que se instaló el paquete. Un entorno de pruebas aislado no tiene el mismo impacto que un runner de CI/CD autorizado para publicar imágenes, actualizar infraestructuras o desplegar aplicaciones en producción.

El ataque también puede aumentar el tiempo necesario para detectar el incidente. El malware podría haberse ejecutado en numerosos entornos con configuraciones diferentes, lo que complica la correlación de eventos y puede incrementar tanto el MTTD, el tiempo medio de detección, como el MTTR, el tiempo medio de respuesta y recuperación.

Comprobaciones que deben iniciarse de inmediato

Las organizaciones que hayan instalado LiteLLM deben comprobar la presencia de las versiones 1.82.7 y 1.82.8 en los proyectos, las imágenes de contenedor, las cachés de los gestores de paquetes y los runners de CI/CD. También deben revisarse las instalaciones indirectas mediante dependencias o imágenes preconfiguradas.

En caso de detectar estas versiones o ante cualquier duda, la respuesta debería incluir:

• revocar y regenerar las claves privadas de las GitHub App;
• sustituir los PAT y los tokens de GitHub;
• rotar las credenciales de AWS, GCP y Firebase;
• revocar los tokens de ECR y JFrog;
• sustituir las claves SSH;
• cambiar las contraseñas de firma;
• regenerar las claves API de los proveedores de IA;
• invalidar las sesiones activas.

La rotación debe comenzar por las cuentas con privilegios administrativos y por los secretos utilizados en los procesos de build y deployment. Los nuevos valores no deberían introducirse en pipelines que aún no hayan sido verificados.

La fase siguiente consiste en analizar los logs de GitHub, los runners de CI/CD, los registros, los proveedores cloud y los clústeres Kubernetes. Es necesario buscar accesos anómalos, creación de tokens, modificaciones de workflows, nuevas claves SSH, publicaciones inesperadas de paquetes o imágenes y despliegues no atribuibles a los operadores habituales.

No hay indicios disponibles de que el incidente se haya incorporado al catálogo KEV de CISA ni de que exista un plazo asociado para su mitigación. El material disponible tampoco señala un identificador CVE relacionado.

Quienes hayan instalado LiteLLM durante el periodo afectado deberían tratar las credenciales presentes en el entorno como potencialmente expuestas, incluso en ausencia de indicadores inmediatos de abuso. La compromisión de una dependencia de software puede dejar rastros en los sistemas posteriores mucho después de la publicación del paquete malicioso.