Ars Technica relata um enorme vazamento de credenciais do LiteLLM após um ataque à cadeia de suprimentos

A Ars Technica relata que credenciais vinculadas a mais de 2.500 organizações apareceram em dados roubados por meio de um pacote de IA comprometido. A escala relatada transforma o incidente com o LiteLLM, ocorrido em março, de uma falha pontual de pacote em uma crise de credenciais potencialmente duradoura.

Os invasores corromperam duas versões oficiais do LiteLLM e as distribuíram pelo Python Package Index, conhecido como PyPI. O código malicioso procurava nos sistemas infectados chaves de nuvem, tokens de repositórios, credenciais SSH, senhas de bancos de dados e segredos usados por serviços de IA.

O ataque não começou com o LiteLLM. Ele fez parte de uma campanha que avançou por ferramentas de segurança confiáveis, fluxos de trabalho de desenvolvedores e contas de publicação de pacotes. Cada elo comprometido supostamente forneceu credenciais que ajudaram os invasores a alcançar outra parte da cadeia de suprimentos de software.

Os dados recém-relatados oferecem uma visão mais clara, mas ainda incompleta, das consequências. Pesquisadores associaram centenas de milhares de arquivos ou registros de pipelines a mais de 2.500 organizações. No entanto, o aparecimento de um domínio em dados roubados não prova que todas as organizações listadas sofreram acesso não autorizado.

Essa distinção é importante. O comprometimento confirmado do pacote ocorreu em março de 2026, enquanto os pesquisadores divulgaram o conjunto de dados mais amplo meses depois. As equipes de segurança agora precisam determinar se as credenciais coletadas durante o ataque continuaram válidas, foram usadas indevidamente ou foram rotacionadas antes que os invasores pudessem utilizá-las.

O que a Ars Technica diz que os dados vazados revelam

O desenvolvimento mais recente não é outro pacote comprometido, mas evidências que sugerem que a invasão original foi muito além das estimativas iniciais.

De acordo com o relatório sobre a exposição de credenciais, pesquisadores de segurança examinaram uma vasta coleção atribuída aos invasores. O material supostamente continha segredos associados a mais de 2.500 organizações.

A coleção incluía chaves de acesso à nuvem, tokens de repositórios de código-fonte, chaves SSH, segredos do Kubernetes, variáveis de ambiente, credenciais de publicação de pacotes e chaves de provedores de IA. São credenciais operacionais, não apenas nomes de contas coletados de um diretório público.

Uma chave de nuvem exposta pode conceder acesso à infraestrutura hospedada. Um token de repositório pode revelar código-fonte privado ou permitir alterações não autorizadas. Uma credencial de publicação de pacote pode permitir que um invasor distribua software malicioso em nome de um projeto confiável.

Os segredos do Kubernetes criam outro caminho. O Kubernetes é um sistema para gerenciar aplicações conteinerizadas, e suas contas de serviço podem ter amplas permissões de infraestrutura. Um token roubado com privilégios excessivos pode ajudar um invasor a passar de uma carga de trabalho para um cluster inteiro.

Os pesquisadores também associaram os dados a aproximadamente 434.000 registros de integração e entrega contínuas. Os pipelines de CI/CD automatizam testes, compilação e implantação de software, muitas vezes carregando temporariamente credenciais na memória.

Esse número não deve ser interpretado como 434.000 violações confirmadas. Uma organização pode operar muitos jobs, runners, repositórios e execuções repetidas de pipelines. Registros duplicados também podem inflar as contagens em dados roubados durante várias etapas da campanha.

O conjunto de dados relatado foi vinculado a uma coleção de arquivos estimada em cerca de 195 TB. Seria enganoso descrever cada byte como uma credencial única. Essas coleções podem incluir arquivos de sistema duplicados, árvores de código-fonte, logs, arquivos compactados e capturas de memória, além de segredos.

A conclusão mais defensável diz respeito ao alcance, não à quantidade de credenciais. Os invasores parecem ter coletado dados de numerosos ambientes de desenvolvimento nos quais havia credenciais valiosas. O tamanho do material também dificulta a verificação e a notificação das vítimas.

A CloudSEK criou um serviço de exposição pesquisável que permite às organizações verificar se seus domínios aparecem no material analisado. Uma correspondência deve desencadear uma investigação, mas não é evidência conclusiva de que um invasor tenha entrado na rede da organização.

Da mesma forma, nenhuma correspondência deve oferecer pouco conforto se uma organização instalou um pacote afetado. Os conjuntos de dados podem estar incompletos, os domínios podem não constar em artefatos de máquinas, e a infraestrutura dos invasores pode falhar antes de registrar uma vítima.

Portanto, a reportagem muda a urgência do incidente sem resolver todas as questões. As organizações precisam de registros locais de instalação, telemetria de rede, logs de auditoria de nuvem e históricos de credenciais para estabelecer sua exposição real.

Um pacote de IA confiável se tornou o mecanismo de entrega

Comprometer o LiteLLM era perigoso porque ele normalmente opera ao lado das próprias credenciais que os invasores querem roubar.

O LiteLLM oferece uma interface comum para aplicações que chamam diferentes serviços de modelos de linguagem de grande porte. Em vez de manter integrações separadas, os desenvolvedores podem encaminhar solicitações por um proxy ou biblioteca Python.

Essa conveniência coloca o LiteLLM próximo de chaves de API para OpenAI, Anthropic, modelos hospedados em nuvem e outros provedores. Implantações em produção também podem acessar bancos de dados, plataformas de observabilidade, armazenamento em nuvem e serviços internos.

Os invasores publicaram as versões maliciosas 1.82.7 e 1.82.8 do LiteLLM no projeto real do PyPI em 24 de março de 2026. Não eram pacotes imitadores com nomes escritos incorretamente. Elas chegaram pelo canal de distribuição em que os usuários já confiavam.

A Wiz relatou que as versões apareceram aproximadamente às 8h30 UTC e que o PyPI colocou o projeto em quarentena às 11h25 UTC. Sua análise do pacote malicioso também identificou o LiteLLM em 36 por cento dos ambientes de nuvem observados pela Wiz.

A versão 1.82.7 ativava sua carga útil quando o software importava o código de proxy do LiteLLM ou iniciava o proxy. A versão 1.82.8 adicionava um arquivo de inicialização do Python chamado litellm_init.pth.

O Python processa arquivos .pth ao inicializar seu ambiente de pacotes do site. Consequentemente, o código malicioso poderia ser executado sempre que o Python fosse iniciado, mesmo que uma aplicação nunca importasse o LiteLLM naquela sessão.

Esse mecanismo enfraqueceu uma suposição comum sobre a exposição a dependências. Um desenvolvedor não precisava necessariamente executar um comando obviamente comprometido. Instalar a versão podia colocar um gancho de execução automática dentro do ambiente.

Em seguida, o malware buscava na memória, em variáveis de ambiente, diretórios de configuração, histórico de shell e locais comuns de credenciais. Ele criptografava o material coletado antes de enviá-lo para uma infraestrutura controlada pelos invasores que imitava o domínio legítimo do LiteLLM.

Os alvos de dados supostamente incluíam credenciais da AWS, Google Cloud e Microsoft Azure. O ladrão também procurava tokens do Kubernetes, configuração do Docker, senhas de bancos de dados, carteiras de criptomoedas, chaves privadas e segredos de CI/CD.

A investigação da campanha da Datadog recomenda tratar qualquer sistema que tenha instalado as versões afetadas como uma exposição completa de credenciais. Essa posição reflete o comportamento de coleta do malware, e não prova que todo segredo descoberto tenha chegado a um invasor.

Os mantenedores do LiteLLM disseram que as versões comprometidas foram removidas e as credenciais dos mantenedores foram rotacionadas. Eles também afirmaram que os usuários da imagem Docker do proxy não foram afetados porque suas dependências estavam fixadas.

Os mantenedores contrataram a Mandiant e suspenderam lançamentos enquanto revisavam repositórios e sistemas de compilação. Sua resposta pública vinculou o comprometimento da publicação a credenciais expostas durante o incidente anterior do Trivy.

Essas medidas de contenção reduziram novas infecções. Elas não poderiam recuperar dados já transmitidos nem invalidar automaticamente todas as credenciais roubadas. Portanto, a remediação precisava ir muito além de desinstalar o pacote.

O verdadeiro adversário é a automação confiável contra o acesso limitado

Este incidente contrapõe a velocidade da entrega automatizada de software ao princípio de segurança de que nenhuma dependência deve herdar credenciais irrestritas.

Os pipelines modernos de compilação obtêm código, ferramentas, contêineres e ações de muitos projetos externos. A automação torna os lançamentos repetíveis, mas cada dependência passa a fazer parte da fronteira efetiva de segurança da organização.

O Trivy ilustra o problema. É um scanner de segurança usado para encontrar vulnerabilidades em contêineres e artefatos de software. As equipes frequentemente concedem ampla visibilidade aos scanners porque a inspeção exige acesso ao código-fonte, registros e saídas de compilação.

Em 19 de março, os invasores comprometeram partes do ecossistema de lançamentos e GitHub Actions do Trivy. A Datadog relatou que componentes maliciosos extraíam a memória de runners hospedados pelo GitHub e procuravam locais comuns de credenciais.

Os invasores então parecem ter reutilizado o acesso roubado em outros projetos e sistemas de pacotes. A campanha alcançou ações e extensões relacionadas à Checkmarx antes que versões maliciosas do LiteLLM aparecessem no PyPI.

Essa sequência inverte o modelo de segurança habitual. Um scanner destinado a detectar software inseguro tornou-se uma fonte upstream de acesso que ajudou a comprometer outro pacote amplamente utilizado.

A campanha também demonstra por que um nome de pacote assinado ou oficial não pode resolver a questão da confiança. A presença autêntica em um registro confirma de onde veio um artefato. Ela não garante que a conta do publicador ou o pipeline de compilação continuasse seguro.

As atualizações automáticas aumentaram a tensão. As equipes frequentemente permitem que lançamentos de patch fluam rapidamente porque esperam que versões menores contenham correções compatíveis. Os invasores exploraram essa expectativa ao publicar versões maliciosas por meio de um projeto legítimo.

A fixação de versões pode desacelerar esse caminho, mas não é uma defesa completa. Uma equipe pode aprovar deliberadamente uma versão comprometida, especialmente quando sua identidade no registro e seu número de lançamento parecem normais.

A verificação criptográfica de hash oferece um controle mais forte porque verifica o artefato exato. No entanto, alguém precisa estabelecer qual hash é confiável antes da instalação. Copiar um hash malicioso do mesmo canal comprometido simplesmente preserva o ataque.

Espelhos privados de pacotes adicionam revisão e atraso antes que artefatos externos cheguem à produção. Eles também criam outro serviço sensível que precisa ser protegido, monitorado e mantido atualizado.

O controle mais profundo é o isolamento de credenciais. Uma dependência executada em um job de compilação deve receber apenas as permissões necessárias para aquela tarefa específica. Credenciais de curta duração devem expirar antes que cópias roubadas forneçam acesso duradouro.

A identidade de carga de trabalho substitui segredos estáticos por credenciais temporárias vinculadas a um job ou serviço. Essa abordagem reduz o valor de arquivos e variáveis de ambiente coletados de um runner comprometido.

As organizações também precisam de estágios de compilação separados. Um job de varredura raramente precisa de permissão para publicar pacotes, administrar contas de nuvem, acessar bancos de dados de produção e modificar repositórios não relacionados.

Muitos pipelines ainda combinam esses privilégios por conveniência. Quando um processo pode alcançar todos os serviços de implantação, uma dependência comprometida pode transformar uma atualização de software em um incidente de identidade em toda a organização.

O ataque ao LiteLLM não inventou essa fraqueza. Ele expôs o quanto ela cresce quando o middleware de IA fica entre aplicações, provedores de modelos, nuvens, bancos de dados e sistemas de observabilidade.

Por que desinstalar o LiteLLM não era suficiente

A remoção do pacote malicioso interrompeu uma via de execução, mas não revogou os segredos copiados enquanto aquele código estava ativo.

O roubo de credenciais cria um problema de resposta diferente da limpeza comum de malware. Uma máquina reconstruída pode eliminar uma porta dos fundos, mas o invasor ainda pode manter chaves válidas que funcionam a partir de outro sistema.

Todo ambiente afetado exige um inventário de credenciais. As equipes de segurança precisam identificar quais segredos estavam presentes na memória, em arquivos, variáveis de ambiente, históricos de shell e diretórios montados de contas de serviço durante a janela de exposição.

A rotação deve incluir chaves de acesso à nuvem, chaves de provedores de IA, senhas de bancos de dados, tokens de repositórios, chaves SSH, contas de serviço do Kubernetes, credenciais de registros de pacotes, segredos de webhook e materiais de assinatura.

A ordem importa. As equipes devem primeiro restringir acessos suspeitos, preservar evidências e criar identidades substitutas. Em seguida, podem atualizar serviços dependentes antes de invalidar as credenciais expostas, sem provocar indisponibilidades descontroladas.

Logs de auditoria em nuvem podem revelar se chaves roubadas foram usadas a partir de locais incomuns. Históricos de repositórios podem mostrar clonagens inesperadas, criação de tokens, alterações em fluxos de trabalho, atividade de lançamento ou mudanças de permissões.

Mantenedores de pacotes enfrentam uma responsabilidade adicional. Se um token de publicação estava presente em um runner infectado, todo pacote acessível por meio desse token precisa ser revisado. Os invasores podem esperar antes de explorar o acesso.

A técnica de persistência .pth também significa que as equipes devem inspecionar diretamente os ambientes Python. Desinstalar o LiteLLM pode não remover um arquivo de inicialização criado de forma independente em site-packages.

A linha do tempo pública do incidente recomenda verificar a presença de litellm_init.pth e rotacionar todas as credenciais presentes em sistemas afetados. Ela também identifica o endpoint controlado pelo invasor models.litellm.cloud.

Os defensores devem procurar nos logs de rede conexões com infraestrutura de comando conhecida. Também devem examinar registros de processos, inicializações incomuns de Python, criação de arquivos compactados e pods privilegiados inesperados do Kubernetes.

No entanto, a passagem de vários meses cria lacunas de visibilidade. Períodos curtos de retenção podem apagar registros de endpoints e de rede antes que uma investigação tardia comece.

Essa lacuna explica por que a divulgação relatada de dados importa agora. Uma organização que não encontrou nenhuma intrusão evidente em março pode obter uma nova pista se seu domínio aparecer no material recuperado.

Ainda assim, investigadores devem resistir a tratar uma ferramenta de consulta de pesquisadores como autoridade final. Correspondências de domínio podem vir de configurações públicas, código-fonte clonado, referências a fornecedores ou listas de clientes.

O erro oposto é igualmente arriscado. Uma empresa não deve descartar uma correspondência simplesmente porque não consegue provar imediatamente a exfiltração. Logs de credenciais, registros de instalação e arquivos de bloqueio de dependências podem fornecer evidências mais fortes.

As equipes também devem inspecionar instalações indiretas. Um desenvolvedor pode não se lembrar de ter selecionado o LiteLLM porque outro framework, ferramenta interna ou ambiente de teste introduziu o pacote.

Listas de materiais de software ajudam a rastrear essas relações. Uma lista de materiais registra os componentes e as versões incluídos em uma aplicação ou artefato de compilação.

Ainda assim, mesmo uma lista completa de componentes não consegue revelar quais credenciais estavam visíveis durante a execução. As evidências de dependência precisam ser combinadas com registros de identidade e acesso em tempo de execução.

Para desenvolvedores que precisam preservar notas de investigação, cronogramas de credenciais e decisões de remediação, uma base de conhecimento técnica pesquisável pode reduzir a fragmentação das evidências. Os próprios segredos sensíveis nunca devem ser copiados para notas gerais.

O que os números não comprovam

A escala relatada é alarmante, mas as evidências disponíveis não estabelecem 2.500 invasões de rede concluídas nem 195 TB de credenciais únicas.

A Ars Technica atribui o novo escopo à análise de pesquisadores de segurança. O comprometimento subjacente do pacote é corroborado de forma independente por múltiplas investigações técnicas e pela resposta dos mantenedores do LiteLLM.

A contagem posterior de vítimas depende de como os pesquisadores mapearam artefatos roubados para organizações. As reportagens públicas ainda não fornecem detalhes suficientes para reproduzir cada correspondência ou distinguir clientes, fornecedores, desenvolvedores e terceiros mencionados.

Um domínio corporativo pode aparecer no código-fonte sem provar que esse código veio do sistema do proprietário do domínio. Fixtures de teste, endereços de e-mail, metadados de dependências e documentação podem conter nomes externos.

Pesquisadores podem fortalecer a atribuição por meio de diversos sinais. Entre eles estão nomes de host internos, caminhos de repositórios privados, identificadores de contas em nuvem, tokens específicos da organização, nomes de runners e timestamps correspondentes.

Mesmo assim, “afetada” pode descrever várias condições. Uma organização pode ter executado malware, outra pode ter exposto uma chave já revogada, e uma terceira pode apenas aparecer em documentação copiada.

O número de 434.000 também exige contexto. Se representar arquivos, registros ou execuções de pipeline, não deve ser apresentado como um número equivalente de pipelines distintos comprometidos.

A coleta relatada de 195 TB merece cautela semelhante. Um arquivo bruto de roubo pode conter diretórios repetidos, grandes binários, arquivos de modelos, caches, repositórios de código-fonte e logs.

Chamar todos os 195 TB de “credenciais” comprime essas distinções em uma manchete dramática. Credenciais ocupam pouco espaço, enquanto os ambientes ao seu redor podem ser enormes.

O risco prático continua grave sem maximizar a linguagem. Um pequeno arquivo de texto contendo uma chave ativa de administrador de nuvem pode importar mais do que terabytes de artefatos de compilação não sensíveis.

Organizações nomeadas também precisam de tratamento justo. A presença em um conjunto de dados de exposição não estabelece negligência, comprometimento contínuo ou roubo de dados de seus sistemas de produção.

Algumas organizações listadas podem ter rotacionado credenciais durante a resposta original. Outras podem ter fornecido nomes ou domínios que apareceram no ambiente de um fornecedor, e não no seu próprio.

A posse e o uso do conjunto de dados pelos invasores continuam sendo questões separadas. Pesquisadores teriam obtido ou analisado material ligado à campanha, mas as evidências públicas não mostram em que extensão cada credencial foi explorada.

A validade das credenciais muda ao longo do tempo. Tokens temporários podem expirar em minutos, enquanto chaves SSH antigas e credenciais estáticas de API podem permanecer funcionais por meses ou anos.

A incerteza mais relevante diz respeito a segredos de longa duração. Se as organizações expostas rotacionaram apenas chaves de IA óbvias, os invasores poderiam manter acesso por meio de tokens de implantação esquecidos ou contas de serviço.

A divulgação deve, portanto, ser tratada como uma pista de investigação sustentada por um evento de malware confirmado. Ela não deve se tornar um veredito final de violação para cada domínio no conjunto de dados.

Esse enquadramento equilibrado evita duas falhas. Ele impede que uma contagem exagerada de vítimas ultrapasse as evidências e impede que a incerteza se torne uma desculpa para a inação.

Três sinais mostrarão se a crise está contida

A próxima fase depende da rotação de credenciais, de descobertas de vítimas verificadas de forma independente e de mudanças mensuráveis na segurança de publicação de pacotes.

O primeiro sinal é evidência de abuso de credenciais após a janela de contenção de março. Provedores de nuvem, registros de pacotes e organizações afetadas devem divulgar se identidades roubadas permitiram acessos posteriores.

O uso confirmado de tokens de publicação inativos fortaleceria o argumento de que a campanha criou uma ameaça duradoura à cadeia de suprimentos. A ausência de uso observado reduziria a preocupação imediata, mas apenas quando a cobertura de auditoria for adequada.

O segundo sinal é a validação independente do conjunto de dados de exposição. Mais organizações devem comparar as correspondências dos pesquisadores com logs de instalação, identificadores de nuvem e telemetria de rede.

Confirmações consistentes sustentariam a escala relatada. Correspondências falsas disseminadas ou registros duplicados reduziriam o impacto estimado sem alterar o comprometimento confirmado do LiteLLM.

O terceiro sinal é a adoção de controles mais seguros de publicação e execução. O modelo de publicação confiável do PyPI usa tokens de identidade de curta duração em vez de credenciais reutilizáveis de upload.

A análise mais ampla da cadeia de suprimentos recomenda publicação confiável, verificação de hash de artefatos, contas de serviço restritas e monitoramento de arquivos inesperados de inicialização do Python. O documento identifica o middleware de IA como um ponto de concentração para credenciais downstream.

Os desenvolvedores não devem esperar por uma lista perfeita de vítimas. Qualquer pessoa que tenha instalado o LiteLLM 1.82.7 ou 1.82.8 deve tratar esse ambiente como exposto e verificar se todas as credenciais acessíveis foram alteradas.

As equipes de segurança também devem revisar a exposição relacionada ao Trivy a partir de 19 de março. A cadeia da campanha começou antes de as versões maliciosas do LiteLLM aparecerem, e concentrar-se em um único pacote pode deixar passar o comprometimento upstream.

Organizações que não encontrarem versões afetadas ainda devem examinar sua política de dependências. O próximo pacote contaminado não necessariamente usará LiteLLM, Python ou o mesmo mecanismo de persistência.

A lição central da reportagem da Ars Technica é mais restrita e acionável do que seus números enormes sugerem. A automação confiável colocou identidades valiosas ao lado de código de terceiros, e uma cadeia comprometida alcançou muitos sistemas.

Faça uma pergunta concreta hoje: qual pacote externo consegue ler suas credenciais de compilação mais privilegiadas? Se a resposta não estiver clara, mapeie esse acesso antes que a próxima atualização rotineira transforme confiança oculta em um incidente.