Jaydns

#6126de 56,330
47CVSS total
Vulnerabilidades · 5
Alta
2
Crítica
3
PT-2026-81905
8.6
2026-08-25
Npm · @Better-Auth/Sso · CVE-2026-80192
**Nome do Software Vulnerável e Versões Afetadas** @better-auth/sso versões anteriores a 1.4.8 @better-auth/sso versões anteriores a 1.6.27 @better-auth/sso versões anteriores a 1.7.0-rc.5 **Description** Existem duas falhas de propriedade de domínio quando o plugin SSO está ativo. Se a verificação de domínio estiver desativada, a atribuição automática de organização aceita domínios de provedores não verificados. Isso permite que um proprietário ou administrador de organização autenticado registre um provedor SSO para qualquer domínio, fazendo com que usuários com domínios de e-mail correspondentes sejam adicionados à organização do invasor com permissões de membro padrão. Se a verificação de domínio estiver ativada, ocorre uma condição de corrida (race condition) entre os endpoints 'verify-domain' e 'update-provider', que pode aplicar uma prova de DNS concluída a um domínio incorreto. Quando combinado com a vinculação implícita de conta, isso permite que um provedor de identidade controlado por um invasor seja vinculado a uma conta de usuário existente. O plugin de organização também deve estar habilitado para que o caminho de atribuição de organização seja explorado. **Recommendations** Atualize o @better-auth/sso para a versão 1.4.8 ou posterior para a linha 1.4.x. Atualize o @better-auth/sso para a versão 1.6.27 ou posterior. Atualize o @better-auth/sso para a versão 1.7.0-rc.5 ou posterior para a linha de pré-lançamento 1.7.
PT-2026-35643
9.8
2026-04-24
Litellm · Litellm · CVE-2026-42208
**Nome do Software Vulnerável e Versões Afetadas** LiteLLM versões 1.81.16 até 1.83.6 **Descrição** Uma injeção de SQL pré-autenticação não autenticada existe no processo de verificação de chave de API do proxy. O problema ocorre porque uma consulta ao banco de dados mistura valores fornecidos pelo chamador diretamente no texto da consulta em vez de usar consultas parametrizadas. Um invasor pode explorar isso enviando um cabeçalho `Authorization` especialmente manipulado para qualquer rota de API de LLM, como `POST /chat/completions`, atingindo a consulta vulnerável através do caminho de tratamento de erros do proxy. Isso permite que um invasor leia ou modifique dados no banco de dados do proxy, visando especificamente tabelas como `litellm credentials`, `LiteLLM VerificationToken` e `litellm config` para roubar credenciais de provedores e chaves de API. O problema foi explorado ativamente em menos de 36 horas após a divulgação, com invasores utilizando payloads `UNION SELECT` para extrair informações sensíveis. **Recomendações** Atualize o LiteLLM para a versão 1.83.7 ou superior. Como solução temporária, defina `disable error logs: true` em `general settings` para remover o caminho que permite que a entrada não autenticada atinja a consulta vulnerável. Revogue e regenere todas as chaves da OpenAI, Anthropic e AWS Bedrock armazenadas no proxy se a instância estiver exposta à internet. Audite os logs do IAM em busca de invocações de modelos ou criação de credenciais não autorizadas se o AWS Bedrock for utilizado.