Todas las notas

Tokens de Vercel en CI: qué rotar tras Trivy y LiteLLM

6 min de lecturaRedactado con IA, editado y aprobado por Mat Caniglia

Si un job con tokens de Vercel corrió Trivy o LiteLLM comprometidos, rotalos esta semana y pasá la nube a OIDC donde se pueda.

Si tu CI bajó trivy-action entre las 17:43 del 19 y las 05:40 UTC del 20 de marzo (horas aproximadas), setup-trivy comprometido, Trivy v0.69.4, las imágenes v0.69.5 o v0.69.6, o litellm 1.82.7 o 1.82.8, considerá expuestos tus tokens de Vercel, deploy hooks y secretos de bypass. Rotalos esta semana y pasá la nube a OIDC donde se pueda.

¿Qué pasó con Trivy y LiteLLM?

Un atacante usó credenciales comprometidas para publicar releases y tags maliciosos de Trivy, y LiteLLM cree que ese incidente terminó en sus propios paquetes envenenados en PyPI. El advisory GHSA-69fq-xp46-6x23 de Trivy, publicado el 21 de marzo de 2026, cuenta que el 19 de marzo de 2026 salió un release malicioso de Trivy v0.69.4. Ese mismo día el atacante reescribió con force-push 76 de los 77 tags de versión de aquasecurity/trivy-action, que pasaron a apuntar a malware que roba credenciales. También reemplazó los 7 tags de aquasecurity/setup-trivy por commits maliciosos.

El 22 de marzo de 2026 volvieron a usar credenciales comprometidas para publicar en DockerHub las imágenes maliciosas de Trivy v0.69.5 y v0.69.6. El advisory marca como afectados trivy-action por debajo de 0.35.0 y setup-trivy por debajo de 0.2.6. Las versiones corregidas son 0.35.0 y 0.2.6. Para el binario de Trivy, la afectada es 0.69.4 y la corregida figura como 0.69.3.

Los mantenedores de LiteLLM dicen que litellm 1.82.7 y 1.82.8 estuvieron publicados en PyPI el 24 de marzo de 2026 desde las 10:39 UTC, durante unos 40 minutos, hasta que PyPI los puso en cuarentena. Su guía de exposición abarca una ventana más larga. Puede estar afectado quien instaló o actualizó con pip ese día entre las 10:39 y las 16:00 UTC. También las imágenes Docker armadas en esa ventana con un install sin versión fija, y los proyectos que traían LiteLLM como dependencia transitiva sin pinear.

Según LiteLLM, las versiones comprometidas parecen haber incluido un ladrón de credenciales. Estaba pensado para buscar variables de entorno, claves SSH, credenciales de AWS, GCP y Azure, tokens de Kubernetes y contraseñas de bases de datos. También estaba pensado para cifrar esos datos y mandarlos con un POST a models.litellm.cloud, un dominio que LiteLLM aclara que no es oficial.

LiteLLM mantiene la investigación como activa. Hoy su lectura es que pudo haberse comprometido la cuenta de PyPI de un mantenedor. Creen que el origen fue Trivy, que usaban en su workflow de escaneo de seguridad en CI/CD, y que credenciales robadas habrían llegado a su pipeline de publicación. La evidencia inicial indica que el atacante esquivó los workflows oficiales y subió los paquetes directo a PyPI.

LiteLLM considera no afectados a quienes usan la imagen Docker oficial de LiteLLM Proxy, a los usuarios de LiteLLM Cloud y a quienes estaban en v1.82.6 o anterior y no actualizaron durante la ventana. La v1.83.0, limpia, salió de un pipeline nuevo con entornos aislados, controles de seguridad más fuertes y una separación de releases más segura.

¿Por qué te importa si tenés tokens de Vercel en el CI?

Te importa porque un token de Vercel que llega al job de deploy como variable de entorno es justo el tipo de secreto que buscaba el stealer de LiteLLM. El advisory de Trivy describe los tags reescritos de trivy-action como malware que roba credenciales. La lectura prudente es dar por expuesto cada secreto de un job afectado. Si un paso afectado corrió en el mismo job que un deploy, asumí que pudo leer ese token.

Un secreto copiado antes de que se arreglara el tag sigue siendo válido hasta que lo rotes.

Quedan expuestos los equipos cuyos pipelines bajaron alguna de las versiones listadas, directa o transitivamente, mientras ese mismo job tenía credenciales de Vercel, de la nube o de publicación.

¿Qué tokens de Vercel siguen siendo estáticos en tu CI?

Toda credencial de Vercel que tu pipeline lee de un secreto guardado es estática. Vercel documenta cómo crear un deploy hook y cómo funcionan los permisos de Protection Bypass for Automation, así que los dos van al inventario al lado de los tokens de cuenta.

Credencial Dónde buscarla Esta semana
Cualquier token de Vercel guardado para deploys con la CLI Secretos de repositorio, organización y environment en el CI Reemplazalo si algún job que podía leerlo corrió una versión afectada
Deploy hook Webhooks del CMS, jobs programados, configuración de integraciones Tratalo como secreto. Recreá todo hook que haya aparecido en logs o variables del CI
Secreto de Protection Bypass for Automation Jobs de tests end-to-end y chequeos de previews Fijate en la documentación de bypass de Vercel cómo reemplazarlo y revisá quién puede leerlo
Claves de nube en variables de build (AWS, GCP, Azure) Variables de entorno del build y secretos del CI Rotalas y después pasalas a federación OIDC
Tokens de publicación de paquetes (PyPI) Workflows de release Revocá el token guardado y pasá la publicación a OIDC

¿Qué credenciales conviene pasar primero a OIDC?

Primero van las claves de los proveedores de nube y los tokens de publicación de paquetes, porque GitHub Actions ya documenta OIDC para esos flujos. Su documentación tiene guías de OIDC para AWS, Azure, Google Cloud Platform, HashiCorp Vault y PyPI. LiteLLM dice que la evidencia inicial sugiere que el atacante salteó los workflows oficiales y subió directo a PyPI. Un equipo que publica paquetes con un token de PyPI guardado tiene que fijarse si OIDC lo puede reemplazar.

Para los deploys de Vercel en sí, leé lo que Vercel documenta hoy para cada forma de deploy antes de planificar una migración. Si alguna todavía necesita un token guardado, metelo en un environment protegido, limitá qué workflows lo pueden leer y asignale un dueño y una fecha de rotación.

Pineá también las actions. El atacante de Trivy reescribió tags existentes, así que un workflow que referenciaba un tag recibió el código malicioso sin ningún cambio en su propio repo. La documentación de GitHub incluye una guía para fijar las dependencias de los workflows, y por ahí conviene arrancar.

Qué revisar esta semana

Lunes. Buscá en cada archivo de workflow y en cada log de build desde el 19 de marzo trivy-action, setup-trivy, Trivy v0.69.4, las imágenes v0.69.5 y v0.69.6, y litellm 1.82.7 o 1.82.8, incluidas las instalaciones transitivas. Buscá models.litellm.cloud en los logs de egress y de DNS.

Martes. Para cada job que aparezca, listá todos los secretos que podía leer. Rotá primero los tokens de Vercel, deploy hooks, secretos de bypass y claves de nube de esa lista. Pasate de las versiones afectadas a Trivy 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6 y LiteLLM v1.83.0.

Miércoles. Pineá las actions de terceros a SHAs de commit y fijá las dependencias de Python en las imágenes de build. Así un tag movido o un install sin versión no cambian lo que corre.

Jueves y viernes. Pasá a OIDC una credencial de nube y un token de publicación. Anotá cada token de Vercel que quede estático, con su dueño y su próxima fecha de rotación, y revisá esa lista todos los meses.

Fuentes