Radar Tech: LiteLLM e a chave que abre duas portas — escalada de privilegio e RCE no proxy de LLMs mais usado do mercado
Uma falha alta corrigida no LiteLLM mostra que a mesma chave criptografica selava os segredos em repouso e assinava os tokens de sessao. Um usuario comum montava essa mesma chave a mao, virava proxy admin e executava comandos no host. O que isso ensina sobre fronteiras de confianca em qualquer plano de dados que guarda credenciais e emite credenciais.
No 30 de setembro de 2026, o LiteLLM — o proxy open source que aparece em quase todo stack de IA que consome varios provedores de modelo por uma API so — publicou um aviso de seguranca de severidade alta. O titulo e tecnico, mas o nome resume o problema: reuso da mesma chave criptografica em dominios diferentes ("Cross-Domain Reuse of the Salt Key"). Ali estava uma licao de arquitetura que vale para muito mais do que o LiteLLM.
O que aconteceu
Resumindo sem eufemismos: qualquer usuario autenticado com privilegio basico (um internal_user, conta comum de operador ou dev) conseguia virar administrador do proxy e, a partir dai, executar comandos arbitrarios no host.
O mecanismo e a parte interessante, porque e construtivo, nao exotico:
- O proxy usa uma unica chave para selar segredos em repouso (cofres de chaves de API dos provedores) e para montar tokens de sessao assinados.
- Como o usuario autenticado podia pedir a criacao de uma chave de API com um campo de metadados controlado por ele, o proxy criptografava o payload dele com a mesma chave e devolvia o resultado.
- Ao apresentar esse valor criptografado de volta como token de sessao, o proxy descriptografava, confiava no conteudo e concedia identidade de administrador.
- Com essa identidade, o endpoint de MCP via stdio entregava execucao de comandos no host.
Um primitivo so — "a mesma chave sela dado e assina identidade" — gera escalada de privilegio e RCE. O risco vem da composicao de funcionalidades legitimas, nao de um bug exotico.
Duas notas de operacao que todo mundo deveria ler antes de fechar a aba:
- A versao corrigida e mais recente e o
1.104.0rc2(ha tambem correcoes nas linhas1.100.4,1.101.3,1.102.2e1.103.1). Em linhas mais antigas,1.87.0a1.90.x, a exposicao so existe seEXPERIMENTAL_UI_LOGIN=truetiver sido ligado explicitamente. - A mitigacao de emergencia (desligar
EXPERIMENTAL_UI_LOGIN) quebra o SSO de CLI e o login do Claude Code no gateway — ou seja, o paliativo tambem derruba um caminho de trabalho legitimo. Esse e o classico trade-off que precisa ser decidido por uma pessoa, com dono e prazo, nao deixado no "depois a gente ve".
As licoes de arquitetura
1. Uma chave, um proposito
Chave de cifragem de dado e chave de assinatura de identidade sao fronteiras diferentes e nao podem ser a mesma chave. Quem consegue fazer o sistema criptografar algo consegue, sem querer, cunhar uma credencial — e essa e a definicao de um oraculo de cunhagem.
2. O oracle e o risco, nao a API
O perigo nao estava em "existe um endpoint que cifra". Estava em um plano de dados guardar segredo e emitir credencial com a mesma raiz de confianca. Se o seu gateway, service mesh ou provedor de identidade faz as duas coisas, procure esse acoplamento hoje, antes de um pesquisador achar por voce.
3. Gateway de IA e plano de dados, nao utilitario
Quem centraliza credenciais de N provedores passa a ser o cofre da organizacao. Ele merece o mesmo tratamento de um banco: inventario de rotas, rotacao de chave, blast radius declarado, log de toda operacao administrativa e um caminho de emergencia que nao dependa da funcionalidade sob ataque.
4. "Upgrade resolve" e uma frase incompleta
Existe a versao corrigida. Existe tambem um caminho, um dono e um prazo para chegar nela — e um paliativo que tem custo funcional. Upgrade sem verificacao de versao reportada pelo processo em execucao, sem decisao registrada sobre o paliativo e sem prova de que o caminho antigo esta fechado nao e resposta a incidente: e uma torcida.
5. Ferramenta que a IA usa tambem e superficie de ataque
Um gateway de LLM e, por definicao, uma ferramenta que agentes chamam. Ele cai nas duas fronteiras ao mesmo tempo: e o cofre de credenciais e o ponto por onde passa a identidade dos agentes. Superficie de ataque que atende agentes exige escopo minimo, por padrao.
O erro do dia
O erro nao foi escolher o LiteLLM. Foi deixar que a mesma chave selasse dado e assinasse identidade — e descobrir isso pela divulgacao responsavel em vez de pelo desenho.
Em uma frase
Se o seu proxy de IA guarda segredos e emite credenciais, ele e uma fronteira de confianca. Trate-o como cofre e como superficie de ataque — nao como um utilitario de conveniencia.
Radar Tech e a curadoria diaria de noticias de tecnologia com vies de arquitetura de software do ArchPrompts. Hoje: o aviso de setembro de 2026 do LiteLLM (GHSA-7hp6-4w63-5g45), escalada de privilegio a proxy admin e RCE por reuso de chave criptografica, e o que ele ensina sobre fronteiras de confianca em gateways de IA.
