O que aconteceu no pipeline de build da LiteLLM em março

A intrusão não começou na própria LiteLLM. A TeamPCP comprometeu primeiro o scanner de segurança de código aberto Trivy, explorando um token de automatização vazado, o que lhe deu uma janela de cerca de 20 dias dentro do próprio repositório do Trivy antes que alguém se apercebesse. Durante essa janela, o grupo forçou a inserção de código malicioso nas tags de versão do Trivy - os marcadores de lançamento específicos para os quais apontam os projetos a jusante quando obtêm uma dependência.

O pipeline de integração contínua da LiteLLM instalava o Trivy sem o fixar numa versão estável e verificada, pelo que importou automaticamente a versão envenenada na execução seguinte do pipeline. Essa única dependência sem versão fixa foi a única brecha de que a TeamPCP precisava: o código malicioso entrou no próprio processo de build da LiteLLM e, daí, em dois pacotes publicados, as versões 1.82.7 e 1.82.8 da LiteLLM, carregadas no Python Package Index.

A defesa em que todos confiam, e como foi contornada

A maioria dos programadores preocupados com pacotes maliciosos no PyPI confia na flag --ignore-scripts, que impede que os scripts de instalação de um pacote executem código arbitrário. A carga maliciosa da TeamPCP não precisava de um script de instalação. Estava alojada num ficheiro .pth, um ficheiro de configuração de caminhos do Python que o próprio interpretador executa automaticamente no arranque, em cada execução, independentemente da forma como o pacote foi instalado. Esta escolha de conceção é o pormenor que todas as manchetes sobre esta violação omitiram, e é o que mais importa para qualquer equipa de engenharia que pensasse que a --ignore-scripts a protegia precisamente desta classe de ataque.

Uma vez em execução, a carga maliciosa recolhia chaves SSH, credenciais na nuvem para AWS, Google Cloud e Azure, tokens do Kubernetes, o conteúdo de ficheiros .env e chaves de API de fornecedores de IA de qualquer máquina onde o pacote envenenado tivesse sido instalado. Os dados roubados eram cifrados com AES-256 e enviados para um domínio de typosquatting concebido para parecer um recurso legítimo da LiteLLM ou do Trivy, ou então carregados diretamente em repositórios na própria conta de GitHub da vítima - um pormenor que permitia que a operação se confundisse com atividade normal de programador, em vez de despoletar um alerta óbvio de tráfego de saída.

2500 empresas, oito nomeadas na Europa e um hiato de cinco meses

A CloudSEK publicou a sua investigação em 11 de agosto de 2026, cinco meses após o compromisso de março, identificando mais de 2500 organizações e cerca de 434000 pipelines de CI/CD como potencialmente expostos - o que a empresa classifica como a maior violação da cadeia de fornecimento de IA descoberta até agora em 2026. Entre as correspondências de elevada confiança que a CloudSEK nomeia estão a Siemens AG, a Siemens Energy, a Deutsche Bahn AG, a Orange S.A., a Vodafone Group Plc, a London Stock Exchange Group, a empresa energética finlandesa Fortum Oyj e a resseguradora Munich Re, abrangendo os setores da indústria, telecomunicações, ferrovias, finanças e seguros em várias jurisdições europeias.

A CloudSEK é explícita ao afirmar que a presença de uma empresa no seu conjunto de dados não é uma prova automática de uma violação bem-sucedida - a constatação significa que credenciais, domínios, repositórios ou infraestrutura ligados a essa organização surgiram nos dados recolhidos, e cada organização precisa de realizar a sua própria investigação para confirmar o que, se algo, foi de facto retirado ou utilizado indevidamente. O que não está em causa é o hiato de cinco meses entre a intrusão de março e a divulgação de agosto, uma janela durante a qual qualquer uma das organizações nomeadas podia estar a operar com infraestrutura com credenciais comprometidas, sem qualquer aviso público de que o compromisso tinha ocorrido.

O que isto significa para quem gere ferramentas de infraestrutura de IA

O aviso FLASH do FBI de julho de 2026 acrescenta um pormenor incómodo à cronologia: as credenciais recolhidas em março continuam a ser consideradas ativas e utilizáveis meses depois, e a agência espera que a TeamPCP ou atores associados as utilizem em futuras intrusões não relacionadas, em vez de as deixar caducar. Para qualquer organização que tenha executado as versões 1.82.7 ou 1.82.8 da LiteLLM em produção ou CI durante março de 2026, a resposta correta não é esperar por uma confirmação individual da CloudSEK ou da LiteLLM - é tratar todas as credenciais que tenham passado por esse pipeline de build como comprometidas e substituí-las agora, com cinco meses de atraso ou não.

A lição estrutural vai para além da LiteLLM. Qualquer organização que permita que o seu pipeline de CI importe uma dependência de ferramentas de segurança, como um scanner, sem a fixar numa versão verificada, tem a mesma brecha que a TeamPCP utilizou aqui, e a --ignore-scripts não é a salvaguarda que a maioria das equipas acredita que é contra uma carga maliciosa entregue através de um ficheiro .pth. Os responsáveis de segurança europeus que gerem ferramentas de infraestrutura de IA construídas sobre a mesma cadeia de fornecimento de código aberto devem encarar isto menos como uma história da LiteLLM e mais como uma antevisão de como será provavelmente entregue o próximo compromisso de ferramentas de IA.

Leia a seguir: 141 006 testes, três invasões reais  |  Micron: 2027 será mais apertado que 2026