Vulnerabilidade Crítica de SQL Injection no LiteLLM Gateway Explorada Ativamente
Uma vulnerabilidade crítica de SQL injection, rastreada como **CVE-2026-42208**, está sendo ativamente explorada no gateway de modelo de linguagem grande (LLM) open-source **LiteLLM**. Atacantes estão aproveitando a falha para acessar e modificar informações sensíveis, incluindo chaves de API e credenciais.

Pesquisadores de cibersegurança estão relatando exploração ativa de uma vulnerabilidade crítica no **LiteLLM**, um gateway LLM open-source. A vulnerabilidade, identificada como **CVE-2026-42208**, permite que atacantes realizem ataques de SQL injection contra o gateway.
## Detalhes da Vulnerabilidade
A falha reside na etapa de verificação da chave de API do proxy dentro do **LiteLLM**. Ao enviar um cabeçalho `Authorization` especialmente elaborado para qualquer rota de API LLM, um atacante não autenticado pode explorar essa vulnerabilidade. Isso lhes concede a capacidade de ler e modificar dados dentro do banco de dados do proxy.
De acordo com o [aviso de segurança](http://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc) do mantenedor, atores de ameaça poderiam usar essa vulnerabilidade para "acesso não autorizado ao proxy e às credenciais que ele gerencia".
## Remediação
Uma correção para esta vulnerabilidade foi lançada na versão 1.83.7 do **LiteLLM**. Esta atualização substitui a concatenação de strings por consultas parametrizadas, mitigando efetivamente o risco de SQL injection.
Dado que o **LiteLLM** armazena dados sensíveis como chaves de API, chaves virtuais e mestras, e segredos de ambiente/configuração, a exploração bem-sucedida poderia levar a violações de segurança significativas.
## Visão Geral do LiteLLM
O **LiteLLM** é uma camada intermediária de proxy/SDK amplamente utilizada que fornece uma API unificada para chamar vários modelos de IA. Ele simplifica o gerenciamento de múltiplos modelos para desenvolvedores de aplicações e plataformas LLM. O projeto ostenta um seguimento comunitário substancial, com 45 mil estrelas e 7.6 mil forks no [GitHub](https://github.com/BerriAI/litellm).
Notavelmente, o **LiteLLM** foi recentemente alvo de um [ataque de cadeia de suprimentos](https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/) onde hackers da **TeamPCP** comprometeram o pacote PyPI, implantando um infostealer para coletar credenciais, tokens e segredos de sistemas infectados.
## Exploração Ativa
Pesquisadores da **Sysdig** relataram que a exploração da **CVE-2026-42208** começou aproximadamente 36 horas após a divulgação pública da vulnerabilidade em 24 de abril.
Os ataques observados envolveram requisições elaboradas enviadas ao endpoint `/chat/completions`, utilizando um cabeçalho malicioso `Authorization: Bearer`. Essas requisições visavam tabelas específicas contendo chaves de API, credenciais de provedor (por exemplo, **OpenAI**, **Anthropic**, **Bedrock**), dados de ambiente e configurações.
A **Sysdig** observou que os atacantes exibiram um claro entendimento da estrutura do banco de dados, visando diretamente tabelas contendo informações sensíveis. Na segunda fase do ataque, o ator de ameaça rotacionou endereços IP, provavelmente para fins de evasão, e refinou suas tentativas de SQL injection com base nas informações coletadas na fase inicial.
Embora o cronograma de exploração não tenha sido tão rápido quanto a [falha recente no Marimo](https://www.bleepingcomputer.com/news/security/critical-marimo-pre-auth-rce-flaw-now-under-active-exploitation/), os ataques foram altamente direcionados e específicos, de acordo com a **Sysdig**.
## Recomendações
Profissionais de segurança são instados a tratar quaisquer instâncias expostas do **LiteLLM** executando versões vulneráveis como potencialmente comprometidas. É crucial rotacionar todas as chaves de API virtuais, chaves mestras e credenciais de provedor armazenadas em instâncias do **LiteLLM** expostas à internet.
Para aqueles que não conseguem atualizar imediatamente para o **LiteLLM** 1.83.7 ou posterior, uma solução alternativa está disponível: definir `disable_error_logs: true` em `general_settings` para bloquear o caminho através do qual entradas maliciosas podem atingir a consulta vulnerável.
