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
CEVIU noticia a release v1.107.0 comprometida e já contida.
CEVIU detalha o ataque à cadeia de suprimentos com infostealer e RAT.
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
- docs.litellm.aifonte original
- Categoria
- CEVIU Segurança da Informação
- Publicado
- 09 de novembro de 2026
- Editoria
- CEVIU Segurança da Informação

