Alerta LiteLLM exposto: três CVE críticos revelam a fragilidade da confiança mutável

A cadeia de erros divulgada por Obsidian Security contra LiteLLM é um lembrete duro de como decisões de design, validações ausentes e pontos únicos de controle podem converter uma conta de baixo privilégio em um acesso total ao servidor. LiteLLM atua como passarela para mais de 100 fornecedores de modelos e, em muitos desdobramentos, processa prompts, respostas e chaves sensíveis, por isso a exposição é proporcionalmente grave: roubo de chaves de fornecedor, sal de criptografia de credenciais, URL da base de dados e capacidade para alterar as respostas a agentes e usuários.

A rota de exploração acorrente três CVE- 2026-47101 permite saltar a autorização ao aceitar sem validar um campo de rua-supplied allowed_routes que pode ser "/*"; CVE-2026-47102 permite que um usuário se autoeleve mudando seu user_role a "proxy_admin" através de /user/update; e CVE-2026-40217 é uma fuga do sandbox no guardrail de código personalizado que executa código Python com exec () e termina expondo __builtins__ e funções como __import__ ou os.system. Obsidian qualifica a cadeia completa em CVSS 9,9, e BerriAI publicou o conjunto completo de adesivos na versão v1.83.14-stable, listada no GitHub como publicada em 2 de maio; atualizar a essa versão ou posteriores é a primeira e mais urgente ação. Ver o repositório oficial: GitHub — LiteLLM v1.83.14-stable e o aviso do pesquisador na web de segurança para contexto geral: Obsidian Security.

Além do exploit técnico, a geometria do ataque mostra uma lição clássica: confiança mutável em várias camadas. O proxy aceitou uma rota de acesso ditada pelo cliente e depois o resto do código assumiu que essa porta de roteamento havia feito todo o filtro. Essa confiança encadeada é a que permitiu que uma falha relativamente simples na gestão de chaves virtuais se tornasse controle remoto do servidor.

A consequência operacional é dupla e perigosa. Por um lado, um atacante que consegue a cadeia pode ler tudo o que passa pela passarela, incluindo PII, fragmentos de código e segredos que os usuários pegam em prompts. Por outro lado, e talvez mais sutil, mas mais explorável por agentes autónomos, o atacante pode alterar as respostas em trânsito e fazer com que um agente ou fluxo automatizado execute ações maliciosas sem que o modelo tenha sido manipulado por prompt injection: a passarela pode forjar tool calls e reescrever contexto de segurança usando callbacks internos que não aparecem na UI.

Há também vectores independentes que agravam o risco: o suporte MCP (Model Context Protocol) da LiteLLM permite que um proxy_admin registe servidores stdio locais que o proxy lança como subprocessos — uma decisão de desenho que implica que ter papel proxy_admin é, na prática, equivalente a ter capacidade de executar código na máquina. Um CVE diferente, CVE-2026-42271, afetou o preview de MCP e já foi observado em explorações reais e listado na catalogação de CISA para vulnerabilidades exploradas ativamente; vale a pena consultar no catálogo conhecido de CISA: CISA KEV.

O que os responsáveis pela infra e segurança devem agora fazer? A resposta começa pela atualização: adesivo para v1.83.14-stable ou superior imediatamente. Depois de aplicar a correção, não basta fechar o buraco: é preciso assumir que qualquer instância comprometida poderia ter tido acesso a chaves e aos dados em trânsito, pelo que a ação seguinte é uma auditoria e rotação de segredos.

Audite e trate o papel proxy_admin como acesso a nível de host: revalide cada conta com esse papel, feche contas obsoletas e exija autenticação forte e just-in-time onde possível. Verifique todas as Custom Code Guardrails e procure cargas úteis suspeitas; lembre-se de que as callbacks declaradas em configuração (por exemplo, litellm_settings.callbacks) não aparecem na consola e são um lugar lógico onde um atacante pós-explotação ocultaria persistência ou armadilhas. Verifique também a integridade do código colocado contra a fonte no Git e hashes de release assinados: não confie apenas na configuração.

Se suspeitar de compromisso, rote imediatamente todas as chaves de fornecedor (OpenAI, Anthropic, Gemini, Bedrock, Azure, etc.), mude o sal e as credenciais da base de dados e os tokens MCP; considere que as chaves em ficheiros de configuração ou variáveis de ambiente poderiam ter sido lidas em texto claro. Active a detecção de anomalias em logs e tráfego: picos de pedidos para endpoints administrativos, alterações em campos de usuários, criação de chaves virtuais com allowed_routes amplos ou callbacks novos são indicadores de compromisso.

No operacional e na arquitetura a médio prazo, replante a localização deste tipo de passadeira crítica e seu modelo de confiança: minimizar a quantidade de dados sensíveis que atravessam um único ponto, segregar redes e papéis, usar gestores de segredos externos e criptografia com separação de funções para que a passarela não tenha acesso direto a chaves-primas são medidas que reduzem o blast radius. Além disso, as regras de execução do código (guardrails) devem ser concebidas com modelos de segurança por defeito, filtros a nível de bytecode e não apenas regex, e evitar exec () direto com globais incompletos.

Também é altura de rever a cadeia de suprimentos e o processo de atualizações: LiteLLM já sofreu tentativas de backdoor em PyPI em março e uma injeção SQL explorada em abril, o que demonstra que projetos de infraestrutura de IA são brancos atrativos. Firme e verifique tarballs e pacotes, aplique digitalização de dependências e use políticas de bloqueio de versões em ambientes produtivos.

Para equipamentos que operam agentes ou gateways de modelos, este incidente deve mudar a matriz de ameaça: uma passarela comprometida não só filtra dados, pode alterar a própria lógica que governa os agentes. Considere controlos finais no endpoint que valdem a integridade das respostas antes de executar ações críticas, e mantenha uma separação clara entre dados sensíveis e prompts que acedem a sistemas produtivos.

Em resumo: atualize a versão alterada, audite papéis e callbacks, rote segredos se houve exposição e reevalúe a arquitetura de confiança que coloca a um único serviço no centro do tráfego de IA. A falha não é apenas técnica: é uma lição operacional sobre como desenhamos e defendemos as portas que mediam entre humanos, agentes e modelos.