O armazenamento centralizado de credenciais é o que torna esta vulnerabilidade particularmente de alto impacto. Uma instância comprometida do LiteLLM não expõe apenas uma chave de API -- ela potencialmente expõe todas as credenciais de nuvem que a organização configurou em todos os provedores de LLM.

Detalhes da Vulnerabilidade

Causa Raiz

A falha existe no processo de verificação de chave de API do proxy do LiteLLM. Quando uma requisição chega, o proxy verifica o valor do cabeçalho Authorization: Bearer contra seu banco de dados para autenticar o chamador. Nas versões afetadas, o valor do token bearer era concatenado diretamente na string da consulta SQL em vez de ser passado como entrada parametrizada:

Uma aspa simples no valor do bearer permite que um atacante escape do literal de string e anexe instruções SQL arbitrárias. Como o ponto de injeção está na própria verificação de autenticação, nenhuma credencial válida é necessária para acioná-la.

Caminho de Ataque

1. O atacante envia uma requisição HTTP forjada para qualquer endpoint de API de LLM (ex.: POST /chat/completions)
2. O cabeçalho Authorization: Bearer contém um payload de injeção SQL
3. A requisição flui pelo caminho de tratamento de erros do proxy e atinge a consulta vulnerável
4. O atacante pode executar instruções SELECT arbitrárias ou potencialmente INSERT/UPDATE/DELETE contra o backend PostgreSQL
5. Tabelas do banco de dados contendo chaves de API, credenciais de provedores e dados de configuração são expostas

O que os Atacantes Alvejaram

A Equipe de Pesquisa de Ameaças da Sysdig observou tentativas de exploração no mundo real visando:

• Tabela LiteLLM_VerificationToken -- chaves de API virtuais e controles de acesso
• Tabelas de armazenamento de credenciais -- chaves de API de provedores upstream de LLM (OpenAI, Anthropic, etc.)
• Tabelas de configuração -- definições de modelos, orçamentos de gastos, configurações de limite de taxa

Linha do Tempo da Exploração

A janela de exploração de 36 horas é consistente com um ator de ameaça organizado usando varredura automatizada para monitorar novas publicações de CVE e desenvolver ou adaptar rapidamente código de exploração. A injeção SQL é uma classe de vulnerabilidade bem compreendida -- uma vez que o caminho de código afetado é identificado, a armação é direta.

Avaliação de Impacto

Confidencialidade: Alta -- conteúdo do banco de dados legível, incluindo credenciais
Integridade: Alta -- banco de dados gravável, chaves podem ser adicionadas, modificadas ou excluídas
Disponibilidade: Média -- o proxy pode ser interrompido através de modificação no banco de dados
Autenticação necessária: Nenhuma -- totalmente pré-autenticação
Acesso de rede necessário: Sim -- o atacante deve conseguir alcançar a porta do proxy

Por que isso importa além de um SQLi típico: O LiteLLM é especificamente projetado para centralizar o gerenciamento de credenciais. Uma organização executando uma instância comprometida do LiteLLM pode tê-la configurado com chaves de API para OpenAI, Anthropic, Azure OpenAI, AWS Bedrock e outros provedores. Cada uma dessas chaves representa acesso a serviços de LLM pagos com limites de gastos potencialmente significativos. Além do abuso de gastos com LLM, credenciais de provedores de nuvem no banco de dados poderiam permitir movimento lateral em ambientes AWS, Azure ou GCP.

Versões Afetadas

Oportunidades de Detecção

Nível de Rede/WAF

Procure por requisições HTTP para endpoints do LiteLLM contendo metacaracteres SQL no cabeçalho Authorization:

Indicadores para procurar nos logs do proxy:

• Requisições para /chat/completions, /embeddings ou outras rotas de API com tokens bearer malformados
• Valores de bearer contendo aspas simples, travessões duplos, UNION, SELECT ou outras palavras-chave SQL
• Alto volume de respostas 4xx do proxy com cabeçalhos Authorization variados do mesmo IP de origem

Nível de Banco de Dados

• Consultas SELECT inesperadas contra LiteLLM_VerificationToken com cláusulas WHERE incomuns
• Acesso a tabelas de credenciais ou configuração fora dos padrões normais de consulta da aplicação
• Registros de chaves de API novos ou modificados não criados através da interface de administração

MITRE ATT&CK

Ações Recomendadas

Imediatas (se executando versões afetadas):

1. Atualize para LiteLLM >= 1.83.7-stable imediatamente
2. Se exposto à internet durante a janela vulnerável (19 de abril - implantação do patch), trate como um possível comprometimento -- não assuma que sem patch = sem comprometimento
3. Roteie todas as chaves de API e credenciais de nuvem armazenadas no banco de dados do LiteLLM
4. Revise os logs de acesso do proxy para indicadores de injeção SQL nos cabeçalhos Authorization

Curto prazo: 5. Restrinja o acesso de rede à porta do proxy LiteLLM -- ele não deve estar diretamente exposto à internet sem autenticação na frente 6. Ative o registro de consultas do banco de dados para detectar futuras tentativas de injeção 7. Adicione regras de WAF para inspecionar cabeçalhos Authorization quanto a metacaracteres SQL

Contínuo: 8. Assine os alertas do CISA KEV -- esta vulnerabilidade estava sendo ativamente explorada antes que a maioria dos ciclos de patch a detectasse 9. Trate a infraestrutura de IA como armazenamentos de credenciais de alto valor -- os mesmos controles de segurança aplicados a gerenciadores de segredos devem ser aplicados a implantações de proxy de LLM

Notas do Analista

Por que a infraestrutura de IA é um alvo crescente: O LiteLLM e ferramentas similares ocupam uma posição privilegiada -- eles detêm credenciais para serviços de nuvem pagos com altos limites de gastos e são frequentemente implantados por equipes de engenharia em vez de equipes de segurança, com revisão de segurança menos madura. A equipe da Sysdig observou especificamente que operadores do LiteLLM "confiam nele para centralizar credenciais de nível de nuvem," tornando-o um alvo atraente para roubo de credenciais e abuso de serviços de LLM (usando chaves de API roubadas para executar suas próprias consultas contra modelos pagos).

A janela de exploração de 36 horas é um parâmetro de referência: Isso não é uma anomalia. Atacantes monitoram ativamente feeds de publicação de CVE e bancos de dados de avisos. Para vulnerabilidades críticas pré-autenticação em software de código aberto amplamente utilizado, assuma que a exploração começa dentro de 24-48 horas após a divulgação pública. Os SLAs de patch precisam levar em conta essa realidade -- uma janela de patch de 30 dias não é apropriada para vulnerabilidades pré-autenticação com CVSS 9+.

CISA KEV como sinal de priorização: O catálogo KEV inclui apenas vulnerabilidades com exploração confirmada no mundo real. Se um CVE aparece no KEV, não é teórico -- alguém já o usou contra alvos reais. As organizações devem tratar adições ao KEV como itens de ação imediata, independentemente de seus limites internos de priorização baseados em CVSS.

Referências

• CISA KEV -- CVE-2026-42208
• Análise da Sysdig TRT
• Cobertura do The Hacker News
• Security Affairs
• GHSA-r75f-5x8p-qvmc
• MITRE ATT&CK T1190
• MITRE ATT&CK T1555