A Forcepoint X-Labs divulgou em 18 de maio um ataque supply-chain a LiteLLM, o gateway Python open-source que serve como interface unificada a 100+ provedores LLM. O grupo de ameaça TeamPCP envenenou releases PyPI 1.82.7 e 1.82.8. A cadeia de ataque não breachou o repositório fonte do LiteLLM diretamente — em vez disso, o TeamPCP envenenou o Trivy (o scanner de vulnerabilidades que o LiteLLM usa em seu pipeline de build) personificando mantenedores do Trivy e disparando processos de release automatizados para distribuir binários Trivy backdoored. Quando o CI/CD do LiteLLM pulled o build do Trivy comprometido, o backdoor scraped a memória do runner e exfiltrou um token PYPI_PUBLISH. Os atacantes então usaram esse token para publicar releases maliciosos do LiteLLM diretamente. Divulgado por Prashant Kumar na Forcepoint X-Labs.
O comportamento do payload difere entre as duas versões. A versão 1.82.7 usou payloads Base64-encoded dentro de proxy_server.py executando no startup do proxy — mais fácil de detectar por qualquer um que diffe o arquivo. A versão 1.82.8 era mais stealthy: desplegava um arquivo litelllm_init.pth em site-packages que ativa "no startup do interpretador Python em cada processo subsequente, independentemente de se o LiteLLM foi alguma vez importado explicitamente." Essa é a escalada chave — uma vez instalado, o backdoor roda toda vez que qualquer interpretador Python inicia naquele ambiente, não só quando o LiteLLM é usado. As credenciais targeted: chaves API OpenAI, Anthropic, Microsoft Azure; credenciais SDK AWS, Google Cloud, e Azure; arquivos kubeconfig e AWS credential de diretórios home de usuários. A exfiltração foi AES-256-CBC criptografada com uma session key de 32 bytes, enviada via curl para models.litellm.cloud. Um módulo de persistência chamado Sysmon.py consultava checkmarx.zone a cada 50 minutos por novas instruções.
A lição arquitetural é o sequestro de cadeia de confiança. O TeamPCP não atacou o repositório bem-defendido do LiteLLM; eles atacaram o Trivy, que o processo de build do LiteLLM confiava por padrão. Essa é a mesma classe de ataque supply-chain que xz-utils (a personificação de mantenedor que quase comprometeu o systemd) e o ataque npm tj-actions do início deste ano. Qualquer ferramenta no seu processo de build — scanners, formatters, resolvedores de dependência, linters — é uma superfície de ataque potencial, mesmo que seu trabalho real seja security-adjacent. O compromise do LiteLLM é especialmente damaging porque a proposta de valor inteira do LiteLLM é ser o gateway a cada provedor LLM maior. Como Prashant Kumar disse: "LiteLLM funciona como um gateway unificado a provedores AI maiores, significando que um único compromise deu a atacantes acesso simultâneo a credenciais OpenAI, Anthropic e Azure." Se você instalou 1.82.7 ou 1.82.8, cada credencial de provedor que o ambiente tocou está potencialmente nas mãos do TeamPCP.
Segunda-feira: se você tem qualquer ambiente que rodou LiteLLM 1.82.7 ou 1.82.8, trate cada chave API à qual o ambiente teve acesso como comprometida — rotacione chaves OpenAI, Anthropic, Azure, AWS, GCP imediatamente, e audite logs de uso por requisições não familiares. Verifique o arquivo litelllm_init.pth nos seus site-packages e o módulo de persistência Sysmon.py. Bloqueie egress para models.litellm.cloud e checkmarx.zone na sua camada de rede até ter limpado o host. Para seu pipeline de build adiante: pin Trivy e cada outra dependência de ferramenta-de-build a hashes verificados (não só versões), exija releases assinados para tooling security-adjacent, e isole tokens de publish PyPI para que não sejam acessíveis a scanners build-time. O writeup da Forcepoint não divulgou o timeline exato, contagens de downloads, ou a resposta da BerriAI — essas lacunas tornam impossível estimar a exposição precisamente. Trate como pior-caso até que a BerriAI publique uma divulgação coordenada.