Ataque a LiteLLM expone terabytes de credenciales

⏱ Tiempo de lectura: 4 min

Terabytes de credenciales de organizaciones globales fueron expuestos en un ataque a la cadena de suministro contra LiteLLM, una herramienta de código abierto para desarrollo de software impulsado por IA. Las firmas de seguridad CloudSEK y Hudson Rock revelaron el incidente el martes y miércoles, identificando que más de 2.500 organizaciones fueron comprometidas, incluidas Microsoft, Amazon, Cisco, Samsung y Salesforce.

Ataque de 40 minutos a través de LiteLLM comprometido

El robo ocurrió durante una ventana de 40 minutos en marzo cuando víctimas descargaron versiones comprometidas de LiteLLM desde el repositorio oficial del Python Package Index. CloudSEK encontró claves en la nube, tokens de repositorio, claves SSH, secretos de Kubernetes, credenciales de publicación de paquetes, variables de entorno y claves de proveedores de IA. Hudson Rock analizó un archivo de 195 TB para hacer el descubrimiento. El grupo TeamPCP, compuesto mayormente por adolescentes, se atribuyó el ataque. Herramientas y Apps de desarrollo fueron el objetivo central.

Cifras exactas, empresas afectadas y alcance

CloudSEK y Hudson Rock confirmaron con alta confianza que 434.000 pipelines de CI/CD (integración continua/entrega continua) tuvieron credenciales expuestas. Las organizaciones identificadas incluyen: Nvidia, Amazon Web Services (AWS), Samsung Electronics, Salesforce, Cisco Systems, F. Hoffmann-La Roche, ServiceNow, Siemens, S&P Global, Airbus US Space & Defense, John Deere, Regeneron Pharmaceuticals, London Stock Exchange Group (LSEG), Thomson Reuters, FedEx, Munich Reinsurance, MediaTek, Volkswagen, Deloitte, Kroger, Siemens Energy, Thales Group, X Corp (Twitter), Zscaler, Epic Games, Orange S.A., HP Inc., Philips, Fortum, Vodafone Group, Carl Zeiss, Deutsche Bahn, NGINX Inc., BT Group, Liebherr, Krungthai Bank y Roku. El compromiso incluyó versiones 1.82.7 y 1.82.8 de LiteLLM. Más detalles en Ars Technica.

Qué se puede esperar ahora

Las firmas de seguridad aconsejan rotación agresiva de credenciales en todos los pipelines afectados, revocación completa de tokens de automatización, invalidación de claves en la nube, tokens de cuenta de servicio Kubernetes y tokens de acceso personal de GitHub/GitLab, además de auditoría de registros. El incidente subraya cómo la prisa por integrar IA en sistemas de entrega de software amplifica riesgos de seguridad en cadenas de suministro abiertas.

Dato	Detalle
Herramienta atacada	LiteLLM (código abierto para desarrollo con IA)
Ventana de exposición	40 minutos en marzo de 2026
Versiones comprometidas	1.82.7 y 1.82.8
Organizaciones afectadas	Más de 2.500 (434.000 pipelines CI/CD)
Datos expuestos	Terabytes: claves en la nube, tokens SSH, secretos Kubernetes, credenciales de IA
Responsables	Grupo TeamPCP (mayormente adolescentes)
Descubrimiento	CloudSEK y Hudson Rock (martes y miércoles)
Causa raíz	Ataque anterior a Trivy (escáner de vulnerabilidades)

Preguntas frecuentes sobre el ataque a LiteLLM

¿Qué tipos de credenciales fueron expuestos?

Claves en la nube, tokens de repositorio, claves SSH, secretos de Kubernetes, credenciales de publicación de paquetes, variables de entorno y claves de proveedores de IA que permitían acceso a más de 2.500 organizaciones.

¿Cuánto tiempo estuvo activo el ataque?

Solo 40 minutos en marzo, pero fue suficiente para comprometer 434.000 pipelines de CI/CD en organizaciones que descargaron las versiones maliciosas desde el repositorio oficial.

¿Qué deben hacer las organizaciones afectadas?

Auditar inmediatamente los entornos para detectar versiones 1.82.7 y 1.82.8, realizar revocación agresiva de credenciales, invalidar todas las claves en la nube, tokens Kubernetes y tokens de GitHub/GitLab, y revisar registros de acceso y filtrado de salida.

Qué conviene mirar de cerca

El investigador de seguridad Kevin Beaumont señaló que el incidente refleja cómo organizaciones enfocadas en acelerar implementaciones de IA descuidan prácticas fundamentales de DevOps. Aunque muchos pipelines CI/CD se configuran genéricamente sin identificadores de empresa, los datos expuestos contienen contraseñas de base de datos activas, claves API de terceros y credenciales en la nube sin protección.

En Inteligencia Artificial entendemos que este ataque expone una tensión crítica: la prisa por integrar IA en cadenas de suministro sin fortalecer primero los controles de seguridad básicos. La lección es que ninguna herramienta de IA, sin importar cuán útil sea, reemplaza una higiene de seguridad rigurosa en toda la infraestructura.

Fuente: arstechnica.com