CVE-2026-42208 afeta verificações de chaves no proxy do LiteLLM e foi explorada em menos de 36 horas para consultar tabelas ligadas a credenciais e configuração do ambiente.
| Componente | Proxy do LiteLLM, pacote Python da BerriAI usado como gateway de IA para centralizar acesso a provedores de LLM. |
| Vetor | Cabeçalho Authorization especialmente construído enviado sem autenticação a rotas de API de LLM, como POST /chat/completions, alcançando a consulta vulnerável pelo caminho de tratamento de erro do proxy. |
| Impacto | Injeção SQL com possibilidade de leitura do banco do proxy e possível modificação de dados, incluindo acesso não autorizado ao proxy e às credenciais gerenciadas por ele. |
| Prioridade | Atualizar para 1.83.7-stable ou versão mais recente; quando a atualização imediata não for viável, definir disable_error_logs: true em general_settings para remover o caminho vulnerável descrito pelos mantenedores. |
| Versão corrigida | A correção foi disponibilizada em 1.83.7-stable, lançada em 19 de abril de 2026. |
| Artefatos | Tabelas observadas na atividade: litellm_credentials.credential_values e litellm_config; rota exemplificada: POST /chat/completions; advisory relacionado: GHSA-r75f-5x8p-qvmc. |
| IoCs | Tentativas associadas aos endereços 65.111.27[.]132 e 65.111.25[.]67. |
| Exploração | A primeira tentativa registrada ocorreu em 26 de abril de 2026 às 16:17 UTC, cerca de 26 horas e 7 minutos após a indexação do aviso no GitHub Advisory Database global. |
A vulnerabilidade CVE-2026-42208 é uma injeção SQL crítica no proxy do LiteLLM, um gateway de IA de código aberto usado para concentrar chamadas a provedores de grandes modelos de linguagem. A falha recebeu pontuação CVSS 9.3 e está ligada ao processo de checagem de chaves de API do proxy. O problema ocorre porque uma consulta de banco usada durante a validação de chaves misturava o valor fornecido pelo chamador diretamente ao texto SQL, em vez de transmiti-lo como parâmetro separado. Essa condição transforma um dado vindo de requisição HTTP em parte da consulta executada contra o banco do proxy.
O vetor é relevante porque não exige autenticação prévia. Um atacante pode enviar um cabeçalho Authorization manipulado para uma rota de API de LLM, como POST /chat/completions, e alcançar a consulta vulnerável por meio do caminho de tratamento de erro do proxy. O impacto descrito inclui leitura de dados do banco do proxy e possível alteração de registros. Como o LiteLLM pode concentrar credenciais de provedores de IA e informações do ambiente de execução, a exploração bem-sucedida não deve ser tratada como uma injeção SQL isolada de baixa consequência; o banco afetado pode conter material operacional usado para acessar serviços externos administrados pela organização.
A correção foi publicada na versão 1.83.7-stable, lançada em 19 de abril de 2026. A exploração foi observada rapidamente após a divulgação pública: a primeira tentativa registrada ocorreu em 26 de abril de 2026 às 16:17 UTC, aproximadamente 26 horas e 7 minutos depois que o aviso foi indexado no GitHub Advisory Database global, dentro de uma janela inferior a 36 horas. A vulnerabilidade também foi adicionada ao catálogo de vulnerabilidades exploradas conhecidas da CISA em 8 de maio de 2026, com prazo de correção para agências federais civis do Executivo dos Estados Unidos até 11 de maio de 2026.
O ponto central da falha está na composição da consulta executada durante a verificação de chaves do proxy. Em um fluxo seguro, o valor recebido no cabeçalho Authorization deveria ser tratado como dado e enviado ao mecanismo SQL por parâmetros vinculados. No comportamento vulnerável, esse valor é incorporado ao texto da consulta, permitindo que caracteres controlados pelo atacante alterem a estrutura lógica do SQL. Como o caminho afetado pode ser alcançado a partir de rotas comuns de API de LLM e por tratamento de erro, a exploração não depende de uma sessão válida já estabelecida no proxy.
A atividade observada teve duas fases conduzidas pelo mesmo operador em dois endereços de saída adjacentes, seguida por uma sondagem breve e não autenticada de endpoints de gerenciamento de chaves. Na primeira fase, a origem associada foi 65.111.27[.]132. Cerca de 20 minutos depois, uma segunda fase utilizou 65.111.25[.]67 para executar sondagem semelhante. O comportamento indicou conhecimento do esquema do banco, com uso de nomes de tabelas do Prisma, enumeração deliberada de quantidade de colunas e foco em três áreas específicas, sem depender de uma prova de conceito pública citada no material analisado.
As tabelas mencionadas na atividade foram litellm_credentials.credential_values e litellm_config. A primeira está relacionada a valores de credenciais, enquanto a segunda guarda informações de configuração do ambiente de execução do proxy. Não foram observadas sondagens contra litellm_users ou litellm_team, o que reduz a probabilidade de uma varredura totalmente genérica e reforça que o operador buscava dados de maior sensibilidade operacional. O risco condicionado pela exploração é o acesso não autorizado ao proxy e às credenciais que ele administra; quando essas credenciais representam chaves de provedores de LLM ou permissões em serviços integrados, o efeito prático pode se estender para fora da aplicação vulnerável.
A superfície exposta inclui instâncias do LiteLLM executando versões anteriores à correção 1.83.7-stable e acessíveis por rotas de API de LLM capazes de acionar o fluxo de validação de chaves. O contexto descreve explicitamente POST /chat/completions como exemplo de rota pela qual o cabeçalho Authorization manipulado pode alcançar a consulta vulnerável. Ambientes que publicam o proxy diretamente na internet, ou que o deixam acessível por redes internas amplas sem filtragem efetiva, têm maior chance de receber tentativas automatizadas após a indexação pública do aviso.
O ativo de maior valor não é apenas a aplicação web do proxy, mas o conjunto de segredos que ele centraliza. Uma única linha em litellm_credentials pode armazenar chaves de organizações em provedores de LLM, chaves administrativas de consoles ou credenciais IAM do AWS Bedrock, conforme descrito no contexto. Isso altera a priorização defensiva: a análise deve considerar tanto o estado da aplicação LiteLLM quanto a validade, o escopo e o uso recente das credenciais guardadas pelo proxy. Uma correção aplicada sem revisão desses segredos pode deixar material já consultado exposto para uso posterior.
Também há histórico recente de pressão sobre esse projeto: no mês anterior, o LiteLLM foi alvo de um ataque de cadeia de suprimentos atribuído ao grupo TeamPCP, voltado a roubar credenciais e segredos de usuários downstream. Esse ponto não muda o vetor de CVE-2026-42208, mas mostra que ambientes que usam o proxy como agregador de credenciais de IA já estavam dentro do interesse de operadores que buscam segredos reutilizáveis.
- Instâncias do LiteLLM anteriores à versão corrigida
1.83.7-stable. - Rotas de LLM API acessíveis sem autenticação efetiva antes do caminho vulnerável, incluindo o exemplo
POST /chat/completions. - Bancos do proxy contendo
litellm_credentials.credential_valueselitellm_config. - Ambientes em que o proxy guarda chaves de OpenAI, Anthropic, AWS Bedrock ou credenciais equivalentes citadas no material analisado.
A caça deve começar pelos logs HTTP do proxy e por registros de gateway, balanceador ou WAF posicionados antes do LiteLLM. O evento de maior interesse é a presença de cabeçalhos Authorization anômalos em requisições para rotas de LLM, especialmente quando associados a respostas de erro, falhas de autenticação, exceções de validação de chave ou aumento incomum de consultas ao banco. Como o caminho vulnerável passa pelo tratamento de erro, logs que normalmente seriam vistos apenas como ruído de autenticação podem conter o sinal inicial da exploração.
No banco de dados, a investigação deve procurar leituras incomuns ou tentativas de enumeração envolvendo litellm_credentials.credential_values e litellm_config. A ausência de acesso a litellm_users e litellm_team foi observada na atividade descrita, portanto a presença de consultas focadas em tabelas de credenciais e configuração, sem comportamento equivalente em tabelas de usuários e equipes, é um padrão compatível com o caso. Equipes devem correlacionar horário de requisições HTTP suspeitas, erros no proxy e consultas SQL geradas no mesmo intervalo.
A telemetria de identidade e provedores externos também precisa ser revisada, porque a leitura de credenciais pode ser suficiente para uso fora do host afetado. Devem ser verificados acessos recentes usando chaves administradas pelo LiteLLM, mudanças de permissões, picos de consumo, criação de recursos, uso a partir de localizações inesperadas e chamadas que não correspondam ao padrão normal da aplicação. A presença dos IPs 65.111.27[.]132 e 65.111.25[.]67 em logs de borda, proxy, WAF, aplicação ou banco deve ser tratada como evidência de tentativa associada ao episódio descrito.
- Requisições para
POST /chat/completionsou rotas equivalentes com cabeçalhoAuthorizationfora do padrão esperado. - Erros do proxy próximos a consultas de validação de chave e mensagens de exceção envolvendo banco de dados.
- Consultas ou erros SQL referenciando
litellm_credentials.credential_valueselitellm_config. - Atividade originada de
65.111.27[.]132ou65.111.25[.]67. - Uso recente e incomum de credenciais armazenadas no proxy, incluindo chaves de provedores de LLM e credenciais IAM do AWS Bedrock quando existirem no ambiente.
A primeira ação é atualizar o LiteLLM para 1.83.7-stable ou versão mais recente. A atualização deve ser acompanhada de validação operacional das rotas de API, porque o componente atua como intermediário de chamadas a provedores de LLM e falhas de implantação podem interromper integrações dependentes. Em ambientes com várias instâncias, a correção precisa cobrir todos os nós do proxy, imagens de contêiner, templates de infraestrutura, pipelines e ambientes de homologação que possam ser promovidos novamente para produção com uma versão vulnerável.
Quando a aplicação imediata do patch não for possível, a orientação dos mantenedores é configurar disable_error_logs: true em general_settings. Essa medida remove o caminho pelo qual entrada não confiável alcança a consulta vulnerável descrita, mas deve ser tratada como contenção temporária, não como substituição definitiva da atualização. Em paralelo, convém restringir exposição de rotas do proxy, aplicar controles de rede, revisar regras de WAF para padrões anômalos no cabeçalho Authorization e reduzir o escopo de credenciais armazenadas sempre que o desenho do ambiente permitir.
Após corrigir, a resposta deve incluir investigação retrospectiva desde pelo menos o período em torno de 26 de abril de 2026, quando a primeira tentativa foi registrada às 16:17 UTC. A revisão deve combinar logs de borda, aplicação, banco, provedores de LLM e serviços cloud associados às credenciais mantidas pelo LiteLLM. Se houver indício de leitura de litellm_credentials.credential_values ou atividade compatível com os IPs citados, a rotação de chaves deve ser priorizada. Credenciais de alto privilégio, chaves com limites financeiros elevados e credenciais IAM usadas para acesso ao AWS Bedrock merecem tratamento de credencial potencialmente exposta até que a análise descarte uso indevido.
- Atualizar todas as instâncias para
1.83.7-stableou versão mais recente. - Aplicar
disable_error_logs: trueemgeneral_settingsapenas como contenção temporária quando o patch não puder ser aplicado imediatamente. - Pesquisar
65.111.27[.]132,65.111.25[.]67,litellm_credentials.credential_values,litellm_confige cabeçalhosAuthorizationanômalos nos logs disponíveis. - Rotacionar credenciais armazenadas no proxy quando houver sinal de exploração ou quando a exposição não puder ser descartada.
- Revisar permissões e limites das chaves administradas pelo LiteLLM, reduzindo privilégios excessivos e separando credenciais por ambiente quando aplicável.
0 Comentários