LiteLLM ataque supply chain e o que fazer agora

LiteLLM ataque supply chain, em 21 de outubro de 2026, publicou a versão 1.107.0 com malware no PyPI e em imagens Docker. LiteLLM é um gateway Python que unifica provedores de modelos de linguagem. O pacote costuma rodar perto de chaves de nuvem e de LLM.

Se o seu time instalou essa versão ou puxou tags flutuantes oficiais na janela errada, o risco não é só o pacote. Além disso, o payload entra no ambiente Python e pode rodar em qualquer início do interpretador, mesmo sem importar o LiteLLM. Por isso a prioridade é conter, limpar hooks, reconstruir e rotacionar segredos alcançáveis.

Este guia fica no ângulo de defesa e desenvolvimento. Assim, você sai com a janela em UTC e com o perímetro claro. Em seguida, vê como provar exposição e o que rotacionar. Depois, fixa a litellm 1.106.2 versão segura e separa o que ainda segue em investigação.

O que aconteceu e qual foi a janela em UTC?#

Em 21 de outubro de 2026, a cadeia de publicação do LiteLLM foi comprometida. A versão 1.107.0 saiu com stealer de credenciais e carregador de código remoto. O artefato ruim chegou ao PyPI e a imagens oficiais.

Qual foi a janela UTC no PyPI e no Docker?#

Segundo o aviso oficial do incidente, atualizado em 21 de outubro de 2026 às 20h30 UTC, o pacote litellm==1.107.0 ficou ao vivo no PyPI cerca de duas horas. A janela do PyPI foi de 11h39 UTC a 13h23 UTC. Já as imagens Docker Hub v1.107.0, latest, main-latest e main-stable apontaram para o índice comprometido de 11h46 UTC a 14h20 UTC.

O digest citado no aviso para a imagem ruim no Docker Hub é sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. No GHCR, as tags equivalentes ficaram comprometidas a partir de 11h46 UTC. Depois, elas ficaram indisponíveis até cerca de 13h51 UTC. A tag de código v1.107.0 no repositório legítimo não carregava os arquivos maliciosos. Portanto, os artefatos saíram de um repositório controlado pelo atacante.

Por que a tag Git limpa não bastava?#

A análise da JFrog Security Research confirma que as sete wheels da 1.107.0 levavam o payload. Em contraste, o tarball de fonte não trazia os mesmos três arquivos de startup. Assim, quem só revisa o Git tag ou o sdist pode achar o release limpo. Ainda assim, a wheel ruim pode entrar no host. O The Register descreveu o caso no mesmo dia como distribuição de malware de roubo de segredos e de um RAT por meio do PyPI e de registries Docker.

Na prática, o que eu vejo com mais frequência é time tratar “duas horas no ar” como janela pequena demais para inventário. Porém, em CI com cache, em rebuild automático e em pull de latest, essa janela basta para contaminar runner, notebook e proxy. O relógio útil é o UTC do instalador e do registry, e não o fuso do escritório.

Quem é afetado no PyPI, no Docker e quem fixa versão?#

Você entra no perímetro se instalou litellm==1.107.0 no intervalo do PyPI. Também entra se executou imagem v1.107.0, latest, main-latest ou main-stable no intervalo Docker. Quem pina versão antiga e não puxou a 1.107.0 naquela janela fica fora do artefato ruim. Mesmo assim, ainda precisa validar lockfiles, caches e imagens locais.

O aviso oficial separa usuários open source de clientes enterprise no registry privado. No OSS, pip sem pin ou imagem com tag flutuante na janela deve ser tratado como comprometido. No enterprise, a LiteLLM afirma que o registry privado usado para distribuição embargada não foi afetado. Isso só vale se a instalação realmente veio desse canal privado. Caso contrário, PyPI público e tags públicas do Docker Hub ou do GHCR entram no mesmo risco.

Quem “fixa versão” no dia a dia também muda a exposição. Dependabot, renovate, imagem base sem digest e pip install -U litellm sem hash ampliam a chance de pegar a 1.107.0. Além disso, ninguém precisa notar o número na hora. O Datadog Security Labs resume a superfície em pacote PyPI e tags GHCR e Docker Hub. Ele também lembra o volume alto de downloads semanais, o que explica a urgência de inventário mesmo com poucas horas de exposição.

O erro que mais custa caro aqui é assumir que “não usamos Docker, então estamos bem”, ou o contrário. LiteLLM PyPI comprometido e LiteLLM Docker supply chain são vetores paralelos do mesmo release. Por isso o inventário precisa cruzar lockfile, histórico de pip, digest de imagem e horário UTC do job.

Como saber se você instalou a versão ruim?#

Comece pelo histórico de instalação e pelo digest, e não pelo feeling do time. Se pip show litellm já apontou 1.107.0 em algum momento da janela, o ambiente deve ser tratado como comprometido. O mesmo vale se o container rodou o digest comprometido. Isso permanece mesmo que o pacote já tenha sido removido do índice público.

Procure evidência de litellm-1.107.0.dist-info e de wheels 1.107.0 em cache. Também procure builds que instalaram a versão sem pin entre 11h39 UTC e 13h23 UTC em 21 de outubro de 2026. Em containers, compare o digest puxado com sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Achar um desses sinais confirma exposição. Não achar nada, porém, não limpa o ambiente, porque limpeza de /tmp, rebuild e rotação de volumes apagam rastros.

A Socket registrou que o scanner dela marcou as wheels minutos após a publicação. Além disso, a proveniência da imagem apontava o repositório lookalike Berri-AI/litellm, e não o BerriAI/litellm legítimo. Isso ajuda a explicar por que a tag de fonte “oficial” pode parecer limpa enquanto o artefato instalável não estava. Se o seu pipeline só valida Git tag, ele podia passar verde e ainda assim entregar LiteLLM 1.107.0 malicioso.

Muita gente acha que desinstalar o pacote apaga o problema, e quase sempre está enganada, porque os hooks foram para a raiz do site-packages. Por isso a checagem de versão precisa vir junto da caça a cook.pth, cook.py e sitecustomize.py inesperado. Sem os dois eixos, você só fecha metade do inventário.

Quais indicadores de comprometimento o aviso oficial e as análises listam?#

Os IoCs mais úteis hoje misturam arquivos de startup, artefatos em /tmp, domínio de exfiltração e digest da imagem. O aviso oficial pede busca por litellm-1.107.0.dist-info, cook.pth e sitecustomize.py. Ele também orienta matar o daemon Python que segura /tmp/remote_code_loader.lock antes de qualquer pip no ambiente sujo.

A JFrog publica uma lista operacional alinhada a esse quadro. Entre os sinais estão o domínio www.litellm.dev e o caminho /healthcheck. Também aparecem o dead-drop raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt, o marcador /tmp/.pc_once_72129118c59f5636c0bb, artefatos /tmp/.pc_sq_ e /tmp/.pc_e_, além do digest da imagem afetada. Segundo o The Register, o caçador da Aikido também destacou /tmp/.pc_once_* como sinal de exfiltração já disparada. O lock do loader, por sua vez, aponta C2 ativo ou recente.

O mecanismo importa para a caça. cook.pth força o import de cook.py no startup do Python. sitecustomize.py sobe o loader em background. Assim, qualquer python, pip ou job no venv pode retrigger o malware. Em resposta a incidente, o primeiro reflexo errado é abrir o venv e “só rodar um pip show”. Se o interpretador sujo sobe, você pode reexecutar o payload enquanto tenta diagnosticar.

Prefira ferramentas de shell e filesystem que não invoquem aquele Python. Isole a máquina e preserve logs de DNS, proxy e nuvem antes da limpeza agressiva. Ausência do lock em um host não prova ausência do roubo de credenciais LiteLLM, porque container efêmero e limpeza de /tmp removem a prova com facilidade.

LiteLLM ataque supply chain exige rotacionar quais segredos?#

Se a 1.107.0 rodou em host com saída para a internet, o aviso oficial pede assumir que a exfiltração pode ter ocorrido. O marcador de execução única confirma quando existe. A ausência do marcador não inocenta, porque container efêmero e limpeza de /tmp removem a prova.

A lista mínima do comunicado oficial inclui papel IAM da instância ou task. Também inclui todas as chaves de provedor guardadas no banco do proxy LiteLLM, master key e virtual keys, senha do DATABASE_URL e qualquer segredo presente no ambiente de processos naquele host. Em seguida, a própria LiteLLM recomenda olhar CloudTrail por GetCallerIdentity do role na hora da instalação e por uso desse material fora da sua infraestrutura. Para o fluxo AWS, o artigo onde olhar primeiro na AWS ajuda a organizar a ordem de logs sem confundir sintoma com causa.

As análises da Wiz e da JFrog ampliam o inventário além do proxy. Elas descrevem coleta de credenciais de navegador, AWS, Azure e GCP, tokens e configs de ferramentas de IA, chaves SSH e GPG, segredos de CI e variáveis de ambiente legíveis. A Wiz fala em módulos amplos de coleta em browser, nuvem e serviços de IA. Trate isso como hipótese forte de superfície, e não como prova de que cada módulo disparou no seu caso. Ainda assim, a rotação deve cobrir tudo que o host podia alcançar, porque o custo de deixar chave viva costuma superar o custo de rotacionar cedo.

Quando o ambiente parece “só um sandbox de prompt”, o risco muda pouco se havia chave real de provedor, token de nuvem ou volume montado com ~/.aws. Rotacione, revogue e regenere. Depois audite uso. Limpar arquivo sem rotacionar segredo deixa a porta aberta para quem já recebeu o pacote criptografado.

Como fixar a versão e verificar hash ou assinatura?#

A versão segura apontada de forma consistente pelo aviso oficial, pela JFrog, pela Endor Labs e pelo The Register é a 1.106.2. Porém, o pin correto não é o primeiro comando. Se o ambiente já executou a 1.107.0, começar com pip install no mesmo Python pode rearmar cook.pth e sitecustomize.py.

Por que não começar com pip install?#

A Endor Labs reforça que o ataque mora no empacotamento. A tag revisada, por si só, não mostra a mudança de build. Por isso, qualquer comando que suba o Python sujo pode rearmar os hooks. Assim, diagnóstico e remediação precisam começar fora desse interpretador.

Ordem defensiva de contenção e pin#

Siga esta ordem defensiva, adaptada do comunicado oficial e das notas da JFrog:

1. Isole o host ou o container e preserve logs de rede, DNS, endpoint e nuvem antes de apagar evidência útil.
2. Remova cook.pth, cook.py, sitecustomize.py e os *.pyc correspondentes em __pycache__ de cada site-packages afetado, usando ferramentas que não iniciem o Python comprometido.
3. Encerre o processo detached associado a /tmp/remote_code_loader.lock e inspecione marcadores /tmp/.pc_once_, /tmp/.pc_sq_ e /tmp/.pc_e_*.
4. Reconstrua venv ou imagem do zero e pinne litellm==1.106.2, de preferência com hash da wheel boa e digest imutável da imagem boa.
5. Só então rotacione os segredos alcançáveis e audite uso posterior desses segredos.

Verificar hash e assinatura reduz reincidência, porém não substitui rebuild. A Socket mostrou que a proveniência do build pode registrar fonte lookalike com aparência quase legítima. Por isso, pin por número sem pin por hash ainda deixa espaço para artefato trocado no próximo incidente. Conferir digest da imagem, hash da wheel e origem do repositório precisa virar hábito de release, e não ritual só depois do susto.

O atalho que mais atrasa contenção é “corrigir no lugar” e seguir com o mesmo volume sujo. Rebuild a partir de artefato verificado custa tempo agora e evita falso negativo caro depois. Se houver dúvida entre limpar e recriar, recriar vence na maior parte dos proxies e runners de IA.

Open source e enterprise diferem neste incidente?#

Sim, e a diferença vem do canal de distribuição, não de imunidade mágica. A LiteLLM afirma que clientes no registry privado enterprise não foram impactados por este release público 1.107.0. Quem puxava do PyPI público ou das tags públicas de Docker Hub e GHCR entra no cenário OSS descrito no aviso.

Há um detalhe adicional no próprio comunicado. A empresa menciona release embargado no canal privado ligado a uma vulnerabilidade com divulgação prevista para 27 de outubro de 2026. Isso é independente do malware da 1.107.0 e não deve ser lido como “enterprise já está patchado para tudo”. Significa só que o registry privado não foi o canal do artefato trojanizado deste incidente, conforme a fonte oficial.

O Datadog observa ainda que este é o segundo comprometimento de supply chain do LiteLLM em 2026. No momento da análise deles, não havia ligação estabelecida com o episódio anterior associado pela pesquisa deles à atividade TeamPCP. Sem fonte primária nova atribuindo ator nomeado a este caso de 21 de outubro de 2026, o texto defensivo deve falar em atacante e em repositório lookalike, conforme o consenso das fontes abertas, e não em grupo específico.

Em operação mista, o risco prático é o time enterprise achar que “somos cliente, então acabou” enquanto um job paralelo ainda instala do PyPI. Confirme o registry real de cada ambiente. Se um único cluster puxa dos dois mundos, a isenção do canal privado não cobre o nó que bebeu da fonte pública.

Como reduzir risco de supply chain em dependências de IA?#

Depois da contenção, o ganho está em tornar a próxima troca de artefato mais cara para o atacante e mais visível para você. Pin de versão exata, pin de hash em Python, digest imutável em imagem e proibição de latest em produção são o piso. Em cima disso, bloqueie tags flutuantes em CI de gateway de LLM e exija revisão humana quando o lockfile subir versão de proxy que guarda chaves.

Monitore egresso para domínios lookalike e para dead-drops em raw GitHub. Neste caso, o domínio de exfiltração citado pelas análises técnicas era uma variação próxima da marca. Além disso, trate startup hooks em site-packages como superfície de persistência. O guia de caça a persistência para blue team encaixa quando o payload sobrevive à remoção do pacote principal. Para o processo contínuo, um programa de gestão de vulnerabilidades precisa incluir dependências de IA com o mesmo rigor de lib web clássica.

Há limite claro. Nenhuma dessas medidas elimina supply chain. Elas reduzem janela, aumentam chance de detecção e diminuem o raio de blast quando um token de release vaza. Separar ambientes que guardam chaves de provedor, usar segredo de curta duração e evitar notebook com role amplo continua sendo defesa de verdade, mesmo com scanner de pacote no pipeline.

O hábito que mais diferencia time maduro de time apressado é recusar rebuild “rápido” com tag móvel depois do incidente. Se a correção de ontem usou latest, a próxima 1.10x.y ruim pode entrar pela mesma porta. Disciplina de artefato é chata e é exatamente o que este caso puniu.

O que ainda não se sabe e o que monitorar agora?#

Até a atualização oficial de 21 de outubro de 2026 às 20h30 UTC, a LiteLLM dizia ter identificado a cadeia de ataque com alto grau de confiança. Porém, a investigação seguia em andamento. O relato oficial e as análises técnicas abertas descrevem artefatos construídos a partir de repositório lookalike Berri-AI/litellm, e não a partir da tag limpa do projeto legítimo.

Ainda não há, nas fontes abertas conferidas nesta sessão, um CVE clássico para “bug de código” da 1.107.0, porque o núcleo do caso é artefato trojanizado na cadeia de distribuição. Também não há atribuição pública consolidada a um grupo nomeado com fonte primária para este evento específico. O Datadog afirma explicitamente que ligação com o incidente anterior de 2026 não estava estabelecida no texto deles.

O que monitorar nas próximas horas e dias é atualização do aviso oficial, novos IoCs, sinais de reuso de credenciais rotacionadas tarde e qualquer segundo estágio servido pelo canal de código remoto. A JFrog alerta que efeitos de código arbitrário baixado depois do dead-drop não ficam limitados ao comportamento do stealer embutido. Por isso, host que ficou horas com o loader vivo merece forense mais larga do que “só troquei a versão”.

Quem espera o relatório final para começar inventário costuma chegar depois da validação das chaves roubadas. Trate o que já é consenso entre aviso oficial e labs como ação imediata, e reserve o que ainda é incerto para o quadro de hipóteses da investigação.

Perguntas frequentes sobre LiteLLM ataque supply chain#

Esta seção responde dúvidas reais de quem opera proxy de LLM, CI e notebooks no mesmo dia do incidente. As respostas abaixo partem do aviso da LiteLLM de 21 de outubro de 2026 e das análises técnicas abertas da JFrog, do Datadog, da Socket, da Wiz, da Endor Labs e do The Register. Elas não substituem forense do seu ambiente, porque cache, volume e horário de pull mudam o enquadramento de cada host.

Preciso rotacionar chaves se só testei a imagem e já apaguei o container?#

Sim, se o container com a imagem ruim chegou a executar e tinha saída de rede ou montagem com segredos, a rotação continua necessária. Apagar o container remove o filesystem efêmero, porém não invalida material já exfiltrado. O aviso oficial é explícito ao pedir assunção de exfiltração quando a 1.107.0 rodou com internet. Rotacione chaves de provedor, segredos de ambiente e credenciais de nuvem alcançáveis, depois audite uso fora da janela legítima.

A tag Git limpa da 1.107.0 significa que posso confiar no release?#

Não. O aviso oficial e a Socket mostram que a tag de fonte legítima não continha os arquivos maliciosos, enquanto wheels e imagens foram construídas a partir de repositório lookalike. Confiar só no Git tag ou no sdist era exatamente o ponto cego deste caso. Para instalação, o que importa é a wheel ou o digest que o ambiente realmente baixou, com hash e origem conferidos.

Desinstalar o litellm com pip já remove o malware?#

Em muitos casos, não basta como primeiro passo, e pode ser perigoso se o comando sobe o Python sujo. Os arquivos cook.pth, cook.py e sitecustomize.py vivem na raiz do site-packages e disparam no startup. A orientação convergente é remover esses hooks sem invocar o interpretador afetado, derrubar o loader, reconstruir o ambiente e só então instalar a 1.106.2 pinada. Trate uninstall isolado como incompleto até provar ausência dos hooks e dos artefatos em /tmp.

Clientes enterprise estão automaticamente seguros?#

Somente se a instalação veio do registry privado que a LiteLLM declara não afetado. Se algum ambiente enterprise também puxava PyPI público ou tags públicas latest, main-stable ou main-latest na janela de 21 de outubro de 2026, esse ambiente entra no mesmo playbook do OSS. A pergunta útil não é o contrato comercial. É o URL e o digest reais do artefato em cada cluster.

Qual é a diferença prática entre este caso e um CVE de código?#

Aqui o problema central é supply chain do artefato publicado, e não um bug documentado com CVSS no código da tag limpa. Por isso as ações imediatas giram em torno de inventário de versão, digest, hooks de startup e rotação de segredo. Mesmo sem CVE clássico publicado nas fontes conferidas, o impacto operacional pode ser alto, porque o payload roda cedo e mira credenciais de nuvem e de LLM no mesmo host.

Conclusão#

Se o seu ambiente tocou a 1.107.0 na janela de 21 de outubro de 2026, a ordem que melhor protege a maioria dos times é isolar, remover hooks sem rearmar o Python, reconstruir com litellm==1.106.2 pinada por hash ou digest, rotacionar tudo que o host podia alcançar e auditar uso das chaves. Esperar um relatório perfeito antes do inventário só amplia o tempo em que credencial viva permanece útil para quem já coletou o pacote.

A resposta muda quando você prova, com origem e horário, que nunca instalou a wheel ruim e nunca puxou as tags flutuantes na janela Docker. Nesse caso, ainda vale endurecer pin e monitoramento, porém a contenção forense deixa de ser o centro. O primeiro passo concreto agora é listar hosts, runners e proxies com LiteLLM e marcar quais passaram por pip ou pull entre 11h39 UTC e 14h20 UTC nesse dia.

Este texto tem caráter informativo e educativo sobre o incidente de supply chain do LiteLLM em 21 de outubro de 2026. Ele não substitui avaliação profissional de segurança, resposta a incidente ou forense no seu ambiente específico.