Se um runner puxou trivy-action entre cerca de 17:43 UTC de 19/3 e 05:40 UTC de 20/3/2026, tags comprometidas do setup-trivy, Trivy v0.69.4, as imagens v0.69.5 ou v0.69.6, ou litellm 1.82.7 ou 1.82.8, trate como exposto todo token da Vercel, deploy hook e segredo de bypass do CI. Rotacione nesta semana e acesse a nuvem via OIDC onde houver suporte.
O que aconteceu no ataque ao Trivy e ao LiteLLM?
Invasores usaram credenciais comprometidas para publicar releases e tags maliciosas do Trivy. O LiteLLM acredita que esse ataque levou aos pacotes envenenados que ele teve no PyPI. O advisory GHSA-69fq-xp46-6x23, publicado em 21 de março de 2026, conta que em 19 de março um invasor publicou um release malicioso do Trivy v0.69.4.
No mesmo dia, o invasor fez force-push em 76 das 77 tags de versão do aquasecurity/trivy-action, apontando para malware que rouba credenciais. Também trocou as 7 tags do aquasecurity/setup-trivy por commits maliciosos. Pelo advisory, a janela do trivy-action durou cerca de 12 horas. A do binário v0.69.4 foi de 18:22 até cerca de 21:42 UTC, umas 3 horas.
Em 22 de março, credenciais comprometidas foram usadas de novo para publicar as imagens maliciosas v0.69.5 e v0.69.6 do Trivy no DockerHub. O advisory lista como afetados o trivy-action abaixo de 0.35.0 e o setup-trivy abaixo de 0.2.6. As versões corrigidas são 0.35.0 e 0.2.6. No binário, a afetada é a 0.69.4 e a corrigida é a 0.69.3.
Do lado do LiteLLM, os mantenedores dizem que o litellm 1.82.7 e o 1.82.8 ficaram no PyPI em 24 de março de 2026. Ficaram no ar a partir das 10:39 UTC por cerca de 40 minutos, até a quarentena do PyPI. A orientação de exposição cobre uma janela maior. Pode estar afetado quem instalou ou atualizou via pip nesse dia entre 10:39 e 16:00 UTC. Também entram imagens Docker construídas na janela com instalação sem versão fixa. E projetos que puxaram o LiteLLM como dependência transitiva sem pin.
Segundo o LiteLLM, as versões comprometidas parecem ter incluído um ladrão de credenciais. Ele foi feito para vasculhar variáveis de ambiente, chaves SSH, credenciais de AWS, GCP e Azure, tokens de Kubernetes e senhas de banco. O código também previa criptografar os dados e enviá-los num POST para models.litellm.cloud, domínio que não é oficial do LiteLLM.
O LiteLLM marcou a investigação como ativa. A leitura atual é que a conta de um mantenedor no PyPI pode ter sido comprometida. Credenciais roubadas no caso Trivy teriam chegado ao pipeline de publicação pelo Trivy usado no workflow de scan de segurança do CI/CD. E as evidências iniciais indicam que o invasor driblou os workflows oficiais para subir os pacotes direto no PyPI.
O LiteLLM diz que não foram afetados os usuários da imagem Docker oficial do LiteLLM Proxy e os do LiteLLM Cloud. Também ficou de fora quem estava na v1.82.6 ou anterior e não atualizou na janela. A v1.83.0, limpa, saiu de um pipeline novo com ambientes isolados, gates de segurança mais fortes e separação de release mais segura.
Por que isso afeta os tokens da Vercel no CI?
Afeta porque um token da Vercel passado ao job de deploy como variável de ambiente é o tipo de segredo que o ladrão do LiteLLM procurava. O advisory do Trivy chama as tags reescritas do trivy-action de malware que rouba credenciais. A leitura prudente é tratar como exposto todo segredo de um job afetado. Se um passo afetado rodou no mesmo job de um deploy, assuma que ele alcançava esse token.
Um segredo copiado antes da correção da tag continua válido até você rotacionar.
Os times afetados são os que tinham pipelines puxando alguma versão listada, direta ou transitivamente, com credenciais da Vercel, de nuvem ou de publicação no mesmo job.
Quais tokens da Vercel no CI ainda são estáticos?
Toda credencial da Vercel que o pipeline lê de um segredo guardado é estática. A documentação da Vercel explica como criar um deploy hook e como funcionam as permissões do Protection Bypass for Automation. Por isso os dois entram no inventário ao lado dos tokens de conta.
| Credencial | Onde procurar | Nesta semana |
|---|---|---|
| Token da Vercel guardado para deploy via CLI | Segredos de repositório, organização e environment no CI | Troque se algum job que podia lê-lo rodou uma versão afetada |
| Deploy hook | Webhooks de CMS, jobs agendados, configurações de integração | Trate como segredo. Recrie todo hook que apareceu em log ou variável de CI |
| Segredo do Protection Bypass for Automation | Jobs de teste end-to-end e checks de preview | Veja na doc de bypass da Vercel como substituir e revise quem pode lê-lo |
| Chaves de nuvem em variáveis de build (AWS, GCP, Azure) | Variáveis de ambiente do build e segredos do CI | Rotacione e depois migre para federação OIDC |
| Tokens de publicação de pacote (PyPI) | Workflows de release | Revogue o token guardado e leve a publicação para OIDC |
Quais credenciais migrar para OIDC primeiro?
Chaves de provedor de nuvem e tokens de publicação de pacote vêm primeiro, porque o GitHub Actions já documenta OIDC para esses caminhos. A documentação traz guias de OIDC para AWS, Azure, Google Cloud Platform, HashiCorp Vault e PyPI. O LiteLLM diz que as evidências iniciais apontam um invasor que contornou os workflows oficiais e subiu direto no PyPI. Um time que publica pacotes com token do PyPI guardado deveria checar se o caminho OIDC substitui esse token.
Para o deploy na Vercel em si, leia o que a Vercel documenta hoje para cada caminho de deploy antes de planejar a migração. Se um caminho ainda exige token guardado, mantenha esse token num environment protegido. Limite quais workflows podem lê-lo e defina um dono e uma data de rotação.
Fixe também as actions. O invasor do Trivy reescreveu tags que já existiam. Assim, um workflow que apontava para uma tag recebeu o código malicioso sem nenhuma mudança no próprio repositório. A documentação do GitHub tem um guia para travar dependências de workflow, e ele é o ponto de partida.
O que verificar nesta semana
Segunda. Busque em todo arquivo de workflow e log de build desde 19 de março por trivy-action, setup-trivy, Trivy v0.69.4, as imagens v0.69.5 e v0.69.6 e litellm 1.82.7 ou 1.82.8. Inclua as instalações transitivas. Procure models.litellm.cloud nos logs de egress e de DNS.
Terça. Para cada job que bater, liste todos os segredos que ele podia ler. Comece rotacionando os tokens da Vercel, deploy hooks, segredos de bypass e chaves de nuvem dessa lista. Saia das versões afetadas para Trivy 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6 e LiteLLM v1.83.0.
Quarta. Fixe as actions de terceiros por SHA de commit e fixe as dependências Python nas imagens de build. Assim, uma tag movida ou um install sem pin não muda o que roda.
Quinta e sexta. Migre uma credencial de nuvem e um token de publicação para OIDC. Anote todo token da Vercel que continuar estático, com dono e próxima data de rotação. Revise essa lista todo mês.
Fontes
- vercel.com/docs/oidc, consultada em 26 de outubro de 2026.
- vercel.com/docs/oidc/reference, consultada em 26 de outubro de 2026.
- vercel.com/docs/accounts/access-tokens, consultada em 26 de outubro de 2026.
- vercel.com/docs/deploy-hooks, consultada em 26 de outubro de 2026.
- vercel.com/docs/deployment-protection/methods-to-bypass-deployment-…, consultada em 26 de outubro de 2026.
- vercel.com/changelog/turborepo-and-remote-cache-now-support-openid-…, consultada em 26 de outubro de 2026.