Voltar
A cadeia de ataque por trás da release v1.107.0 do LiteLLM

LiteLLM detalha cadeia de ataque por trás da release v1.107.0, iniciada por chave de admin commitada e nunca revogada

Aprofundamento CEVIU

Aprofundamento

A LiteLLM publicou a cadeia de ataque completa por trás da release v1.107.0 e a trata como a fonte canônica, porque atualizações feitas durante a investigação continham suposições que depois se mostraram imprecisas. A origem foi uma chave de admin da Agent Platform interna, commitada em 27 de maio de 2026 no repositório público LiteLLM-Labs/lite-harness. O arquivo foi apagado cerca de três horas depois, mas o commit original ficou no histórico público até 22 de outubro. Por falha humana, a chave nunca foi revogada e seguia válida mais de quatro meses depois.

Em 10 de outubro, o atacante usou a chave para extrair da plataforma o token OAuth da GitHub CLI de um owner da organização. Esse token não tem escopo, passa pela verificação de 2FA uma vez e não cai nos fluxos de reautenticação para ações sensíveis. Com ele, o atacante empurrou branches temporárias que rodaram workflows de exfiltração de segredos de CI e obteve tokens equivalentes de dois maintainers. Em 21 de outubro, alterou o workflow de release para aceitar um repositório de origem arbitrário (source_owner), contornou a proteção de branch da main com o token do owner, mandou o build para o fork Berri-AI/litellm e aprovou a release com o token de outro maintainer. Os wheels e imagens saíram por volta de 11:40 UTC, e o pacote no PyPI foi congelado às 13:23 UTC e as imagens Docker removidas às 14:20 UTC. Depois, o atacante apagou os registros de execução e reescreveu o histórico da main, mas os commits continuam recuperáveis por SHA e o log de auditoria registrou cada sobrescrita. A empresa também afirma que a exigência de aprovação por conta travada em dispositivo físico havia sido afrouxada na semana anterior para acelerar releases e backports.

O que mudou

Em 22 de outubro de 2026, o CEVIU noticiou "Release v1.107.0 do LiteLLM, de 21 de outubro de 2026, foi comprometida e já está contida", com o aviso inicial sobre o pacote malicioso que ficou cerca de duas horas no ar. Em 23 de outubro de 2026, a matéria "Ataque à cadeia de suprimentos do LiteLLM rouba senhas e segredos" detalhou o payload, com infostealer e RAT. Agora a lacuna é a origem: a investigação da própria LiteLLM explica como o atacante chegou à publicação, e corrige a hipótese inicial de que os tokens saíram de logs de um deployment interno. Foi um token de um serviço diferente, a Agent Platform.

Por que isso importa

Para quem opera pipelines de release, a lição é que um único segredo esquecido abriu caminho até o controle da organização. A leitura editorial: revogar é parte obrigatória de remover um segredo commitado, e apagar o commit não resolve. Tokens unscoped da CLI em automações dão poder de owner a quem os roubar. Alertas para sobrescrita de proteção de branch e para execuções de workflow apagadas teriam exposto etapas do ataque, já que o log de auditoria registrou tudo.

Linha do tempo

  1. CEVIU noticia a release v1.107.0 comprometida e já contida.

  2. CEVIU detalha o ataque à cadeia de suprimentos com infostealer e RAT.

  3. LiteLLM publica a cadeia de ataque completa, iniciada por chave de admin commitada e nunca revogada.

Perguntas frequentes

Como o ataque ao LiteLLM começou?

Com uma chave de admin da Agent Platform interna, commitada em um repositório público em 27 de maio de 2026. O arquivo foi removido horas depois, mas a chave nunca foi revogada. Em 10 de outubro, o atacante a usou para extrair um token da GitHub CLI de um owner da organização.

Por que o token da GitHub CLI foi tão perigoso?

Porque esses tokens não têm escopo, são emitidos após o 2FA e não passam pela reautenticação exigida em ações sensíveis. Com o token de um owner, o atacante passou a ter capacidade de owner sobre a organização, inclusive para sobrescrever a proteção de branch.

Quanto tempo as versões maliciosas ficaram no ar?

Cerca de duas horas. Os pacotes foram publicados por volta de 11:40 UTC em 21 de outubro. O PyPI foi congelado às 13:23 UTC e as imagens Docker foram removidas às 14:20 UTC.

O que os times de segurança devem fazer a partir disso?

Revogar toda chave que já foi commitada, mesmo que o arquivo tenha sido apagado. Manter tokens unscoped da CLI fora de automações. Configurar alertas para sobrescritas de proteção de branch e para execuções de workflow apagadas.

Fontes

Avalie este artigo:
Categoria
CEVIU Segurança da Informação
Publicado
09 de novembro de 2026
Editoria
CEVIU Segurança da Informação

Quer receber mais sobre CEVIU Segurança da Informação?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser