Un “pip install” que roba todas tus credenciales: el ataque a LiteLLM y por qué tu empresa debería preocuparse
Callum McMahon estaba trabajando con normalidad en su editor de código cuando, de repente, su ordenador se quedó sin memoria RAM y se bloqueó. No estaba ejecutando nada especial. Solo había actualizado un plugin. Al investigar la causa del problema, descubrió algo que puso en alerta a toda la comunidad de desarrolladores: la actualización había instalado, de forma automática, una versión envenenada de LiteLLM, una de las librerías más populares del ecosistema de inteligencia artificial. Y esa versión llevaba un pasajero oculto.
El pasajero era un ladrón de credenciales. En cuestión de segundos, el código malicioso rastreaba el sistema en busca de claves SSH, credenciales de Amazon Web Services, Google Cloud y Azure, configuraciones de Kubernetes, carteras de criptomonedas, tokens de API, contraseñas de bases de datos, historiales de comandos y prácticamente cualquier secreto almacenado en el equipo. Todo ello se cifraba con una clave RSA de 4096 bits y se enviaba a un servidor controlado por los atacantes.
Lo más inquietante: para activar el malware no hacía falta ejecutar LiteLLM ni importar la librería en ningún proyecto. Bastaba con instalarla. El código malicioso se ejecutaba automáticamente cada vez que arrancaba cualquier proceso de Python en ese entorno.
Pero, ¿qué es LiteLLM y por qué importa?
LiteLLM es una librería de Python que permite conectarse a más de 100 proveedores de modelos de lenguaje (OpenAI, Anthropic, Google, entre otros) a través de una única interfaz. Es una pieza clave en la infraestructura de miles de aplicaciones de inteligencia artificial. Tiene más de 40.000 estrellas en GitHub y, según los datos públicos de PyPI, acumula aproximadamente 97 millones de descargas mensuales.
Pero LiteLLM no solo la instalan desarrolladores de forma consciente. Es lo que se conoce como una dependencia transitiva: muchos otros paquetes y herramientas la incluyen como parte de su instalación. Eso significa que puedes tener LiteLLM en tu sistema sin saberlo, porque otra herramienta que sí instalaste la necesita para funcionar. Y si esa versión concreta está comprometida, tu sistema también lo está.
Aquí reside la ironía más cruel de este ataque: LiteLLM es, por definición, el paquete que gestiona las claves API de todos los proveedores de IA de una organización. Los atacantes eligieron precisamente el componente que, por diseño, tiene acceso a todos los secretos.
Qué ocurrió exactamente
El 24 de marzo de 2026, las versiones 1.82.7 y 1.82.8 de LiteLLM fueron publicadas en PyPI (el repositorio central de paquetes de Python) con código malicioso inyectado. Ninguna de estas versiones correspondía a una publicación legítima del equipo de desarrollo: fueron subidas directamente por los atacantes utilizando credenciales robadas.
El ataque fue progresivo. La versión 1.82.7 contenía el código malicioso oculto en un archivo del servidor proxy, lo que requería que la librería fuera importada para activarse. Pero la versión 1.82.8, publicada poco después, era significativamente más agresiva: incluyó un archivo .pth que se ejecuta automáticamente con cada proceso de Python, sin necesidad de importar nada. Es decir, el simple hecho de tener la librería instalada bastaba para comprometer el sistema.
El malware funcionaba en tres fases. Primero, un recolector de credenciales barría el sistema en busca de claves SSH, credenciales cloud, secretos de Kubernetes, carteras de criptomonedas y archivos de configuración. Segundo, si detectaba que el sistema formaba parte de un clúster de Kubernetes, desplegaba pods privilegiados en cada nodo para extender el compromiso a toda la infraestructura. Y tercero, instalaba una puerta trasera persistente que contactaba periódicamente con un servidor externo para recibir nuevas instrucciones.
Toda la información robada se cifraba y se enviaba a models.litellm.cloud, un dominio diseñado para parecer legítimo pero controlado íntegramente por los atacantes.
Quién está detrás: TeamPCP y una campaña en cadena
El ataque a LiteLLM no fue un incidente aislado. Forma parte de una campaña coordinada atribuida a un grupo conocido como TeamPCP, que en las últimas semanas ha comprometido múltiples herramientas de seguridad y desarrollo de software en lo que podría describirse como un efecto dominó.
La secuencia fue la siguiente. El 19 de marzo, TeamPCP comprometió Trivy, el escáner de vulnerabilidades de Aqua Security, inyectando malware en sus acciones de GitHub y en sus imágenes de Docker Hub. El 23 de marzo, utilizando credenciales obtenidas en el ataque anterior, comprometieron KICS, la herramienta de análisis de seguridad de Checkmarx, junto con extensiones de Visual Studio Code y más de 66 paquetes de npm. Y el 24 de marzo, el ataque llegó a LiteLLM, probablemente porque el proyecto utilizaba Trivy en su proceso de integración continua.
Cada compromiso genera nuevas credenciales robadas que abren la puerta al siguiente objetivo. Como lo expresó Gal Nagli, responsable de exposición a amenazas en Wiz (propiedad de Google): la cadena de suministro del software de código abierto se está devorando a sí misma. Trivy se compromete, eso lleva a que LiteLLM se comprometa, las credenciales de decenas de miles de entornos acaban en manos de los atacantes, y esas credenciales conducen al siguiente compromiso.
Lo más preocupante del patrón de TeamPCP es su elección de objetivos. No atacan software cualquiera: atacan las herramientas que las empresas utilizan precisamente para protegerse. Escáneres de vulnerabilidades, acciones de CI/CD, gateways de API. Herramientas en las que las organizaciones confían implícitamente y que, por su naturaleza, tienen acceso privilegiado a credenciales e infraestructura.
Por qué esto afecta a tu empresa (aunque no seas desarrollador)
Es tentador leer esta noticia y pensar que es un problema exclusivo de programadores. Pero la realidad es muy distinta. El software que utilizan las empresas a diario (herramientas de productividad, plataformas SaaS, integraciones con servicios cloud, aplicaciones internas) está construido sobre miles de dependencias como LiteLLM. Y cuando una de esas piezas se compromete, el impacto se extiende a toda la cadena.
Pensemos en un escenario concreto. Una consultora tecnológica en Madrid utiliza una herramienta interna de IA para procesar documentos de clientes. Esa herramienta, sin que nadie lo sepa explícitamente, depende de LiteLLM para conectarse a los modelos de lenguaje. Si un desarrollador del equipo actualizó las dependencias el 24 de marzo por la mañana, la versión envenenada pudo haberse instalado automáticamente. Y en ese momento, todas las credenciales del sistema (claves de acceso a AWS, tokens de bases de datos, secretos de integración) habrían sido exfiltradas.
Esto no es un problema teórico. Según los investigadores de Endor Labs, el malware desplegado por TeamPCP en LiteLLM es capaz de escalar desde un único equipo comprometido hasta controlar clústeres enteros de Kubernetes, lo que en la práctica significa acceso completo a toda la infraestructura digital de una empresa.
Ataques a la cadena de suministro de software: la nueva normalidad
Los ataques a la cadena de suministro de software no son nuevos, pero su frecuencia y sofisticación están aumentando a un ritmo alarmante. El principio es sencillo y a la vez devastador: en lugar de atacar directamente a miles de empresas, el atacante compromete una única herramienta que todas ellas utilizan. Una sola brecha se multiplica automáticamente a través de la red de dependencias.
Andrej Karpathy, una de las figuras más reconocidas de la comunidad de inteligencia artificial, reaccionó al incidente de LiteLLM calificándolo de pesadilla del software moderno. Su argumento es contundente: cada vez que una empresa instala una dependencia, podría estar incorporando un paquete envenenado en cualquier punto del árbol de dependencias. Y cuanto más grande es el proyecto, más puntos de exposición existen.
En el caso concreto de la campaña de TeamPCP, el alcance es especialmente preocupante. En apenas cinco días, los atacantes han comprometido cinco ecosistemas diferentes: GitHub Actions, Docker Hub, npm, Open VSX y PyPI. La velocidad de propagación y la capacidad de pivotar de un objetivo al siguiente demuestran un nivel de sofisticación operativa que debería hacer reflexionar a cualquier empresa que dependa de software para operar.
Qué puede hacer tu empresa hoy
Incidentes como el de LiteLLM ponen de manifiesto una realidad incómoda: la superficie de ataque de cualquier empresa que utilice software (y en 2026, todas lo hacen) se extiende mucho más allá de sus propios sistemas. Incluye cada librería, cada dependencia, cada herramienta de terceros que forma parte del ecosistema digital.
Lo primero es la visibilidad. La mayoría de empresas no saben cuántas dependencias de software tienen ni cuáles de ellas representan un riesgo. Un inventario actualizado de los componentes digitales de la organización es el punto de partida para cualquier estrategia de protección.
Lo segundo es la capacidad de respuesta. La versión envenenada de LiteLLM estuvo disponible durante aproximadamente tres horas antes de ser detectada y retirada. Tres horas pueden parecer poco, pero son suficientes para que un sistema de integración continua actualice automáticamente las dependencias, construya una nueva imagen de producción y la despliegue. Sin monitorización continua y sin protocolos de respuesta rápida, esa ventana es más que suficiente para causar daños severos.
Y lo tercero, y quizá lo más importante, es asumir que la prevención absoluta no existe. Puedes fijar versiones de dependencias, auditar código, implementar controles de acceso estrictos, y aun así, un ataque como el de TeamPCP puede encontrar una vía de entrada. Por eso es fundamental contar con una estrategia que combine prevención, detección, respuesta y transferencia de riesgo.
En Axyom, trabajamos precisamente sobre esta visión. Nuestro AI CISO monitoriza de forma continua la postura de seguridad de tu empresa, identifica los riesgos materiales y genera evidencia verificable de los controles implementados. Y cuando la prevención no es suficiente, el componente asegurador de nuestra plataforma garantiza que el impacto financiero de un incidente esté cubierto.
Porque la cuestión ya no es si tu empresa se verá afectada por un incidente de ciberseguridad, sino cuándo. Y la diferencia entre las empresas que sobreviven y las que no está en cuánto tiempo tardaron en darse cuenta, qué capacidad de respuesta tenían, y si estaban financieramente protegidas para absorber el golpe.
Cronología de la campaña TeamPCP (marzo 2026)
19 de marzo — Compromiso de Trivy (Aqua Security). Inyección de malware en el escáner de vulnerabilidades y sus acciones de GitHub. 75 de 76 tags de trivy-action modificados.
23 de marzo — Compromiso de KICS (Checkmarx). Utilizando credenciales robadas en el ataque a Trivy, los atacantes comprometen las acciones de GitHub de Checkmarx, extensiones de VS Code y más de 66 paquetes de npm.
24 de marzo — Compromiso de LiteLLM. Las versiones 1.82.7 y 1.82.8, publicadas con código malicioso en PyPI, son detectadas y retiradas en aproximadamente tres horas. Los cinco ecosistemas afectados: GitHub Actions, Docker Hub, npm, Open VSX y PyPI.