Pesquisadores da Obsidian Security descobriram uma cadeia de três vulnerabilidades no LiteLLM que permite a uma conta de baixo privilégio escalar para administrador do proxy e executar código no servidor, expondo chaves de provedores, segredos de descriptografia e todo o tráfego de prompts e respostas; a correção foi publicada na versão 1.83.14‑stable e a Obsidian classificou a cadeia como CVSS 9.9 (Crítico).
Pesquisadores da Obsidian Security descobriram uma cadeia de vulnerabilidades no LiteLLM que permite a uma conta de baixo privilégio assumir o controle de servidores proxy.
O LiteLLM é um gateway open‑source amplamente usado que centraliza chamadas para mais de 100 provedores de modelos por meio de uma interface compatível com OpenAI.
Um takeover do servidor expõe chaves de provedores, segredos que descriptografam credenciais e todo o tráfego de prompts e respostas que passa pelo proxy.
A Obsidian classificou a cadeia completa como CVSS 9.9 (Crítico) e o mantenedor BerriAI lançou a correção na versão 1.83.14‑stable.
A exploração envolve três falhas distintas que podem ser encadeadas para obter controle total.
Primeiro, CVE‑2026‑47101 é um bypass de autorização em que o campo allowed_routes de uma chave virtual é aceito sem verificar o papel do usuário, permitindo a um usuário não‑administrador criar uma chave com acesso total a rotas restritas.
O mesmo problema de escrita sem validação aparece em outros endpoints de gerenciamento de chaves, e os pull requests publicados corrigem esses pontos.
Com a porta de rota aberta, dois caminhos levam à execução de código no servidor.
CVE‑2026‑47102 é um escalonamento de privilégios porque o endpoint user/update permite que qualquer campo seja atualizado; um self‑update definindo user_role como proxy_admin promove o atacante a administrador do proxy.
Um org_admin alcança esse endpoint por caminhos legítimos, e um usuário internal_user padrão pode alcançá‑lo depois do bypass inicial.
A terceira falha, CVE‑2026‑40217, é uma quebra da sandbox no Custom Code Guardrail que executa código Python do lado do servidor usando exec sem filtragem em nível de código‑fonte.
Quando exec recebe um globals sem builtins, o Python injeta o módulo builtins na runtime, permitindo imports, acesso a arquivos e chamadas como os.system que podem abrir um reverse shell.
Outra rota no playground das guardrails contornou uma lista de negação por regex via reescrita de bytecode em tempo de execução, terminando igualmente em execução remota de código.
Como o LiteLLM fica no ponto central do tráfego entre agentes e modelos, a exploração pode revelar a chave mestre, a chave salt que decripta credenciais e a URL do banco de dados.
Todas as chaves de provedores configuradas — por exemplo OpenAI, Anthropic, Gemini, Bedrock e Azure — ficam acessíveis; chaves em configuração ou ambiente aparecem em texto claro e chaves no banco de dados podem ser recuperadas usando a salt key.
Isso também significa que prompts, respostas e qualquer dado em trânsito — incluindo informações pessoais, código‑fonte, tickets internos e segredos colados — podem ser lidos ou alterados.
A Obsidian demonstrou que, por meio do mecanismo de callback do LiteLLM que dispara em cada requisição e não aparece na UI de administração, um invasor pode forjar respostas do modelo e acionar um reverse shell na máquina de um desenvolvedor.
A correção está disponível na versão 1.83.14‑stable; atualizar para essa versão ou posterior fecha a cadeia que envolve os três CVEs.
Além disso, é recomendado auditar contas com o papel proxy_admin, revisar os Custom Code Guardrails e rotacionar chaves de provedores e credenciais de banco de dados se houver suspeita de exposição.
O caso destaca como um gateway centralizado pode amplificar o impacto de falhas aparentemente isoladas.
