CISA adiciona à KEV o bypass de autenticação MCP do LiteLLM: qualquer token Bearer bastava

Em 2 de setembro de 2026, a U.S. Cybersecurity and Infrastructure Security Agency adicionou o CVE-2026-59822 ao seu catálogo Known Exploited Vulnerabilities como a "BerriAI LiteLLM Improper Authentication Vulnerability", uma entre sete falhas do lote daquele dia. O bug está no endpoint MCP Streamable HTTP do LiteLLM: quando a validação de uma chave do LiteLLM falhava, o fallback de passthrough OAuth2 substituía um objeto UserAPIKeyAuth() vazio em vez de rejeitar a requisição, de modo que qualquer cabeçalho Authorization Bearer forjado abria uma sessão MCP autenticada. Um atacante que alcançasse esse endpoint poderia listar e chamar todas as ferramentas MCP com as quais o gateway estava configurado e, por meio dessas ferramentas, alcançar os serviços por trás delas. Todas as versões anteriores à 1.84.0 são afetadas, e as agências civis federais receberam até 16 de setembro para corrigir. Este registro — a listagem no KEV para o bypass de autenticação MCP do LiteLLM — é uma entrada em o OrcaRouter AI Incident Archive, que contém o conjunto completo de registros e as entradas vizinhas deste incidente.

A razão pela qual uma vulnerabilidade num proxy importa mais do que a sua pontuação CVSS sugere é o que está por trás do proxy. A equipa de investigação de ameaças da Wiz é direta: "Um proxy LiteLLM pode armazenar chaves para todos os fornecedores de modelos para os quais encaminha tráfego, incluindo OpenAI, Anthropic, Azure e Gemini. Também pode ser executado com permissões IAM na nuvem e ligar-se a serviços internos através de servidores de ferramentas MCP. Um único comprometimento pode dar a um atacante acesso às credenciais e aos serviços a jusante do proxy, e não apenas ao próprio proxy." A Wiz Research afirma ter descoberto a falha, e os honeypots da Wiz registaram posteriormente tentativas de a explorar.

O mecanismo: uma verificação falha que retornou uma sessão válida

O próprio aviso da BerriAI, GHSA-7488-6r32-c95q, descreve o defeito em duas frases: "O manipulador de autenticação MCP suportava passagem direta de OAuth2 para servidores MCP upstream, mas o caminho alternativo podia substituir a validação malsucedida da chave LiteLLM por um objeto UserAPIKeyAuth() vazio. Isso permitia que requisições com um cabeçalho Authorization fabricado alcançassem as ferramentas MCP sem uma chave LiteLLM válida." A palavra importante é alternativa. O código tinha uma ramificação para implantações que repassam diretamente o token OAuth de um servidor MCP upstream e, quando uma chave LiteLLM falhava na validação, essa ramificação retornava um objeto de autenticação vazio em vez de um erro.

Um objeto de autenticação vazio não é o mesmo que nenhum objeto de autenticação. O código downstream via um UserAPIKeyAuth construído com sucesso e prosseguia, sem tenant, sem usuário e sem escopo associado a ele. A análise da Wiz é mais direta sobre a consequência prática: "quando a validação do token falha, em vez de rejeitar a solicitação, o servidor retorna um objeto UserAPIKeyAuth() vazio, sem restrições. Qualquer token Bearer (até mesmo um único caractere, por exemplo, x) concede acesso total ao MCP."

O que isso proporciona a um atacante é um menu. O protocolo MCP expõe uma listagem de ferramentas, de modo que uma sessão que se autentica retorna os nomes e esquemas de todas as ferramentas que o gateway foi configurado para alcançar — bancos de dados, repositórios de código, APIs internas, nos exemplos da Wiz. O aviso do fornecedor declara o efeito de forma clara: "Um atacante poderia usar isso para listar e chamar ferramentas MCP configuradas e acessar serviços conectados expostos por meio do MCP." As chamadas de ferramentas então são executadas com qualquer autoridade que o próprio proxy detenha em relação a esses backends, que é o problema de concentração de credenciais descrito pela Wiz.

Uma correção em maio, uma CVE em julho, um prazo federal em setembro

As datas não se alinham da forma que um leitor poderia supor, e as lacunas são a parte interessante. O LiteLLM 1.84.0 — a primeira versão que o aviso indica como corrigida — foi enviado ao PyPI em 14 de maio de 2026, de acordo com os próprios metadados de lançamento do índice de pacotes. O identificador CVE foi reservado junto ao CVE Program em 7 de julho de 2026, e o registro foi publicado no dia seguinte, 8 de julho; a entrada OSV PYSEC-2026-3479 veio em 23 de julho. A inclusão na lista KEV veio em 2 de setembro, com prazo de correção em 16 de setembro.

Duas coisas se seguem. Primeiro, a compilação corrigida ficou pública por mais de três meses antes de a CISA listar a falha como explorada — portanto, as organizações vinculadas ao prazo tinham uma atualização funcional disponível o tempo todo, e a inclusão na KEV não foi o momento em que surgiu uma correção. Segundo, a diferença de versões aumentou desde então: a versão atual do LiteLLM no PyPI é 1.106.5, enviada em 27 de outubro de 2026. Uma implantação que ainda esteja em qualquer versão abaixo de 1.84.0 agora está mais de vinte versões menores atrasada, e não apenas uma correção atrás.

O que a listagem estabelece, e o que não estabelece

O alerta da CISA para o lote afirma que as adições são feitas "com base em evidências de exploração ativa", e a entrada legível por máquina do catálogo para CVE-2026-59822 traz data de inclusão de 2 de setembro de 2026, prazo de 16 de setembro de 2026, valor de uso conhecido em campanhas de ransomware "Unknown" e duas fraquezas: CWE-287 (autenticação imprópria) e CWE-306 (autenticação ausente para uma função crítica).

• Estabelecido: A CISA avaliou a falha como ativamente explorada e a incluiu na lista federal de remediação. O registro SSVC do NVD, atribuído a um Coordenador da CISA e com data de 2 de setembro de 2026, registra a exploração como "ativa", a automatização como "sim" e o impacto técnico como "parcial".

• Estabelecido:foi observada exploração em um ambiente controlado. A Wiz publicou tráfego de honeypot mostrando requisições com tokens de um único caractere sondando um endpoint de enumeração de modelos: um GET para /v1/models carregando "Authorization: Bearer x". O The Hacker News, ao noticiar o lote KEV em 3 de setembro, descreveu a mesma atividade como a Wiz observando "esforços de exploração envolvendo CVE-2026-59822 contra seus honeypots para sondar endpoints de enumeração de modelos."

• Estabelecido: as pontuações de gravidade existem e diferem conforme o framework. O aviso da BerriAI classifica a falha como CVSS 4.0 em 8,8, alta, com confidencialidade alta, integridade baixa e disponibilidade nenhuma; a avaliação CVSS 3.1 do próprio NIST, que é primária no NVD, a coloca em 8,2. Os dois números descrevem o mesmo defeito sob sistemas de pontuação diferentes e não devem ser comparados como se um substituísse o outro.

• Não estabelecido: nenhuma vítima nomeada. Nem o alerta da CISA, nem o aviso da BerriAI, nem a análise da Wiz, nem a cobertura do The Hacker News identificam uma organização cujas ferramentas MCP tenham sido acessadas por meio dessa falha, ou relatam credenciais ou dados obtidos de uma. O registro público de exploração é telemetria de honeypot e uma determinação federal, não uma violação divulgada.

• Não estabelecido: que nenhum grupo de ransomware o utilize. O campo KEV exibe "Unknown", que é um valor atribuído pela CISA, e não uma constatação de ausência em qualquer sentido.

O precedente de junho, e a cadeia de execução remota de código que isto não é

Esta é a segunda falha do LiteLLM a chegar ao catálogo KEV em 2026, e a anterior é fácil de confundir com ela. A CVE-2026-42271, adicionada em 8 de junho de 2026 com prazo de 22 de junho, é uma injeção de comando nos endpoints de teste do servidor MCP do LiteLLM: a Wiz descreve endpoints que permitem a um usuário testar uma configuração de servidor MCP antes de salvá-la, com o campo command passado para execução de subprocesso sem validação. Atacantes enviaram uma configuração falsa de servidor stdio cujo comando baixou e executou um minerador de criptomoedas, e retornaram um handshake MCP de aparência válida para que o teste parecesse bem-sucedido. A entrada da CISA para ela lista CWE-78 e CWE-77 — injeção de comando e de argumentos, não autenticação.

Essa falha é a que permite o encadeamento. A Wiz afirma que a CVE-2026-42271 "pode ser encadeada com um bypass de validação do cabeçalho Host do Starlette (CVE-2026-48710) para alcançar RCE totalmente não autenticado", e que pesquisadores externos ligaram o grupo de ransomware Qilin à exploração ativa dessa cadeia. A CVE-2026-48710 foi adicionada ao catálogo KEV no mesmo lote de 2 de setembro que o bypass do LiteLLM, com o mesmo prazo de 16 de setembro, e a nota do próprio catálogo da CISA sobre a falha do Starlette diz que ela poderia ser encadeada com a CVE-2026-42271. O vínculo com o Qilin pertence a esse pareamento. Não se trata de uma descoberta sobre a CVE-2026-59822, e nada nas fontes revisadas conecta o grupo de ransomware ao bypass de autenticação.

Um detalhe administrativo separa as duas entradas do LiteLLM: a ação exigida na listagem de junho cita a BOD 22-01, a diretiva operacional vinculante mais antiga, enquanto a listagem de setembro cita a BOD 26-04, “Prioritizing Security Updates Based on Risk”. O alerta da CISA não explica a mudança, e o catálogo não faz nenhuma anotação sobre isso.

O que mudou depois

O caminho de remediação é curto. O aviso do BerriAI recomenda atualizar para a 1.84.0 ou posterior e oferece uma solução alternativa para equipes que não podem migrar imediatamente: "desative as rotas MCP ou bloqueie o acesso a /mcp/ e aos endpoints MCP relacionados no seu proxy reverso ou gateway de API." Essa solução alternativa é um instrumento contundente — ela remove a capacidade em vez de restringi-la — mas é a única mitigação que o fornecedor indica para implantações sem patch.

O texto de ação obrigatória da CISA relativo aos pontos de entrada coloca as agências federais perante o mesmo dilema: aplicar as mitigações de acordo com as instruções do fornecedor e em conformidade com a BOD 26-04, "ou descontinuar a utilização do produto se as mitigações não estiverem disponíveis", cabendo a cada agência avaliar a exposição à internet de um ativo. A diretiva é vinculativa apenas para as agências federais do poder executivo civil; a CISA incentiva outras organizações a adotar a mesma priorização baseada no risco, sem que tal seja obrigatório.

Não se sabe publicamente se alguém fora de um honeypot agiu dentro do prazo. Nem a CISA nem a BerriAI publicaram números sobre quantas implantações do LiteLLM ficaram expostas, quantas foram corrigidas antes de 16 de setembro ou quantas foram atingidas por meio do bypass.

O que permanece em aberto

Vale mencionar três lacunas em vez de mascará-las. Não há relatório público de incidente que vincule o CVE-2026-59822 a uma intrusão específica, então a listagem no KEV se baseia nas evidências de exploração da CISA e nas observações de honeypot da Wiz, e não em uma vítima documentada. Não há declaração do fornecedor sobre como o caminho de fallback acabou sendo escrito dessa forma, nem por quanto tempo ele existiu antes da 1.84.0 — o avisório descreve o defeito e sua correção, não seu histórico. E os prazos do lote não eram uniformes: cinco das sete entradas adicionadas em 2 de setembro tinham prazo de 5 de setembro, enquanto as entradas LiteLLM e Starlette tinham 16 de setembro. A CISA não diz por quê.

O que está estabelecido é mais restrito e mais útil do que a pontuação. Um único caractere em um cabeçalho Authorization era, nas versões afetadas, indistinguível de uma chave válida para o endpoint MCP — e as versões que se comportavam assim deixaram de ser atuais em maio de 2026.