Releases maliciosos do LiteLLM ligados a invasão do Trivy podem ter exposto mais de 2.100 organizações
12 de Agosto de 2026

Duas versões maliciosas do LiteLLM permaneceram no PyPI por cerca de 40 minutos, em março, e continham código de roubo de credenciais capaz de coletar chaves de cloud, chaves SSH, tokens do Kubernetes, senhas de bancos de dados e outros segredos dos sistemas que as instalaram.

Agora, a empresa de inteligência de ameaças CloudSEK afirma que um conjunto de dados obtido por ela, construído a partir de cerca de 434.000 arquivos capturados pelos atacantes, aponta para uma possível exposição que alcança mais de 2.500 organizações.

Esses números não representam uma contagem de vítimas. Segundo a CloudSEK, o material veio de fontes confidenciais de inteligência e é formado por arquivos capturados e registros que ela atribuiu à campanha, não por dados coletados das organizações citadas. Em outras palavras, os arquivos foram roubados.

A CloudSEK publicou o conjunto de dados como uma consulta pública, pesquisável por nome ou domínio e filtrável por nível de confiança. Cada linha traz o nome e o domínio da organização, a quantidade de segredos expostos, a quantidade de execuções e um rótulo de alta ou média confiança.

Uma correspondência de alta confiança indica de quais sistemas cada arquivo veio. Essa conclusão se baseia em sinais de identidade no ambiente capturado do executor de CI, principalmente a identidade do host e domínios legítimos de commit, e o domínio da própria organização precisa aparecer para que a correspondência receba a classificação máxima.

Nomes de espaços em repositórios só permitem uma conclusão de confiança média. NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens e X Corp estão entre as entradas, mas nada disso prova que credenciais roubadas tenham sido usadas. Por isso, tanto a CloudSEK quanto a LiteLLM recomendam que as organizações afetadas rotacionem os segredos em vez de esperar prova definitiva de uso indevido.

A LiteLLM é um gateway de IA open source usado para conectar aplicações a vários provedores de modelos. O projeto identificou as versões 1.82.7 e 1.82.8 como comprometidas e informou que elas ficaram disponíveis em 24 de março, às 10h39 UTC, por cerca de 40 minutos, antes de o PyPI colocá-las em quarentena. Ainda assim, a orientação é tratar como suspeita qualquer instalação feita naquele dia até 16h00 UTC.

Em 12 de agosto o PyPI confirmou que nenhuma das duas versões aparece no histórico de lançamentos do pacote, enquanto as versões 1.82.6 e 1.83.0 seguem disponíveis.

Em um alerta de 2 de julho, identificado como FLASH-20260702-01, o FBI avisou que atores afiliados provavelmente vão transformar as credenciais exfiltradas durante a campanha TeamPCP em armas muito depois da invasão inicial. A agência orientou organizações a rotacionar segredos de CI/CD, tokens de publicação e credenciais de cloud acessíveis durante as janelas de exposição relevantes.

Um segredo duradouro copiado nesse período, como uma chave estática de cloud, uma chave SSH ou um token de publicação, continua válido a menos que tenha sido rotacionado ou revogado desde então. É por isso que a orientação do FBI foca nas credenciais, e não apenas no pacote, e também por que a agência e a Aqua recomendam que as equipes abandonem tokens de longa duração em favor de tokens temporários.

A versão 1.82.8 incluía um arquivo chamado litellm_init.pth, que o Python processa na inicialização do interpretador. Com isso, ele era executado sempre que um processo Python começava naquele ambiente, independentemente de algo importar o LiteLLM ou não.

Os pacotes comprometidos foram projetados para coletar variáveis de ambiente, chaves SSH, credenciais de cloud, tokens do Kubernetes e senhas de bancos de dados antes de criptografar e enviar os dados roubados para models.litellm[.]cloud, um domínio controlado pelos atacantes e sem relação com o projeto.

A análise da campanha feita pela Unit 42 registra que o payload lia variáveis de ambiente que guardam chaves de API de modelos, incluindo OPENAI_API_KEY e ANTHROPIC_API_KEY.

Esse comportamento muda a pergunta típica da triagem. Importa menos saber se uma equipe usa LiteLLM de forma consciente e mais verificar se algo no host o instalou, já que o aviso do projeto observa que uma dependência transitiva sem fixação de versão, inclusive uma puxada por um framework de agentes ou ferramenta de orquestração, pode instalá-lo sem escolha explícita de ninguém.

O caso do LiteLLM faz parte de uma campanha maior de supply chain do TeamPCP, ligada ao scanner Trivy da Aqua Security. O Google acompanha o TeamPCP sob o nome UNC6780. A Aqua disse que os atacantes mantiveram acesso após uma rotação incompleta de credenciais e, em 19 de março, fizeram force-push de commits maliciosos em 76 de 77 tags de versão do trivy-action e em todas as sete tags do setup-trivy, além de publicar uma versão maliciosa do Trivy 0.69.4.

O comprometimento do ecossistema é acompanhado como CVE-2026-33634 e foi incluído no catálogo Known Exploited Vulnerabilities da CISA em 26 de março. Em 12 de agosto o registro da CVE agora lista BerriAI LiteLLM 1.82.7 a 1.82.8 como afetadas, além dos componentes do Trivy.

A forma exata como os lançamentos maliciosos do LiteLLM chegaram ao PyPI é descrita de maneira diferente nas contas publicadas. O relatório da CloudSEK afirma que o build contaminado produziu e publicou as versões; o relatório do próprio LiteLLM aponta para um upload direto no PyPI, fora do fluxo oficial de CI/CD; e a Unit 42 descreve atacantes mirando tokens de publicação do PyPI após a violação do Trivy.

Questionada sobre a divergência, a CloudSEK contestou a interpretação. “São estágios diferentes da mesma cadeia de ataque, e não explicações concorrentes”, disse a empresa. A evidência dela mostra como a credencial foi obtida, enquanto as descobertas da LiteLLM e da Unit 42 mostram como ela foi usada depois.

O alerta da PyPA sobre os lançamentos maliciosos descreve a mesma sequência: um token de API exposto pela dependência comprometida do Trivy e depois usado para enviar as duas versões. A BerriAI ainda não havia respondido, até o momento da publicação, sobre qual conta suas próprias análises forenses sustentam.

A atribuição dentro do conjunto de dados passa por duas verificações independentes, segundo a CloudSEK. Um índice classifica cada arquivo com base em variáveis de identidade de CI, e um segundo controle de propriedade reavalia a titularidade a partir dos registros coletados e pode sobrepor essa classificação. “Se houver divergência, o relatório é retido”, disse a empresa, e o veredito final adota o menor dos dois níveis de confiança.

A cifra de 434.000 se refere a arquivos capturados e eventos de exfiltração, não a pipelines, execuções ou jobs distintos. A CloudSEK informou que um arquivo capturado equivale aproximadamente a uma execução de job, mas não apresenta o total como jobs únicos sem deduplicação e verificação independentes.

A empresa não quis comentar notificações pré-publicação enviadas às organizações citadas e também não informou se alguma contestou sua inclusão.

O impacto posterior da campanha está confirmado, mesmo que os números de escala da CloudSEK não estejam. A Checkmarx disse que credenciais obtidas na invasão do Trivy permitiram acesso não autorizado aos seus repositórios no GitHub e a publicação de artefatos maliciosos. A Mercor afirmou ter sido afetada por versões maliciosas do LiteLLM e ter contido atividade não autorizada.

Separadamente, a CERT-EU avaliou com alta confiança que uma conta da Amazon Web Services da Comissão Europeia foi comprometida por meio do ataque de supply chain ao Trivy, com cerca de 91,7 GB de dados compactados exfiltrados.

Organizações que avaliam exposição devem seguir três passos:

• Verificar se houve instalações do LiteLLM 1.82.7 ou 1.82.8 durante a janela de auditoria do LiteLLM em 24 de março, entre 10h39 e 16h00 UTC.
• Rotacionar quaisquer segredos aos quais esses sistemas possam ter tido acesso.
• Procurar em suas organizações no GitHub por repositórios chamados tpcp-docs ou docs-tpcp, que o FBI lista como indicadores da campanha. O alerta da Aqua sobre a CVE observa que o malware criou esses repositórios com o prefixo tpcp-docs- e enviou os dados roubados como um artefato de release com a tag data-<timestamp>, então uma busca pelo nome exato pode não encontrá-los.

Publicidade

Anuncie no CaveiraTech e coloque sua marca na frente de milhares de profissionais de cybersecurity

Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...