Os gateways de IA tornam-se a superfície de ataque — a entrada do LiteLLM no KEV e o caminho por chaves, MCP e a nuvem
O bypass de autenticação MCP do BerriAI LiteLLM (CVE-2026-59822) entrou no catálogo KEV da CISA, e a Microsoft relata atacantes a usar gateways LiteLLM para entregar o XMRig. A pesquisa da Wiz encontrou cerca de 1 em 10 de ~3,000 instâncias públicas que aceitavam a chave padrão sk-1234 ou executavam sem autenticação. Examinamos o que significa a infraestrutura de IA ser um cofre de credenciais.
Este artigo foi traduzido por máquina.
Em setembro de 2026, a CISA adicionou o bypass de autenticação MCP do BerriAI LiteLLM, CVE-2026-59822, ao seu catálogo Known Exploited Vulnerabilities (KEV) (2 de setembro, conforme a linha do tempo da Wiz). A falha permite que um token Bearer arbitrário estabeleça uma sessão autenticada válida no endpoint MCP Streamable HTTP do LiteLLM, e surgiu ao lado de 6 outras falhas exploradas — incluindo SonicWall SMA 1000 e Sangoma Switchvox — na atualização do KEV do início de setembro (conforme The Hacker News). O LiteLLM é um gateway de IA de código aberto que guarda as chaves de API de cada fornecedor de LLM configurado; pela estimativa da Wiz, está presente em cerca de um terço dos ambientes de nuvem.
O relato factual: (1) A pesquisa da Wiz (publicada em 9 de setembro) encontrou que, de cerca de 3,000 instâncias LiteLLM expostas à internet, cerca de 9.6% aceitavam a chave mestra padrão sk-1234 ou não exigiam autenticação alguma. Nas instâncias sem autenticação configurada, cada usuário recebia PROXY_ADMIN por padrão, e chegava à funcionalidade de admin sem credenciais (corrigido desde então). (2) Com direitos de admin, um atacante pode usar a funcionalidade de endpoint pass-through para fazer proxy de pedidos para URLs internas arbitrárias — incluindo o serviço de metadados da AWS — e o mecanismo de encaminhamento de cabeçalhos x-pass- anula o requisito de session token do IMDSv2, o que permite o roubo de credenciais IAM da nuvem. (3) Em setembro, a Microsoft relatou atacantes a encadear CVE-2026-42271 e CVE-2026-48710 (o bypass de autenticação 'BadHost' do Starlette) para entrar em gateways LiteLLM e entregar um miner XMRig por meio de um binário ELF (conforme The Hacker News). Os ataques a instâncias RAGFlow expostas, por sua vez, produziram chaves de fornecedores de LLM e metadados roubados, e não ransomware.
Análise (separada do relato factual): o que estas histórias mostram é que os gateways de IA ultrapassaram a fase de 'LLMjacking' — gastar o orçamento de API de outrem — e tornaram-se um caminho de intrusão na nuvem propriamente dito. O LiteLLM executa Python no lado do servidor em cada pedido de inferência, pode fazer proxy de pedidos para URLs internas arbitrárias e liga-se a ferramentas externas via MCP. Não é apenas um cofre de chaves; é uma ponte para a rede interna, com capacidade de execução. Ativos que a defesa prefere resguardar sob um princípio de desenho do tipo 'é IA, mantenha-se interno' tornam-se, para os atacantes, um caminho de várias etapas até chaves, IAM e APIs internas, por trás de um único bypass de autenticação. A lacuna estrutural entre padrões pensados para a experiência do desenvolvedor (sk-1234, PROXY_ADMIN quando não configurado) e a implantação em produção merece ser nomeada como tal.
Implicações defensivas: (1) Se executar LiteLLM, atualize primeiro para v1.84.0 ou posterior (correção de CVE-2026-59822) e para v1.83.7 ou posterior (correção de CVE-2026-42271), além de Starlette 1.0.1 ou posterior; confirme que a chave mestra padrão foi alterada e que a instância não está exposta à internet. (2) Faça a rotação de todas as chaves de API de fornecedores armazenadas, como se estivessem comprometidas no momento em que a exposição for confirmada, e defina limites de gasto para limitar o dano quando uma chave sair. (3) Trate as funcionalidades que implicam execução arbitrária de código ou proxy de URL arbitrária — MCP, endpoints pass-through — como permissões ao nível do agente, a inventariar à parte e a desativar por padrão. (4) Audite outros gateways de IA e orquestradores de LLM com a mesma lente: credenciais padrão, funcionalidade de admin exposta, proxy de URL interna. Isto é análise nossa, não orientação de fornecedor.
Os dados factuais deste artigo são extraídos em primeiro lugar da pesquisa da Wiz (https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise), da release de correção do BerriAI LiteLLM (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable) e do catálogo KEV da CISA (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), com a cobertura de The Hacker News como fonte secundária (https://thehackernews.com/2026/09/cisa-adds-5-actively-exploited.html e https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html); a data de 2 de setembro no KEV segue a linha do tempo da Wiz. As partes de análise são mantidas separadas do relato factual. Note-se que as contagens de instâncias e a parcela dos ambientes de nuvem são estimativas que dependem do momento e do método de medição.