Base de CVEs

Flowise contains an authentication bypass vulnerability in the unprotected /api/v1/account/register endpoint that allows unauthenticated attackers to create user accounts. Remote attackers can exploit this endpoint to register arbitrary accounts and authenticate to the system, gaining full API access without credentials.

Rclone é um programa de linha de comando para sincronizar arquivos e diretórios com diferentes provedores de armazenamento em nuvem. Da versão 1.46.0 até a versão 1.74.3, o rclone rcd --rc-serve aceita requisições GET e HEAD sem autenticação para caminhos na forma: /[remote:path]/object. O valor de remote é extraído da URL e passado para a inicialização normal do backend. A configuração inline de remote pode definir opções de backend que executam comandos locais durante a inicialização. Como resultado, uma única requisição GET ou HEAD sem autenticação pode executar um comando como usuário do processo rclone. Esta vulnerabilidade está corrigida na versão 1.74.3.

O n8n é uma plataforma de automação de fluxos de trabalho de código aberto. Antes das versões 2.25.7 e 2.26.2, quando o @n8n/mcp-browser é executado no modo de transporte HTTP, o endpoint MCP aceita solicitações de inicialização de sessão e de invocação de ferramentas sem qualquer autenticação. Qualquer cliente acessível pela rede, ou qualquer site visitado pelo usuário, pode estabelecer uma sessão MCP e invocar ferramentas de controle do navegador. Quando a extensão n8n AI Browser Bridge está instalada e uma conexão com o navegador está ativa, um chamador não autenticado pode acessar recursos de controle do navegador, incluindo navegação, avaliação de JavaScript e acesso a cookies e armazenamento, no perfil real do navegador do usuário. Este problema afeta apenas instâncias em que o @n8n/mcp-browser é executado com o transporte HTTP (--transport http). Esta vulnerabilidade está corrigida nas versões 2.25.7 e 2.26.2.

Existe uma vulnerabilidade de credenciais padrão inseguras no NI grpc-device quando a configuração TLS não está presente e o servidor está vinculado além do loopback. Isso pode permitir que um usuário não autenticado acesse o servidor na rede local. Afeta o NI grpc-device 2.17.0 e versões anteriores.

Em JetBrains Hub antes de 2026.1.13757, 2025.3.148033, 2025.2.148048, 2025.1.148120, 2024.3.148430, 2024.2.148429 bypass de autenticação via acesso direto ao banco de dados levando a acesso administrativo era possível

Dois endpoints que alteram estado no blueprint do SQL Editor do pgAdmin 4 -- DELETE /sqleditor/close/<trans_id> e POST /sqleditor/initialize/sqleditor/update_connection/<sgid>/<sid>/<did> -- eram as únicas rotas do módulo sem o decorador @pga_login_required. Ambas chegam a um sink pickle.loads sobre session['gridData'][<trans_id>]['command_obj']: o endpoint de fechamento via close_sqleditor_session(), e update_sqleditor_connection via check_transaction_status(). No modo servidor, esses endpoints eram acessíveis sem nenhuma sessão autenticada do pgAdmin. O defeito é uma falha de falta de autenticação em função crítica (CWE-306) envolvendo um sink de desserialização de dados não confiáveis (CWE-502). Explorar isso para execução remota de código exige que o atacante também forje um arquivo de sessão no servidor cuja entrada gridData contenha um payload pickle malicioso, o que por sua vez exige (a) conhecimento da SECRET_KEY do Flask do pgAdmin (nenhuma cadeia para vazá-la é descrita aqui -- o atacante precisa já possuí-la) e (b) permissão de escrita no diretório sessions/ do pgAdmin no host. Nenhuma dessas pré-condições é concedida por este defeito isoladamente. Quando essas pré-condições são atendidas por outro canal (implantação incorreta, comprometimento prévio, configuração vazada), a ausência do controle de autenticação é o último passo que transforma um comprometimento parcial existente em execução de código não autenticada no processo do pgAdmin -- e, por extensão, no host sob a conta que executa o pgAdmin. A correção é um decorador @pga_login_required de uma linha em cada um dos dois endpoints, seguindo a convenção usada por todas as outras rotas do módulo. A cadeia is_authenticated / MFA agora é executada antes de trans_id ser desreferenciado, de modo que uma requisição não autenticada é rejeitada antes de alcançar o caminho de desserialização. O defeito afeta apenas o modo servidor. No modo DESKTOP, o hook before_request do pgAdmin reautentica DESKTOP_USER em toda requisição, portanto nenhum endpoint pode ser exercitado em estado não autenticado e nenhum decorador de autenticação (ou sua ausência) é relevante. O teste de regressão que acompanha a correção reproduz o caminho do atacante -- obtém um X-pgA-CSRFToken em GET /login e o reenvia contra os dois endpoints -- e se ignora fora do modo servidor por essa razão; ele está incluído no workflow de CI existente do modo servidor, junto com os testes de isolamento de dados. Este problema afeta o pgAdmin 4: a partir de 6.9 até antes de 9.16.

O mcp-pinot é um servidor Model Context Protocol (MCP) baseado em Python para interagir com o Apache Pinot. Nas versões 3.0.1 e anteriores, o mcp-pinot por padrão executa um servidor MCP HTTP vinculado a 0.0.0.0:8080 sem nenhuma autenticação habilitada. Todas as ferramentas MCP, incluindo execução de consultas SQL, criação de schemas e mutação de configuração de tabelas, ficam acessíveis a qualquer chamador adjacente na rede. O servidor intermedia essas chamadas usando credenciais do Pinot do lado do servidor, produzindo uma condição de confused deputy que resulta em acesso total de leitura/escrita ao cluster Pinot configurado. Este problema foi corrigido na versão 3.1.0.

O Electronic Protest Docketing System (EPDS) do U.S. Government Accountability Office (GAO) e o Electronic Docketing System (EDS) do Civilian Board of Contract Appeals (CBCA) não autenticam solicitações de alteração de senha enviadas ao endpoint de API '/update-profile/N'. Um atacante remoto e não autenticado poderia alterar a senha de um usuário arbitrário.