El robo a LiteLLM deja 153 GB de credenciales de 2,488 empresas y 433,909 archivos expuestos
El análisis del archivo sustraído en el ataque de cadena de suministro a LiteLLM identifica 118,829 volcados de runners de integración continua atribuidos a 2,488 dominios corporativos.
El análisis forense del archivo robado durante el ataque a LiteLLM cerró la cuenta del incidente: 153 gigabytes de datos, 433,909 ficheros y 118,829 volcados de ejecutores de integración continua atribuidos a 2,488 dominios corporativos. La firma Hudson Rock publicó el desglose el 13 de agosto y confirma la escala del que ya figura como el mayor compromiso de cadena de suministro del año.
Cómo ocurrió
El 24 de marzo de 2026 el grupo identificado como TeamPCP subió a PyPI las versiones 1.82.7 y 1.82.8 de LiteLLM, un proxy de código abierto ampliamente desplegado en infraestructura corporativa. El acceso al proceso de publicación se obtuvo por una cadena de tres pasos que conviene leer con detenimiento.
El pipeline de integración continua de LiteLLM instalaba Trivy —un escáner de vulnerabilidades— sin fijar la versión a una referencia verificada. Los atacantes envenenaron ese escáner. El escáner comprometido, ejecutándose con los permisos del pipeline, robó el token de publicación de PyPI del proyecto. Con ese token, las versiones maliciosas quedaron firmadas y distribuidas como legítimas.
El código insertado, catalogado como SANDCLOCK Stealer, recolectó llaves SSH, credenciales de AWS, Google Cloud y Azure, tokens de Kubernetes, secretos de integración continua y claves de API de proveedores de modelos.
Alcance del daño
La lista de organizaciones afectadas atraviesa sectores completos. Incluye NVIDIA, Amazon Web Services, Samsung Electronics, Cisco Systems, Salesforce, ServiceNow, Siemens, S&P Global, Airbus U.S. Space & Defense, John Deere, London Stock Exchange Group, Thomson Reuters, FedEx, Munich Re, MediaTek, Volkswagen, Deloitte, Thales, X Corp, Zscaler, Epic Games, Orange, HP, Philips, Vodafone, Deutsche Bahn, BT Group y Krungthai Bank.
La composición del listado importa tanto como su longitud. Aparecen proveedores de nube, fabricantes de semiconductores, aseguradoras, bancos, operadores de telecomunicaciones y contratistas de defensa. Cada credencial filtrada es una llave hacia entornos productivos de terceros.
Lectura de Tabuga Intelligence
El detalle técnico decisivo es el que menos titulares gana: la herramienta de seguridad fue el vector. Un escáner de vulnerabilidades instalado sin fijación de versión ejecutó código arbitrario con los privilegios del pipeline de publicación. La defensa se convirtió en la puerta.
Este patrón desarma una suposición operativa muy extendida. Los equipos de TI tratan las herramientas de seguridad como una categoría exenta del escrutinio que aplican al resto de dependencias. Se instalan desde el registro público, se actualizan automáticamente y se ejecutan con permisos elevados porque necesitan inspeccionar todo. Esa combinación —privilegio alto, actualización automática, procedencia no verificada— define exactamente el activo que un atacante busca.
El segundo elemento estructural es la amplificación. El compromiso de un solo proyecto de código abierto produjo credenciales de 2,488 organizaciones sin que ninguna de ellas fuera atacada de forma directa. El modelo de dependencias transitivas convierte un incidente puntual en un evento sistémico.
Qué debe hacer un equipo de TI en República Dominicana
La exposición local no depende de aparecer en la lista publicada. Cualquier organización que despliegue LiteLLM en alguna de las dos versiones comprometidas debe asumir compromiso de credenciales y actuar en consecuencia.
Las acciones inmediatas son cuatro. Rotar todas las credenciales de nube, llaves SSH y tokens de servicio que hayan pasado por pipelines con LiteLLM entre marzo y agosto. Auditar los registros de acceso de esas credenciales buscando uso desde geografías o rangos horarios anómalos. Fijar por hash todas las herramientas instaladas en pipelines de compilación, incluidas las de seguridad. Separar los permisos de publicación de los permisos de compilación, de modo que un pipeline comprometido no alcance el token de distribución.
Para el sector financiero regulado, este incidente entra en la categoría de riesgo de terceros que la Superintendencia de Bancos evalúa en sus revisiones de ciberseguridad. Documentar la verificación de exposición conviene tanto por prudencia técnica como por trazabilidad regulatoria.
Fuente: Help Net Security · Cybernews — 13 de agosto de 2026.