A cadeia de suprimentos de IA como vetor de ataque: um olhar sobre o ataque ao LiteLLM
Nesta última semana de março, um tema chamou a atenção no universo da cibersegurança, mas ainda não está sendo analisado de forma profunda no Brasil. Um aviso de segurança foi publicado no repositório oficial do LiteLLM no GitHub reportando que as versões 1.82.7 e 1.82.8 – disponibilizadas no PyPI, que é o repositório oficial de pacotes para a linguagem Python – continham payloads maliciosos com o objetivo de roubo de credenciais, ausentes no código-fonte oficial.
Descoberta e escopo
Na prática, as vítimas foram comprometidas ao instalar diretamente o pacote litellm a partir do PyPI sem fixar previamente uma versão segura, durante a janela de tempo em que as versões maliciosas estavam ativas. E para poder adentrar no tema principal que proponho, que trata dos riscos e do potencial impacto que esse tipo de ataque representa, é preciso, antes, contextualizar a que se destina e a relevância que serviços como o LiteLLM têm sobre a cadeia de suprimentos de inteligência artificial.
Contexto e relevância
À medida que as organizações passam a depender cada vez mais de LLMs em processos de negócio, é comum a contratação de modelos de linguagem dos principais provedores (como OpenAI, Anthropic, Google, Azure e AWS Bedrock). E para lidar com a complexidade na comunicação entre cliente e provedor, as empresas recorrem a ferramentas que funcionam como uma camada de abstração unificada, viabilizando a comunicação e a orquestração do acesso aos mais diversos provedores. Essa abordagem não apenas simplifica, mas padroniza a integração com os provedores de IA. É nesse contexto que entra o LiteLLM: uma biblioteca Python de código aberto, desenvolvida pela BerriAI, capaz de intermediar a comunicação com mais de 100 provedores de modelos de linguagem. A biblioteca vem sendo amplamente adotada em pipelines de produção, plataformas de MLOps, ambientes Kubernetes e arquiteturas baseadas em agentes autônomos.
Vetor e exploração
Ataques à cadeia de suprimentos possuem uma característica em comum, eles usam os elos da corrente para chegar ao alvo, explorando brechas nos serviços que orbitam ao redor dos clientes finais. E a sofisticação deste ataque está no uso de credenciais legítimas do LiteLLM para publicar os pacotes maliciosos no PyPI. Uma vez que os clientes instalavam as versões adulteradas, o malware era acionado de duas formas: Versão 1.82.7: o código malicioso estava embutido no arquivo proxy/proxy_server.py e era ativado quando a vítima importava o módulo litellm.proxy. Versão 1.82.8: o ataque se tornou ainda mais agressivo com a injeção de um arquivo de inicialização oculto chamado litellm_init.pth. Esse arquivo explorava um mecanismo nativo do Python para executar o código malicioso silenciosamente, assim que o interpretador era iniciado e sem exigir sequer que a vítima importasse o LiteLLM.
Evidências e limites
A etapa seguinte era a execução autônoma do script malicioso, que vasculhava o sistema da vítima e coletava credenciais em massa, incluindo variáveis de ambiente, que frequentemente armazenam chaves de API; chaves SSH e credenciais Git; credenciais ativas e arquivos de configuração dos principais provedores de nuvem; segredos de clusters Kubernetes; e carteiras de criptomoedas. Todos os dados coletados eram então criptografados e exfiltrados silenciosamente para um domínio sob controle do atacante, disfarçado para parecer legítimo: models.litellm.cloud.
Linha do tempo do incidente
Para você entender os bastidores desse ataque, o cibercriminoso utilizou as credenciais legítimas de publicação no PyPI da equipe do LiteLLM para distribuir as versões adulteradas, tornando o pacote indistinguível, à primeira vista, de uma atualização comum. Em nota publicada no blog docs.litellm.ai, Krrish Dholakia, CEO do LiteLLM, diz que o vetor de entrada foi o Trivy, uma ferramenta de escaneamento de vulnerabilidades utilizada no pipeline de integração contínua (CI/CD) do projeto. Quando o repositório apt do Trivy foi comprometido em um ataque separado, o binário malicioso instalado no runner de CI obteve acesso privilegiado e exfiltrou as credenciais que permitiram aos atacantes publicar versões comprometidas do LiteLLM diretamente no PyPI.
Impacto por setor e Brasil
O incidente do LiteLLM não é uma anomalia, é um padrão. Porque, em menos de uma semana, o mesmo atacante comprometeu o Trivy, presente em praticamente qualquer pipeline DevSecOps moderno e usou esse acesso para contaminar o LiteLLM, simplesmente, a biblioteca central de dezenas de aplicações de IA em produção. Ou seja, dois elos de uma mesma corrente, quebrados em sequência. Considerando que 2026 vem sendo amplamente apontado como o ano da consolidação da IA em ambientes corporativos, à medida que LLMs se tornam infraestrutura crítica, as ferramentas que orbitam esse ecossistema, como SDKs de integração, proxies de LLM, bibliotecas de orquestração, e ferramentas de observabilidade, tornam-se alvos de altíssimo valor. Então, um único pacote comprometido, instalado silenciosamente por um runner de CI, pode conceder ao atacante acesso irrestrito a todo o ambiente de nuvem de uma organização.
Medidas de mitigação recomendadas
Para CISOs e líderes de tecnologia, a mensagem é muito clara e direta: a superfície de ataque de IA não começa nos modelos, mas sim, nos pacotes que você instala para chegar até eles. Fixação de versões, SBOMs (Software Bill of Materials), verificação de integridade de artefatos, monitoramento de dependências transitivas e revisão de permissões de CI/CD não são boas práticas opcionais, são o novo perímetro. Alan Aquino, gerente sênior de Engenharia da Fortinet Brasil.