LiteLLM hackea: 2.500 empresas afectadas por la mayor brecha de IA de 2026

¿Cuánto daño dejó el ataque a LiteLLM?

Más de 2.500 organizaciones y 434.000 pipelines de integración continua fueron comprometidos en una sola ventana de 40 minutos. Este es el alcance del ataque de cadena de suministro más grande contra infraestructura de inteligencia artificial documentado hasta ahora, según análisis independientes de las firmas de ciberseguridad CloudSEK y Hudson Rock, que publicaron hallazgos entre el 12 y el 13 de agosto de 2026.

El objetivo final fue LiteLLM, un proxy de código abierto ampliamente adoptado para gestionar llamadas a modelos de lenguaje grande (LLM) en entornos empresariales. Pero la cadena de compromiso comenzó mucho antes, en otro proyecto open source: el escáner de vulnerabilidades Trivy de Aqua Security. El grupo de amenazas conocido como TeamPCP infiltró primero los pipelines de GitHub Actions de Trivy, y desde allí escaló hasta comprometer los sistemas de construcción de LiteLLM, publicar versiones maliciosas en PyPI y distribuir malware a sus usuarios.

Según SecurityWeek, aunque los paquetes modificados (versiones 1.82.7 y 1.82.8) estuvieron disponibles solo durante 40 minutos, esa ventana fue suficiente para que el código malicioso se propagara exponencialmente. "Los sistemas automatizados de compilación comprimen el tiempo", señaló CloudSEK. "Una vez que un artefacto malicioso llega a un registro, los trabajos programados, los resolvedores de dependencias, los runners efímeros y las capas en caché pueden copiarlo rápidamente".

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

La cadena de compromiso: de Trivy a LiteLLM

La sofisticación del ataque radica en su diseño multicapa. TeamPCP no atacó directamente a LiteLLM. En cambio, infectó Trivy, un escáner de vulnerabilidades utilizado por miles de equipos de desarrollo. Dado que los desarrolladores de LiteLLM ejecutaban Trivy en su propia pipeline de CI/CD, el escáner comprometido obtuvo acceso legítimo al entorno de ejecución de LiteLLM.

Esto permitió a los atacantes exfiltrar silenciosamente los tokens de publicación de PyPI de LiteLLM. Con esas credenciales, subieron las versiones 1.82.7 y 1.82.8 del paquete, que contenían código malicioso diseñado para ejecutarse cada vez que se iniciaba el intérprete de Python, sin necesidad de importar explícitamente la librería.

El payload utilizaba un hook de inicio .pth de Python para ejecutar tres etapas de ataque: recolección de variables de entorno, archivos de configuración local (como .kube/config y .aws/credentials), intentos de movimiento lateral en clusters de Kubernetes e instalación de una backdoor persistente en systemd.

Según Ars Technica, el equipo detrás de TeamPCP está "compuesto en gran parte por adolescentes", lo que subraya cómo actores relativamente pequeños pueden operar con sofisticación técnica superior a muchas organizaciones corporativas.

La escala revelada: 153 GB de secretos expuestos

Mientras la comunidad de seguridad analizaba el comportamiento del malware, Hudson Rock obtuvo acceso directo a los datos exfiltrados: un archivo RAR de 153 GB que contiene exactamente 433.909 archivos. A través de su análisis, atribuyeron 118.829 volcados de runners de CI/CD a 2.488 dominios corporativos afectados.

Entre los secretos expuestos se incluyen claves de infraestructura en la nube (AWS_SECRET_ACCESS_KEY), tokens de despliegue de Bitbucket, claves API de Elastic, JWTs internos, tokens NPM, credenciales de Salesforce (SALESFORCE_CLIENT_SECRET), firmas de Slack (SLACK_SIGNING_SECRET) y claves de proveedores de IA que daban acceso directo a la infraestructura de enrutamiento de LLM de las víctimas.

Ars Technica confirmó la legitimidad de los datos a través del investigador independiente de seguridad Kevin Beaumont, quien declaró: "He confirmado que los datos son legítimos, múltiples organizaciones víctimas lo verificaron. Contiene un volumen significativo de contenido sensible en organizaciones. Es una brecha masiva de supply chain debido a la mala seguridad de IA — no porque la IA sea la amenaza, sino porque los adolescentes pueden dejar en ridículo a organizaciones obsesionadas con lanzar IA rápidamente y con deficiente seguridad DevOps".

Organizaciones impactadas

Las listas de víctimas publicadas por CloudSEK e independientemente verificadas por Hudson Rock incluyen nombres de primer nivel del ecosistema tecnológico global:

Amazon Web Services (AWS), Nvidia Corporation, Samsung Electronics, Cisco Systems, Salesforce, ServiceNow, Siemens AG, John Deere, Epic Games, Orange S.A., S&P Global, Regeneron Pharmaceuticals, London Stock Exchange Group, Thomson Reuters, FedEx, Volkswagen AG, Deloitte, X Corp (Twitter), Zscaler, HP Inc., Philips, Vodafone Group, Deutsche Bahn, BT Group, Roku, TomTom y MediaTek, entre otras.

Un detalle crítico: muchos de los archivos en la base de datos exfiltrada no contienen atribución organizacional clara. Como señala Hudson Rock, "muchos pipelines de CI/CD están configurados de forma genérica. Las variables volcadas contienen contraseñas activas de bases de datos, claves API de terceros y credenciales de nube sin ningún correo electrónico identificable, dominio personalizado o nombre de servidor interno". Esto significa que numerosas organizaciones tienen secretos activos en esta base de datos sin saberlo.

¿Qué significa esto para tu startup?

Este incidente demuestra que la infraestructura de inteligencia artificial se ha convertido en un punto de fallo único. Como advirtió CloudSEK: "El incidente no fue solo una brecha de cadena de suministro de software que involucró a un producto de IA. Demostró que comprometer un punto de control de IA puede exponer las identidades y sistemas alrededor de él".

Para founders y equipos de engineering, esto tiene implicaciones concretas:

1. Revisa inmediatamente tus versiones de LiteLLM. Si utilizas cualquier proxy de infraestructura de IA, escáneres de vulnerabilidades de terceros o paquetes downstream de IA, audita tu entorno buscando las versiones 1.82.7 y 1.82.8 de LiteLLM. Según Hudson Rock, debes asumir que cualquier secreto accesible por tu entorno LiteLLM está comprometido.

2. Revoca agresivamente todas las credenciales. Invalida y rota todas las claves IAM de AWS/GCP/Azure, tokens de service account de Kubernetes y PATs de GitLab/GitHub. Revisa los logs de AWS CloudTrail y auditorías de Kubernetes API buscando actividad anómala desde el 24 de marzo de 2026 (fecha aproximada del ataque).

3. Verifica persistencia en tus entornos. Busca archivos .pth no autorizados en el directorio site-packages y servicios systemd sospechosos que puedan disfrazarse como "System Telemetry Service". Implementa filtrado estricto de egreso en los entornos de runners de CI/CD.

4. Exige transparencia sobre herramientas de terceros. Este ataque ocurrió porque un escáner de seguridad (Trivy) fue comprometido y afectó indirectamente a LiteLLM. Como startup, debes conocer qué herramientas de terceros ejecutan código en tus pipelines y tener planes de contingencia ante compromisos de proveedores críticos.

Alon Gal, cofundador y CTO de Hudson Rock, resumió el cambio de paradigma: "Una ventana de aproximadamente 40 minutos en la que la dependencia de LiteLLM fue hackeada llevó a más de 430.000 instancias en las que millones de secretos fueron cosechados. Esta magnitud nos empuja a un mundo completamente nuevo respecto al tipo de respuesta requerida desde la industria de ciberseguridad".