O Primeiro Ataque à Cadeia de Suprimentos de Gateway de IA: Brecha no LiteLLM Atinge Startup de $10B

Em fevereiro, escrevemos sobre o Clinejection, um ataque à cadeia de suprimentos que transformou o título de uma issue no GitHub em malware em 4.000 máquinas de desenvolvedores. Na análise seguinte, rastreamos a cadeia de ataque em cinco etapas e perguntamos quantas outras pipelines mediadas por IA tinham as mesmas fragilidades.

Agora temos a resposta. Milhares.

Em 31 de março de 2026, um grupo chamado TeamPCP comprometeu o pacote npm do LiteLLM. O LiteLLM é um gateway de IA open-source, baixado milhões de vezes por dia, que funciona como camada intermediária entre aplicações e APIs de LLMs da OpenAI, Anthropic e dezenas de outros provedores. O código malicioso ficou ativo tempo suficiente para que o Lapsus$ exfiltrasse dados de pelo menos um alvo relevante: a Mercor, uma startup de recrutamento por IA avaliada em $10 bilhões, com $350 milhões captados em rodada Série C liderada pela Felicis Ventures.

Os dados vazados incluíam mensagens do Slack, conteúdo de sistemas de tickets e vídeos de conversas entre sistemas de IA e contratados humanos. A Mercor processa mais de $2 milhões em pagamentos diários para treinadores de IA que trabalham com OpenAI e Anthropic. A conexão entre TeamPCP e Lapsus$ ainda não está clara, mas o resultado está: o comprometimento de um gateway de IA deu aos atacantes acesso a um dos nós mais sensíveis da cadeia de suprimentos de treinamento de IA.

Por Que um Gateway de IA Não É Só Mais um Pacote npm

O Clinejection foi um ataque de pipeline de build. O componente comprometido ficava no ambiente de CI/CD. Desenvolvedores foram afetados, mas o raio de explosão era limitado a quem instalou uma ferramenta CLI específica.

O LiteLLM ocupa uma posição fundamentalmente diferente. Um gateway de IA é uma camada de proxy. Todo prompt que sua aplicação envia a um LLM passa por ele. Toda resposta volta por ele. Toda chave de API está armazenada nele ou trafega por ele. Comprometa essa camada e você obtém três coisas simultaneamente: todos os prompts (incluindo dados proprietários, informações de clientes e instruções internas), todas as respostas (incluindo código gerado, análises e decisões) e todas as chaves de API (que dão acesso direto aos provedores de LLM).

O risco aqui não é da mesma classe que uma biblioteca utilitária comprometida. Um left-pad envenenado quebra seu build. Um gateway de IA envenenado lê seus pensamentos.

A superfície de ataque escala com a adoção. O LiteLLM reporta milhões de downloads diários. Toda organização que o utilizava roteou suas interações de IA mais sensíveis por uma única dependência open-source. Quando essa dependência foi comprometida, o atacante herdou a posição de confiança de toda aplicação atrás do gateway.

Mesmo Dia, Outro Pacote

No mesmo dia do comprometimento do LiteLLM, a Socket Security reportou que o Axios, uma das bibliotecas de cliente HTTP mais populares do ecossistema npm, também havia sido comprometido. Uma dependência maliciosa foi inserida em várias versões do Axios no npm, adicionando capacidade de trojan de acesso remoto. Hackers norte-coreanos foram apontados como responsáveis.

Dois ataques de cadeia de suprimentos npm de grande porte em um único dia. Um mirando infraestrutura específica de IA. Outro mirando infraestrutura de uso geral. Ambos usando o mesmo vetor: comprometa o pacote, herde a confiança.

A diferença está no que o atacante ganha. Comprometer o Axios dá interceptação de requisições HTTP. Comprometer um gateway de IA dá a camada cognitiva completa de toda aplicação que está por trás dele. Os prompts contêm a lógica de negócio. As respostas contêm as decisões. As chaves de API abrem os provedores. É um alvo qualitativamente mais rico que qualquer biblioteca tradicional.

Teatro de Compliance, Documentado

Um detalhe do incidente Mercor merece seção própria.

Após a brecha, o LiteLLM trocou de provedor de compliance, saindo da Delve para a Vanta. Isso é revelador. Não porque a Vanta seja melhor ou pior que a Delve. Porque a troca em si diz o que o compliance estava fazendo antes do ataque: não o suficiente.

Certificações de compliance (SOC 2, ISO 27001 e variantes) auditam se você tem processos de segurança. Elas não auditam se suas dependências npm contêm código malicioso. Verificam se você tem uma política de gerenciamento de vulnerabilidades. Não verificam se um script postinstall malicioso pode exfiltrar suas chaves de API para o servidor de um atacante entre ciclos de auditoria.

A Mercor era “uma de milhares de empresas” afetadas pelo comprometimento do LiteLLM, segundo reportagem do TechCrunch. Cada uma dessas empresas pode ter tido certificação SOC 2. Cada uma estava vulnerável mesmo assim.

Trocar de fornecedor de compliance após um ataque de cadeia de suprimentos é como trocar de seguradora após um acidente de carro. Atende uma necessidade administrativa real. Não faz nada quanto às condições da estrada que causaram o acidente.

Da Teoria à Contagem de Vítimas

Quando analisamos o Clinejection em fevereiro e março, descrevemos ataques à cadeia de suprimentos de IA como uma nova categoria com uma prova de conceito. A cadeia de ataque estava documentada. O playbook era público. Escrevemos: “O próximo atacante não precisa inventar nada. Só precisa encontrar um alvo que ainda não aplicou as lições.”

O ataque ao LiteLLM confirma o padrão, mas eleva a gravidade. O Clinejection comprometeu uma ferramenta de build. O LiteLLM comprometeu a camada de inferência em tempo de execução. O Clinejection afetou 4.000 máquinas de desenvolvedores. O LiteLLM afetou milhares de aplicações em produção. O payload do Clinejection era benigno (OpenClaw). O comprometimento do LiteLLM levou à exfiltração de dados de uma empresa avaliada em $10 bilhões.

A trajetória de escalada é clara. O primeiro ataque à cadeia de suprimentos de IA foi uma prova de conceito com payload inofensivo. O segundo mirou a camada de inferência e resultou em roubo real de dados. O terceiro será pior, porque o playbook continua melhorando enquanto as defesas não acompanham.

A Cadeia de Suprimentos de IA Tem Três Camadas

Segurança tradicional de cadeia de suprimentos de software foca em dependências. Você audita seus pacotes. Verifica checksums. Fixa versões. Isso é necessário e insuficiente para sistemas de IA.

Cadeias de suprimentos de IA têm três camadas que cadeias tradicionais não têm.

A camada de modelo. De onde vem seu modelo? Quem o treinou? Que dados foram usados? Se você usa uma API hospedada, está confiando no pipeline inteiro do provedor. Cobrimos isso em Seu Provedor de IA É um Risco na Cadeia de Suprimentos.

A camada de gateway. Como os prompts chegam ao modelo? O que fica entre sua aplicação e a API? LiteLLM, LangChain, camadas de proxy customizadas, plataformas de gerenciamento de API. É aqui que o ataque ao LiteLLM operou. É a camada que a maioria das organizações nunca auditou porque parecia “só mais uma dependência.”

A camada de agente. O que seus sistemas de IA podem fazer? A que ferramentas têm acesso? Que credenciais estão disponíveis no ambiente de execução? É aqui que o Clinejection operou. O bot de triagem tinha acesso a credenciais de build que não precisava.

A maioria das organizações começou a pensar na camada um (risco de modelo). Quase nenhuma auditou a camada dois (risco de gateway). E como documentamos em nossa cobertura do Clinejection, a camada três (risco de agente) permanece em grande parte sem exame.

A brecha no LiteLLM é uma função forçante. Prova que a camada de gateway é um alvo de alto valor. Prova que “baixado milhões de vezes por dia” não equivale a segurança. Prova que a confiança depositada em um gateway de IA é a confiança que um atacante herda ao comprometê-lo.

O Que Isso Exige

Audite suas dependências de gateway de IA. Se você usa LiteLLM, LangChain ou qualquer camada de proxy entre sua aplicação e APIs de LLM, trate como infraestrutura crítica. Fixe versões. Verifique checksums. Monitore atualizações inesperadas de pacotes. Não atualize automaticamente dependências de gateway de IA em produção.

Rotacione chaves de API por cronograma, não após incidentes. Toda organização afetada pelo comprometimento do LiteLLM agora precisa rotacionar cada chave de API que passou pelo gateway. Se você estivesse rotacionando chaves mensalmente, a janela de exposição seria limitada. A maioria das organizações rotaciona chaves de API de LLM nunca.

Separe credenciais de IA das credenciais de aplicação. Chaves de API de LLM não devem ficar no mesmo cofre de segredos, com as mesmas políticas de acesso, que suas credenciais de banco de dados. O raio de explosão de um comprometimento de gateway de IA não deve se estender à infraestrutura inteira.

Avalie se você realmente precisa de um gateway. A proposta de valor do LiteLLM é abstrair múltiplos provedores de LLM. Se você usa um provedor só, não precisa dessa camada de abstração. Cada dependência que você remove é uma superfície de ataque eliminada. Simplicidade é estratégia de segurança.

Pare de tratar compliance como segurança. SOC 2 não preveniu essa brecha. Nunca foi projetado para isso. Compliance informa seus clientes que você tem processos. Segurança é se esses processos de fato previnem ataques. São coisas diferentes. Tratar como equivalentes é o caminho para acabar trocando de fornecedor de compliance após uma brecha em vez de corrigir a classe de vulnerabilidade que a causou.

O Padrão Está Acelerando

Fevereiro: Clinejection. Prova de conceito. Payload benigno. 4.000 desenvolvedores afetados.

Março: LiteLLM. Ataque em produção. Exfiltração de dados. Milhares de empresas afetadas. $10 bilhões em valuation expostos. Axios comprometido no mesmo dia.

O intervalo entre incidentes está diminuindo. A severidade está aumentando. A superfície de ataque está crescendo conforme mais organizações adotam gateways de IA, frameworks de agentes e camadas de proxy sem tratá-los como a infraestrutura crítica que são.

O código malicioso no LiteLLM foi removido “em questão de horas.” Horas é rápido para resposta a incidentes. Horas é uma eternidade quando cada prompt e chave de API que trafega pelo gateway está sendo interceptado.

Sua cadeia de suprimentos de IA não é algo para auditar um dia qualquer. É a dependência mais sensível da sua stack, carregando seus prompts proprietários, dados de clientes e credenciais de provedor por código que você não escreveu e provavelmente nunca leu.

Trate de acordo.

Fontes

TechCrunch. “Mercor cyberattack report.” Março 2026.
Socket Security. “Axios npm compromise.” Março 2026.

A Victorino ajuda organizações a auditar e governar dependências na cadeia de suprimentos de IA: contato@victorino.com.br | www.victorino.com.br