Nova vulnerabilidade LiteLLM explorada logo após a divulgação

🇧🇷 PT 🇺🇸 EN

2026-04-29 00:00

← Voltar

Resumo Executivo

Uma vulnerabilidade de gravidade crítica no gateway de IA de código aberto LiteLLM foi explorada dias após a divulgação pública para acessar tabelas de banco de dados contendo informações confidenciais, relata Sysdig. O defeito de segurança é descrito como uma injeção de SQL durante o processo de verificação da chave da API do proxy e é identificado como CVE-2026-42208, com pontuação CVSS de 9,3. Em um comunicado de 20 de abril, os mantenedores do LiteLLM explicaram que uma consulta ao banco de dados usada durante a verificação da chave não passou o valor fornecido pelo chamador como um parâmetro separado, incluindo-o na consulta. Isso permitiu que um invasor não autenticado enviasse um cabeçalho de autorização especialmente criado para qualquer rota da API LLM e acessasse a consulta por meio do caminho de tratamento de erros do proxy. “A chamada acontece antes da autenticação (autenticação) ser decidida, portanto a injeção é totalmente pré-autenticação: qualquer cliente HTTP que possa alcançar a porta proxy é suficiente”, observa Sysdig. Ao explorar o problema, o invasor pode acessar o banco de dados do proxy LiteLLM para ler e potencialmente modificar dados, permitindo o vazamento de credenciais armazenadas no banco de dados. Anúncio. Role para continuar lendo.

Em 24 de abril, o comunicado foi indexado no banco de dados GitHub Advisory, e os primeiros ataques explorando a falha foram observados 36 horas depois, diz Sysdig. A empresa de segurança cibernética observou os...

Detalhes

Uma vulnerabilidade de gravidade crítica no gateway de IA de código aberto LiteLLM foi explorada dias após a divulgação pública para acessar tabelas de banco de dados contendo informações confidenciais, relata Sysdig. O defeito de segurança é descrito como uma injeção de SQL durante o processo de verificação da chave da API do proxy e é identificado como CVE-2026-42208, com pontuação CVSS de 9,3. Em um comunicado de 20 de abril, os mantenedores do LiteLLM explicaram que uma consulta ao banco de dados usada durante a verificação da chave não passou o valor fornecido pelo chamador como um parâmetro separado, incluindo-o na consulta. Isso permitiu que um invasor não autenticado enviasse um cabeçalho de autorização especialmente criado para qualquer rota da API LLM e acessasse a consulta por meio do caminho de tratamento de erros do proxy. “A chamada acontece antes da autenticação (autenticação) ser decidida, portanto a injeção é totalmente pré-autenticação: qualquer cliente HTTP que possa alcançar a porta proxy é suficiente”, observa Sysdig. Ao explorar o problema, o invasor pode acessar o banco de dados do proxy LiteLLM para ler e potencialmente modificar dados, permitindo o vazamento de credenciais armazenadas no banco de dados. Anúncio. Role para continuar lendo.

Em 24 de abril, o comunicado foi indexado no banco de dados GitHub Advisory, e os primeiros ataques explorando a falha foram observados 36 horas depois, diz Sysdig. A empresa de segurança cibernética observou os invasores visando especificamente três tabelas de banco de dados contendo informações confidenciais, como chaves de API, credenciais de provedor e configuração de variável de ambiente do proxy. “O operador já conhecia o identificador PostgreSQL gerado pelo Prisma do LiteLLM e executou uma varredura de descoberta de contagem de colunas do livro didático em cada tabela de destino”, explica Sysdig. Apesar da natureza direcionada dos ataques, não foi observada qualquer continuação e as chaves e credenciais extraídas não foram abusadas. Os ataques observados, afirma a empresa de segurança cibernética, foram realizados com intervalo de 21 minutos, provavelmente por meio de uma ferramenta automatizada que usava a mesma carga, mas alternava os endereços IP de origem. “A novidade desta descoberta é a velocidade e a precisão da tentativa de enumeração de esquemas, e não um compromisso confirmado”, observa Sysdig. LiteLLM versão 1.83.7 resolve a vulnerabilidade garantindo que o valor fornecido pelo chamador seja sempre passado como um parâmetro separado. Os usuários são aconselhados a atualizar para a versão corrigida o mais rápido possível ou desabilitar os logs de erros para mitigar o caminho de exploração.

Relacionado: 38 vulnerabilidades encontradas no software médico OpenEMR Relacionado: Lançamento de atualizações de segurança do Chrome 147, Firefox 150 Relacionado: Nenhum patch para a nova técnica de escalonamento de privilégios PhantomRPC no Windows Relacionado: Falha do OpenSSH que permite acesso total ao shell root oculto por 15 anos