Brecha no LiteLLM expõe segredos de mais de 2.500 empresas, incluindo AWS, Cisco e Samsung
Um ataque à cadeia de suprimentos de software que atingiu o LiteLLM — biblioteca open-source amplamente usada como gateway unificado para provedores de IA (OpenAI, Anthropic, gateways de LLM em geral) — resultou no vazamento de um arquivo de 153GB de credenciais roubadas, afetando mais de 2.500 organizações e cerca de 434 mil pipelines de CI/CD em todo o mundo. É considerada a maior brecha de cadeia de suprimentos de IA de 2026.
Como o ataque aconteceu
Segundo pesquisadores, o grupo por trás do ataque comprometeu inicialmente o pipeline de GitHub Actions do projeto Trivy (ferramenta popular de scanning de segurança) e, a partir daí, conseguiu publicar versões maliciosas do pacote LiteLLM (especificamente as versões 1.82.7 e 1.82.8). Essas versões continham um hook de inicialização Python (arquivo .pth) que permitia execução furtiva, persistência e movimento lateral dentro de ambientes de CI/CD — sem que times de desenvolvimento percebessem nada de anormal na instalação da dependência.
Uma vez ativo, o código malicioso extraía silenciosamente segredos de ambientes de integração contínua: credenciais de nuvem (AWS, GCP, Azure), tokens do Kubernetes, tokens de repositório, chaves SSH, credenciais de publicação de pacotes, variáveis de ambiente (.env) e — de forma particularmente crítica para o ecossistema de IA — chaves de provedores de IA e configurações de gateway.
Quem foi afetado
A análise do arquivo vazado (433.909 arquivos, com 118.829 dumps de CI runners atribuídos a 2.488 domínios corporativos) identificou correspondências de alta confiança envolvendo nomes como Nvidia, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales e a London Stock Exchange Group, entre muitas outras.
Por que isso é especialmente grave
Diferente de um vazamento de dados de usuário final, esta brecha comprometeu justamente o tipo de credencial que dá acesso a infraestrutura de produção: chaves de nuvem, tokens de Kubernetes e credenciais de repositório de código. Com esse tipo de acesso, um atacante pode, em tese, ir muito além do roubo inicial — desde publicar pacotes maliciosos em nome da organização comprometida até acessar diretamente cargas de trabalho em produção na nuvem.
O fato de a cadeia de comprometimento ter começado em uma ferramenta de segurança (Trivy) amplamente confiada por times de DevSecOps reforça um ponto incômodo: dependências open-source usadas para proteger pipelines também são, elas mesmas, superfície de ataque.
O que fazer agora
- Verifique se sua organização usou LiteLLM 1.82.7 ou 1.82.8 em qualquer ambiente de CI/CD nos últimos meses — mesmo que já tenha atualizado, credenciais expostas durante a janela de exposição continuam comprometidas até serem rotacionadas.
- Rotacione imediatamente todas as credenciais que possam ter transitado por pipelines de CI/CD afetados: chaves de nuvem, tokens de Kubernetes, chaves SSH, tokens de repositório e chaves de provedores de IA.
- Audite logs de acesso de contas de nuvem e repositórios de código em busca de atividade anômala desde o período em que o pacote malicioso esteve disponível.
- Revise a política de dependências de CI/CD — considere pinning de versões, verificação de assinatura de pacotes e scanning de supply chain como controles obrigatórios, não opcionais.
- Trate ferramentas de segurança como superfície de ataque também — aplique o mesmo rigor de revisão a dependências de scanning/observabilidade que a qualquer outra dependência crítica.
Perguntas frequentes
Minha empresa usa LiteLLM — como sei se fui afetado?
Verifique os logs de instalação de pacotes dos seus pipelines de CI/CD no período em que as versões 1.82.7/1.82.8 estiveram disponíveis, e monitore serviços de threat intelligence que estejam publicando listas de domínios/organizações identificados no vazamento.
Atualizar para a versão mais recente do LiteLLM já resolve o problema?
Resolve a vulnerabilidade específica no pacote, mas não desfaz a exposição de credenciais que já foram roubadas durante a janela de comprometimento — a rotação de credenciais continua sendo obrigatória.
Esse tipo de ataque é comum?
Ataques de cadeia de suprimentos via dependências open-source vêm crescendo significativamente, especialmente no ecossistema de ferramentas de IA/CI-CD, que combina alta confiança automática (instalação sem revisão humana) com acesso privilegiado a segredos de produção.
Conclusão
A brecha do LiteLLM é um lembrete concreto de que a cadeia de suprimentos de software — incluindo as próprias ferramentas de segurança — é hoje um dos vetores de ataque mais eficazes contra infraestrutura corporativa. Para qualquer organização que usa LiteLLM ou dependências similares em pipelines de CI/CD, rotação de credenciais e auditoria de acesso não são mais opcionais: são resposta obrigatória a um incidente já confirmado em escala global.
