Fushuling

Existe uma falha lógica no processo de validação de URL que permite a ocorrência de Server-Side Request Forgery (SSRF). A função ` is safe url()` utiliza `urlparse` para validar URLs de mídia remota, enquanto o `requests.Session().get` interpreta barras invertidas de forma diferente ao enviar a requisição. Um invasor pode fornecer uma URL especialmente manipulada contendo uma barra invertida que faz com que o `urlparse` identifique um nome de host globalmente roteável, enquanto a requisição real é direcionada para um host interno. Essa discrepância permite que invasores ignorem as verificações de endereços não globais e induzam as aplicações a acessar serviços HTTP internos, expondo potencialmente dados sensíveis.

As restrições nas URLs de redirecionamento podem ser burladas, levando a ataques de redirecionamento aberto (open redirect). O problema ocorre porque a lógica de validação verifica apenas se o host e o esquema da URL de redirecionamento correspondem ao site atual, utilizando posteriormente apenas a parte do caminho para o redirecionamento. Um invasor pode burlar isso fornecendo uma URL onde o caminho começa com `//`, como `http://127.0.0.1:25222//fushuling.com`. Os navegadores interpretam caminhos que começam com `//` como URLs relativas ao protocolo, redirecionando o usuário para um domínio externo. Isso é acionado através do cabeçalho `Referer`.

O DataEase é uma ferramenta de análise e visualização de dados de código aberto. A lógica de validação da URL JDBC do banco de dados H2 pode ser burlada utilizando caracteres Unicode especiais. Isso ocorre porque o comportamento de conversão de caixa desses caracteres difere entre o processo de validação no DataEase e o processo de análise no H2. Essa discrepância permite que invasores introduzam parâmetros perigosos, como `init`, em strings de conexão JDBC do H2 maliciosas para alcançar a execução arbitrária de código.

O parsing incorreto do host no componente `UriComponentsBuilder` pode permitir que aplicações que o utilizam para analisar e validar strings de URL fornecidas externamente fiquem expostas a um ataque de server-side request forgery (SSRF). SSRF é uma falha que permite a um invasor induzir a aplicação do lado do servidor a fazer requisições para um local não pretendido.

Uma falha lógica na lógica de verificação de URL permite que invasores ignorem filtros de segurança, levando ao Server-Side Request Forgery (SSRF). O software utiliza a função `validate url` para realizar verificações de segurança na parte do host de uma URL extraída pelo `urlparse`. No entanto, existe uma discrepância entre a forma como o `urlparse` e a biblioteca `requests` analisam as URLs. Por exemplo, na função `safe get()`, o `validate url` pode identificar que uma URL aponta para um IP público, enquanto o `requests.get` interpreta a mesma URL como apontando para um endereço interno. Isso ocorre porque o `urlparse` pode tratar certos caracteres, como barras invertidas, como caracteres comuns, enquanto o `requests` pode tratá-los como caracteres de caminho, permitindo que um invasor redirecione solicitações para recursos de rede interna.

O Speakr é uma aplicação web auto-hospedada para transcrição de gravações de áudio. A função auxiliar `is safe url()`, utilizada para validar alvos de redirecionamento pós-login, aplica incorretamente `urljoin(request.host url, target)` antes da análise, enquanto o controlador passa o alvo bruto para a função `redirect()`. Isso permite que uma entrada relativa ao esquema, como `////evil.com`, seja validada como uma URL do mesmo host, mas interpretada pelo navegador como um redirecionamento relativo ao caminho de rede para um host externo controlado por um invasor através do cabeçalho Location.

Existe um problema no endpoint de busca de URL do serviço de arquivos OSS "chat/api/oss/get url", onde a análise inconsistente de URL entre a função de validação `urlparse` e o cliente HTTP `requests` permite a evasão de server-side request forgery (SSRF). Isso possibilita que atacantes acessem serviços de rede interna.

Uma divergência na análise de URLs permite a evasão da validação de URLs de webhook. O sistema utilizava o `urllib.parse.urlparse` do Python para validação, mas o `requests.post` para enviar a requisição. Para entradas malformadas contendo barras invertidas e @, esses componentes podem divergir sobre qual é o hostname de destino. Isso permite que uma URL pareça ser um hostname público permitido durante a validação, enquanto o cliente HTTP se conecta a um host diferente, como destinos de loopback, privados ou não permitidos. Isso resulta em um Server-Side Request Forgery (SSRF), onde o servidor é induzido a fazer uma requisição HTTP POST externa não pretendida.

Um problema permite que o driver carregue e execute classes arbitrárias ao processar parâmetros de URL de conexão JDBC. Um ator capaz de influenciar a URL de conexão poderia potencialmente executar código no contexto da aplicação, desde que uma classe adequada esteja disponível no classpath da aplicação.

Uma falha lógica na lógica de verificação de URL permite que invasores ignorem filtros de segurança, levando ao Server-Side Request Forgery (SSRF). O sistema utiliza a função ` validate url()` para realizar verificações de segurança na parte do host de uma URL extraída pelo `urlparse()`. No entanto, existe uma discrepância entre a forma como o `urlparse()` e a biblioteca `requests` analisam certas URLs. Por exemplo, em uma URL como `http://127.0.0.1:6666@1.1.1.1`, o `urlparse()` identifica o hostname como `1.1.1.1` (um endereço público), enquanto o `requests` o interpreta como `127.0.0.1` (um endereço interno). Essa inconsistência permite que as solicitações sejam roteadas para endereços de rede interna, apesar de passarem na validação inicial.

Nome do Software Vulnerável e Versões Afetadas vLLM versões 0.16.0 até 0.18.99 Descrição vLLM, um mecanismo de inferência e serviço para grandes modelos de linguagem, contém uma falha de falsificação de solicitação do lado do servidor (SSRF) na função `download bytes from url`. Isso permite que um invasor que possa controlar o JSON de entrada em lote faça com que o executor em lote vLLM emita solicitações HTTP/HTTPS arbitrárias do servidor, sem nenhuma validação de URL ou restrições de domínio. A vulnerabilidade reside no arquivo `run batch.py`, especificamente dentro da função `download bytes from url`, que chama diretamente `session.get(url)` em uma URL fornecida no JSON de entrada em lote. O parâmetro `file url` dentro de `BatchTranscriptionRequest` e `BatchTranslationRequest` é vulnerável, pois não possui restrições de domínio, IP ou porta. Isso pode ser explorado para atingir serviços internos acessíveis do host vLLM. Recomendações Atualize para a versão 0.19.0 ou posterior do vLLM.

Name of the Vulnerable Software and Affected Versions JupyterHub versões anteriores a 5.4.4 Description Uma falha no JupyterHub permite que invasores criem links que redirecionam os usuários para uma página de login do JupyterHub e, em seguida, para um site controlado pelo invasor em vez de uma página legítima do JupyterHub. Isso ignora as verificações de segurança do JupyterHub. Recommendations Atualize para a versão 5.4.4 do JupyterHub.

Os carregadores de mídia do Windows falham ao realizar a validação de caminho local antes de aceitar URLs de arquivos de hosts remotos e caminhos no estilo UNC (Universal Naming Convention, um padrão para especificar a localização de recursos compartilhados em uma rede). Isso permite que invasores forneçam alvos de arquivos hospedados em rede que o sistema trata como conteúdo local, ignorando as restrições de acesso pretendidas.

DataEase is an open source data visualization analysis tool. Versions 2.10.19 and below exhibit inconsistent locale handling between the JDBC URL validation logic and the H2 JDBC engine's internal parsing. DataEase uses `String.toUpperCase()` without specifying an explicit locale, relying on the JVM's default runtime locale for security checks, while H2 JDBC normalizes URLs using `Locale.ENGLISH`. In Turkish locale environments (tr TR), Java converts the lowercase letter 'i' to 'İ' (dotted capital I) instead of 'I', allowing a malicious parameter like `iNIT` to bypass DataEase's blacklist while H2 correctly interprets it as `INIT`. This discrepancy enables attackers to smuggle dangerous JDBC parameters past DataEase's security validation. The issue has been confirmed as exploitable in real-world DataEase deployments running under affected regional settings.

Dataease is an open source data visualization analysis tool. Prior to version 2.10.20, controlling the `IniFile` parameter allows an attacker to force the JDBC driver to load an attacker-controlled configuration file. This configuration file can inject dangerous JDBC properties, leading to remote code execution. The vulnerability resides in the `getJdbcIniFile` method, which aggressively searches for a configuration file named `rsjdbc.ini` if not explicitly restricted. Within a JDBC URL context, users can specify the configuration file via URL parameters, enabling the loading of arbitrary files on the server as JDBC configuration files. The `IniFile` parameter within the Redshift JDBC driver properties is explicitly supported and used to load external configuration files.

Existe uma vulnerabilidade na função `SdkProxyRoutePlanner` dentro do componente `JDBC URL Handler` do snowflakedb snowflake-jdbc. A manipulação do argumento `nonProxyHosts` pode levar a uma complexidade ineficiente de expressões regulares. Este problema é explorável localmente e o exploit foi divulgado publicamente. O código vulnerável está localizado no arquivo src/main/java/net/snowflake/client/internal/core/SdkProxyRoutePlanner.java.

Existe uma condição de falsificação de solicitação no lado do servidor no componente Manipulador de Endereços IP do lintsinghua DeepAudit. O problema está relacionado ao processamento desconhecido dentro do arquivo `backend/app/api/v1/endpoints/embedding config.py`. A exploração bem-sucedida permite a iniciação remota do ataque. O endpoint de API afetado é `/api/v1/endpoints/embedding config`.

Existe um problema de segurança no MindsDB relacionado à falsificação de solicitação do lado do servidor. Isso ocorre pela manipulação da função `clear filename` no arquivo `mindsdb/utilities/security.py`, especificamente no componente de Upload de Arquivos. O problema é explorável remotamente e foi divulgado publicamente.

Existe uma falha de segurança no jeecgboot jeewx-boot. A manipulação do argumento `imgurl` na função `getImgUrl` dentro do arquivo WxActGoldeneggsPrizesController.java pode levar a path traversal. A exploração remota é possível e um exploit foi divulgado publicamente. A correção inicial do problema pode ser contornada com codificação adicional.

Nome do Software Vulnerável e Versões Afetadas: Versões do DataEase anteriores à 2.10.12 Descrição: O DataEase é uma ferramenta de inteligência de negócios e visualização de dados de código aberto. Antes da versão 2.10.12, existe um bypass de Execução Remota de Código (RCE) via H2 JDBC. Se a URL JDBC atender a critérios específicos, o método `getJdbcUrl` retorna o parâmetro `JdbcUrl`, contornando a lógica de filtragem do H2 e permitindo a especificação do driver H2 para a conexão JDBC via `"driver":"org.h2.Driver"`. Recomendações: Atualize o DataEase para a versão 2.10.12 ou posterior.