Ataques a la cadena de suministro de IA: la cadena de suministro es la superficie

El 19 de marzo de 2026, un grupo de amenazas llamado TeamPCP hizo force-push de 76 de 77 etiquetas de versión en el repositorio trivy-action de Aqua Security en GitHub. Trivy es el escáner de vulnerabilidades de código abierto más desplegado en la industria. Las nuevas etiquetas apuntaban a commits maliciosos que contenían un ladrón de credenciales. Dado que la mayoría de los pipelines CI/CD referencian Actions de GitHub mediante etiquetas de versión mutables en lugar de SHAs de commit fijados, cada organización que ejecutaba Trivy en su pipeline de compilación comenzó a ejecutar el código malicioso de inmediato. Los escaneos aún parecían tener éxito. El escáner aún reportaba vulnerabilidades. También recolectaba silenciosamente cada secreto en el entorno del runner.¹

Los ataques a la cadena de suministro explotan la composición de operaciones autorizadas para producir comportamiento no autorizado. Después de que los atacantes comprometieran Trivy mediante el secuestro de etiquetas de Actions de GitHub, utilizaron credenciales CI robadas para poner una puerta trasera en LiteLLM en PyPI, alcanzando 46.996 instalaciones en 46 minutos. Cada componente operó dentro de los permisos otorgados. La defensa estructural consiste en fijar las dependencias a referencias inmutables y tratar la instalación de paquetes como ejecución de código.

Cinco días después, el 24 de marzo, TeamPCP usó un token de publicación de PyPI robado de uno de esos entornos CI para publicar dos versiones con puerta trasera de LiteLLM, una biblioteca proxy de IA popular presente en el 36% de los entornos cloud.² La versión 1.82.8 incluía un archivo .pth que se ejecuta automáticamente en cualquier arranque de Python, antes de cualquier importación, antes de cualquier sandbox a nivel de aplicación. La carga útil barría claves SSH, credenciales cloud, contraseñas de base de datos, carteras de criptomonedas y secretos de CI/CD, las cifraba con una clave pública RSA codificada en duro y exfiltraba el archivo a un dominio controlado por el atacante registrado el día anterior.³

PyPI puso en cuarentena ambas versiones después de 46 minutos. En esa ventana, ocurrieron 46.996 instalaciones.⁴ El mantenedor de LiteLLM eliminó su cuenta de GitHub, rotó todas las claves y contrató a Mandiant.⁵

El escáner de seguridad escaneó. El pipeline de compilación compiló. El gestor de paquetes instaló. Cada componente hizo exactamente lo que se confiaba que hiciera.

TL;DR

• La cadena: TeamPCP comprometió Trivy (escáner de seguridad) el 19 de marzo mediante secuestro de etiquetas de Actions de GitHub, luego comprometió LiteLLM (proxy de IA) el 24 de marzo usando un token de PyPI robado de un entorno CI infectado por Trivy. 46.996 descargas en 46 minutos.⁴
• La técnica: La versión 1.82.8 abusa del mecanismo .pth de Python para ejecutar un ladrón de credenciales en cada invocación de python3 en el sistema infectado, sin importar LiteLLM.³
• El radio de impacto: 2.337 paquetes de PyPI dependen de LiteLLM. El 88% tenía especificaciones de versión que permitían las versiones comprometidas. Impacto aguas abajo confirmado en Google ADK, Stanford DSPy, MLflow, Guardrails AI y Cisco AI Defense SDK.⁴
• La campaña: TeamPCP golpeó cinco ecosistemas en una semana: Actions de GitHub, Docker Hub, npm (CanisterWorm, más de 28 paquetes), Open VSX (Checkmarx KICS) y PyPI (LiteLLM).⁶
• La lección estructural: Cada eslabón de la cadena operó dentro del alcance otorgado. Componer esas operaciones autorizadas produjo comportamiento no autorizado. El patrón refleja la brecha de composición que habilita la exfiltración silenciosa a nivel de agente y Clinejection a nivel CI/CD. Los ataques a la cadena de suministro son ataques de composición.
• Qué puedes hacer: Fijar dependencias a referencias inmutables. Aislar las credenciales de publicación de los runners CI. Monitorizar las solicitudes de red salientes a nivel de sistema operativo. Tratar pip install como ejecución de código, porque lo es.

Un escáner de seguridad entra en tu pipeline de compilación

El ataque comenzó con una configuración incorrecta en el entorno de Actions de GitHub de Trivy a finales de febrero de 2026. Un atacante explotó un flujo de trabajo pull_request_target vulnerable para exfiltrar el token de acceso personal aqua-bot de Aqua Security. Aqua rotó algunas credenciales el 1 de marzo, pero pasó por alto otras. TeamPCP retuvo tokens válidos.¹

El 19 de marzo, usaron esos tokens para hacer force-push de 76 de 77 etiquetas de versión en el repositorio trivy-action y de las 7 etiquetas en setup-trivy, redirigiendo cada referencia de etiqueta mutable a commits maliciosos. También activaron la automatización de release para publicar un binario malicioso de Trivy como v0.69.4.¹

La carga útil era un ladrón de credenciales que volcaba la memoria del proceso Runner.Worker, recolectaba claves SSH, credenciales cloud, secretos de Kubernetes, configuraciones de Docker, credenciales Git y archivos .env. Cifraba el botín con AES-256 y una clave RSA de 4096 bits, luego exfiltraba el archivo a servidores controlados por el atacante. El código malicioso se ejecutaba junto a la funcionalidad legítima de Trivy. Los escaneos tuvieron éxito. El escáner aún reportaba vulnerabilidades. El ladrón corría en segundo plano.⁷

Entre el 19 y el 23 de marzo, los atacantes también envenenaron imágenes de Docker Hub bajo las etiquetas trivy:0.69.4, trivy:0.69.5, trivy:0.69.6 y trivy:latest. CrowdStrike, Microsoft, Wiz y Palo Alto publicaron análisis técnicos en cuestión de días.⁷⁸⁹

La ironía es estructural: las organizaciones más conscientes de la seguridad fueron las más expuestas. Si ejecutabas Trivy en CI porque te importa el escaneo de vulnerabilidades, tu pipeline de compilación era el que recolectaba credenciales.

Del escáner al ladrón al proxy de IA

El pipeline CI de LiteLLM ejecutaba Trivy. Específicamente, ci_cd/security_scans.sh descargaba Trivy mediante apt desde el repositorio de Aqua sin fijar la versión.¹⁰ Durante la ventana de compromiso, una ejecución CI descargó el binario envenenado de Trivy, que recolectó el PYPI_PUBLISH_PASSWORD del entorno de Actions de GitHub.

El 23 de marzo, el atacante registró litellm.cloud. El 24 de marzo a las 10:39 UTC, publicó litellm==1.82.7 en PyPI usando las credenciales robadas. La versión 1.82.8 siguió a las 10:52 UTC.⁴

Las dos versiones usaron técnicas de ataque diferentes. La versión 1.82.7 incrustó la carga útil en proxy_server.py, que se activa al hacer import litellm.proxy. La versión 1.82.8 dejó un archivo .pth en site-packages/, que se activa en cualquier arranque del intérprete de Python. El mecanismo .pth es una función legítima de Python para configuración de rutas. El site.py de Python ejecuta automáticamente cualquier archivo que termine en .pth que encuentre en site-packages/ durante la inicialización del intérprete. La mayoría de los desarrolladores de Python no saben que esta función existe.³

La carga útil en ambas versiones recolectaba variables de entorno, claves SSH, credenciales de AWS/GCP/Azure, configuraciones de Kubernetes, contraseñas de base de datos, carteras de criptomonedas y secretos CI/CD. Cifraba la colección con AES-256-CBC usando una clave de sesión aleatoria, envolvía la clave de sesión con una clave pública RSA de 4096 bits codificada en duro y exfiltraba el archivo mediante HTTPS POST. Solo el atacante puede descifrar los datos robados.³

Un bug en el malware de la 1.82.8 lo delató. El archivo .pth genera un proceso hijo de Python, que vuelve a activar el archivo .pth, creando una bomba fork exponencial. Andrej Karpathy señaló el bug en X. Sin la bomba fork, el ladrón habría corrido silenciosamente en cada invocación de Python en cada sistema infectado, potencialmente durante semanas antes de que alguien lo notara.⁴

PyPI puso en cuarentena ambas versiones a las 11:25 UTC – 46 minutos de exposición, 46.996 descargas.⁴

El radio de impacto

Los desarrolladores descargan LiteLLM aproximadamente 3,4 millones de veces al día. Wiz reporta que se ejecuta en el 36% de los entornos cloud.² La ventana de exposición de 46 minutos fue suficiente.

FutureSearch analizó los registros de descargas de BigQuery de PyPI y encontró que durante la ventana del ataque, pip descargaba la versión 1.82.8 a 6 veces la tasa de cualquier versión segura. Las descargas se inclinaban fuertemente hacia pip (que resuelve a la última versión) frente a uv (que usa archivos de bloqueo). De las 46.996 descargas, 23.142 fueron instalaciones pip de la v1.82.8, cada una de las cuales ejecutó la carga útil durante la instalación misma porque el archivo .pth se activa durante el propio proceso Python de pip.⁴

2.337 paquetes en PyPI dependen de LiteLLM. El 88% (2.054 paquetes) tenía especificaciones de versión que permitían instalar las versiones comprometidas. La exposición aguas abajo incluye:⁴

Los usuarios de LiteLLM Cloud y del proxy Docker no se vieron afectados porque sus dependencias estaban fijadas en requirements.txt. La distinción entre “fijado” y “no fijado” fue la diferencia entre estar comprometido y estar a salvo.⁵

Cinco ecosistemas en una semana

TeamPCP no se detuvo en PyPI. La campaña golpeó cinco ecosistemas de paquetes en rápida sucesión:⁶

Actions de GitHub (19 de marzo): 76 etiquetas de trivy-action y las 7 etiquetas de setup-trivy secuestradas. Se publicaron binarios maliciosos de Trivy v0.69.4 a v0.69.6.

Docker Hub (19-22 de marzo): Imágenes maliciosas de Trivy subidas como aquasec/trivy:latest y etiquetas específicas de versión. Propagadas a mirror.gcr.io.

Open VSX (23 de marzo): TeamPCP comprometió la Action de GitHub de Checkmarx KICS, secuestrando 35 etiquetas entre las 12:58 y las 16:50 UTC.²

npm (23-24 de marzo): CanisterWorm, un gusano autopropagante, desplegado en más de 28 paquetes npm.

PyPI (24 de marzo): Las versiones 1.82.7 y 1.82.8 de LiteLLM publicadas con cargas útiles de robo de credenciales.

Cada compromiso de ecosistema usó credenciales recolectadas del anterior. La campaña fue un grafo dirigido de explotación de confianza, donde cada nodo comprometido entregaba las llaves del siguiente.

Los ataques a la cadena de suministro son ataques de composición

El patrón estructural en la campaña de TeamPCP es el mismo que describí en el contexto de la seguridad de agentes y la exfiltración silenciosa: componentes autorizados individualmente que se componen en comportamiento no autorizado.

Trivy tenía permiso para ejecutarse en CI. CI mantenía credenciales de publicación por diseño. El gestor de paquetes instalaba paquetes bajo demanda. Cada archivo .pth configuraba rutas de Python como estaba previsto. Cada eslabón de la cadena operó dentro de su alcance definido. Componer esas operaciones legítimas produjo exfiltración de credenciales a escala.

El ataque Clinejection demostró el mismo patrón a nivel CI/CD: un título de issue inyectó texto adversarial en el pipeline automatizado de Cline, que ejecutó un script npm preinstall, que envenenó la caché de compilación, que contaminó artefactos entre flujos de trabajo. Cada paso mantenía su propia autorización.¹¹

El benchmark MCPTox demostró el mismo patrón a nivel de agente: instrucciones maliciosas incrustadas en descripciones de herramientas redirigen a los agentes para exfiltrar credenciales usando herramientas legítimas ya presentes en el servidor. El agente nunca ejecuta la herramienta envenenada en sí. Lee la descripción envenenada y usa sus propias herramientas legítimas para llevar a cabo el ataque.¹²

La exfiltración silenciosa lo demuestra a nivel de tiempo de ejecución: instrucciones adversariales en metadatos de páginas web inducen a un agente a exfiltrar contexto de ejecución mediante una solicitud HTTP saliente que el agente ya tiene permiso para hacer.¹³

La superficie de ataque no es un único componente vulnerable. La superficie de ataque es la composición de componentes confiables. Asegurar eslabones individuales no asegura la cadena. Trivy por sí solo no era la vulnerabilidad. LiteLLM por sí solo no era la vulnerabilidad. La relación de confianza entre ellos – mediada por etiquetas de versión mutables y dependencias sin fijar – era la vulnerabilidad.

Lo que realmente ayuda

Las defensas que habrían detenido cada etapa de este ataque son aburridas. También son las que la mayoría de las organizaciones se saltan.

Fija a referencias inmutables. LiteLLM descargaba Trivy mediante apt sin fijar la versión. Si security_scans.sh hubiera fijado una versión específica o un SHA de commit, el binario envenenado v0.69.4 nunca se habría ejecutado. Las Actions de GitHub deberían referenciar SHAs de commit, no etiquetas mutables. La diferencia entre uses: aquasecurity/[email protected] (comprometido) y uses: aquasecurity/trivy-action@57a97c7 (seguro) es la diferencia entre perder tus credenciales de publicación o no.¹

Aísla las credenciales de publicación de los runners CI. El PYPI_PUBLISH_PASSWORD estaba expuesto como variable de entorno en el runner de Actions de GitHub donde se ejecutaba Trivy. Si el equipo hubiera aislado las credenciales de publicación en un flujo de trabajo separado sin dependencias de actions de terceros, el compromiso de Trivy no habría dado acceso a PyPI. Los Trusted Publishers de PyPI (OIDC) eliminan por completo los tokens almacenados.⁵

Monitoriza las solicitudes de red salientes. El ladrón de credenciales exfiltraba datos mediante HTTPS POST a models.litellm.cloud, un dominio que los atacantes registraron 24 horas antes del ataque. La monitorización de egress que marque solicitudes a dominios recién registrados habría capturado esto. Mi propio sistema de hooks bloquea solicitudes salientes a dominios que no estén en una lista de permitidos, el mismo patrón que habría interceptado esta exfiltración.¹⁴

Aprendí la misma lección en producción por las malas. Una ruta de purga de caché de Cloudflare confiable disparó una llamada API totalmente autorizada y aun así produjo el resultado incorrecto porque los guardrails circundantes eran demasiado laxos. Esa falla me llevó a añadir aprobaciones de acciones destructivas y hooks de preflight alrededor de operaciones de alto impacto, no solo listas de dominios permitidos.

Trata pip install como ejecución de código. Un archivo .pth en site-packages/ se ejecuta en cada arranque de Python. No hay opción de exclusión. No hay sandbox. Si ejecutas pip install en un entorno CI con acceso a credenciales, otorgas ejecución de código arbitrario a cada dependencia transitiva del paquete. La mitigación: ejecuta pip install en un entorno sin acceso a credenciales, luego copia los paquetes instalados al entorno que los necesita.

Usa archivos de bloqueo. El análisis de FutureSearch mostró que los usuarios de uv (que dependen de archivos de bloqueo) rara vez descargaban la versión comprometida, mientras que los usuarios de pip (que resuelven a la última versión) la descargaban constantemente. Los archivos de bloqueo no son una defensa completa, pero previenen la exposición más común: una restricción de versión >= sin fijar que se actualiza silenciosamente a una release comprometida.⁴

La implicación incómoda

La campaña de TeamPCP demuestra que la seguridad de la cadena de suministro no es una preocupación secundaria que va detrás de la seguridad de aplicaciones, la seguridad de red y la protección de endpoints. Para las organizaciones que ejecutan agentes de IA con acceso a herramientas, la cadena de suministro es la superficie de ataque primaria.

Un agente de IA que llama a pip install en un entorno CI, descarga URLs o instala servidores MCP compone relaciones de confianza en tiempo de ejecución. Cada operación lleva su propia autorización. La composición puede no tenerla. La paradoja de desplegar y defender acelera esto: las organizaciones despliegan agentes más rápido de lo que auditan las cadenas de confianza que esos agentes componen.

El bug de la bomba fork en LiteLLM 1.82.8 es la única razón por la que alguien detectó este ataque rápidamente. Sin ese error de implementación, el ladrón de credenciales habría corrido silenciosamente en cada invocación de Python en cada sistema infectado. 46.996 instalaciones en 46 minutos. El 36% de los entornos cloud. 2.337 paquetes aguas abajo. El atacante cometió un error. La próxima vez, puede que no lo haga.

Actualización — 31 de marzo de 2026: un vector diferente, el mismo resultado

Seis días después de que este post saliera en vivo, npm tuvo su siguiente incidente. El 31 de marzo, el mantenedor de axios Jason Saayman reveló que su computadora personal había sido comprometida mediante una campaña dirigida de ingeniería social seguida de malware troyano de acceso remoto. Los atacantes usaron sus credenciales de npm para publicar axios 1.14.1 y 0.30.4, ambos inyectaron una nueva dependencia llamada [email protected] que instalaba un RAT multiplataforma en macOS, Windows y Linux. Las versiones maliciosas permanecieron activas durante aproximadamente tres horas antes de que colaboradores de la comunidad triaran el incidente y npm las retirara.¹⁶

El vector de axios fue diferente al de TeamPCP. No hubo runner CI comprometido, ni credenciales recolectadas de un escáner de seguridad de terceros, ni gusano multi-ecosistema. La campaña contra Saayman corrió durante aproximadamente dos semanas antes de la publicación, y el compromiso viajó a través del dispositivo personal del mantenedor directamente al pipeline de publicación de npm. La remediación requirió un borrado completo de todos sus dispositivos y la rotación de cada credencial en cada plataforma que hubiera usado, personal o de otro tipo. La infraestructura C2 era sfrclak[.]com en 142.11.206.73:8000.¹⁶

La lección estructural es la misma. La cadena de confianza ahora incluye la atención y vigilancia del mantenedor como eslabones, porque operaciones individualmente legítimas se componen en comportamiento no autorizado cuando un adversario manipula a un humano en la cadena. Las mitigaciones que el equipo de axios está adoptando (publicación OIDC, releases inmutables, aislamiento de dispositivos)¹⁶ abordan la misma brecha de composición que Trivy-a-LiteLLM expuso: credenciales de publicación almacenadas donde pueden ser alcanzadas por adversarios que ya comprometieron algo adyacente a ellas.

Tres horas. 46 minutos. Estas son las ventanas en las que operan ahora los ataques modernos a la cadena de suministro. La fijación y los archivos de bloqueo siguen siendo la defensa primaria: los usuarios de axios que tenían instalaciones recientes fuera de la ventana 00:21-03:15 UTC del 31 de marzo no se vieron afectados.¹⁶

Preguntas frecuentes

¿Cómo verifico si me vi afectado?

Busca en tus registros CI y entornos locales versiones 1.82.7 o 1.82.8 de LiteLLM instaladas entre las 10:39 y las 11:25 UTC del 24 de marzo de 2026. Si encuentras cualquiera de las dos versiones, rota cada credencial que el sistema pudiera alcanzar – variables de entorno, claves SSH, archivos de configuración. Guía oficial de LiteLLM: trata cualquier sistema que ejecutara las versiones comprometidas como totalmente comprometido.⁵

¿Qué identificador de aviso debo rastrear?

Rastrea PYSEC-2026-2 en OSV y la base de datos de avisos de PyPA. OSV también asigna el alias MAL-2026-2144 al incidente. Al 25 de marzo de 2026, la página pública del aviso de OSV no lista un alias CVE para las releases maliciosas de LiteLLM, por lo que los equipos de respuesta a incidentes deben guiarse primero por las versiones afectadas, la ventana de instalación y PYSEC-2026-2.¹⁵

¿Los usuarios de LiteLLM Cloud o del proxy Docker se vieron afectados?

No. LiteLLM Cloud y la imagen oficial del proxy Docker fijan las dependencias en requirements.txt, previniendo la resolución automática a las versiones comprometidas. Solo los usuarios que instalaron LiteLLM mediante pip install litellm (sin fijar) durante la ventana de 46 minutos se vieron afectados.⁵

¿Qué es un archivo .pth y por qué es peligroso?

Un archivo .pth es una función de Python para configurar rutas de búsqueda de módulos. El módulo site.py de Python lee y ejecuta cualquier archivo que termine en .pth en el directorio site-packages/ durante la inicialización del intérprete. La ejecución ocurre antes de cualquier sentencia import, antes de cualquier código de aplicación y antes de cualquier sandbox a nivel de Python. La biblioteca estándar de Python documenta el mecanismo, pero pocos desarrolladores de aplicaciones saben que existe. Es una función legítima reutilizada como vector de ataque.³

¿Está esto relacionado con el ataque a la cadena de suministro de Trivy?

Sí. El compromiso de LiteLLM fue una consecuencia directa del compromiso de Trivy. TeamPCP comprometió las Actions de GitHub de Trivy el 19 de marzo, lo que recolectó credenciales CI/CD de organizaciones que ejecutaban Trivy en sus pipelines de compilación. Una de esas credenciales era el token de publicación de PyPI de LiteLLM. El atacante usó ese token para publicar las versiones maliciosas de LiteLLM cinco días después.¹⁰

¿Qué es TeamPCP?

TeamPCP (también rastreado como DeadCatx3, PCPcat, ShellForce, CipherForce) es un grupo de amenazas que condujo una campaña multi-ecosistema de cadena de suministro en marzo de 2026, comprometiendo paquetes en Actions de GitHub, Docker Hub, npm, Open VSX y PyPI. El grupo usó recolección de credenciales, secuestro de etiquetas y técnicas de gusano autopropagante en cinco ecosistemas de paquetes en aproximadamente una semana.⁶

¿Cómo se relaciona esto con la seguridad de agentes de IA?

Los agentes de IA que instalan paquetes, descargan URLs o se conectan a servidores MCP componen relaciones de confianza en tiempo de ejecución. Cada operación lleva su propia concesión de permisos. La composición de esas operaciones puede producir comportamiento no autorizado, como lo demuestran la exfiltración silenciosa (nivel de agente), Clinejection (nivel CI/CD) y este ataque (nivel de cadena de suministro). La monitorización conductual en tiempo de ejecución, las listas de dominios permitidos y el aislamiento de credenciales abordan la brecha de composición en diferentes capas del stack.¹⁴

Fuentes