Racerz-Fighting

Existe um problema onde o mapeamento Guice do `MediaFilter` em `WebModule.java` e o `ResourceServlet` do Jetty em `WebServer.java` interpretam parâmetros de caminho de forma diferente no endpoint '/api/media/*'. Um invasor não autenticado pode ignorar as verificações de autorização de sessão e dispositivo inserindo um ponto e vírgula no limite do Servlet, caso conheça ou adivinhe o ID único do dispositivo e o nome do arquivo de mídia. Isso ocorre porque o Jetty despacha o caminho não canônico para o `ResourceServlet`, permitindo a divulgação apenas de leitura de arquivos de mídia protegidos, como fotografias, áudio ou vídeo. Proxies reversos que rejeitam ou reescrevem parâmetros de caminho com ponto e vírgula podem bloquear essas solicitações.

Existe uma confusão de autoridade por barra invertida no fluxo de autenticação de URL baseado em cabeçalhos do Jira e Confluence. A função `validate url for ssrf()` interpreta a autoridade de uma URL de forma diferente da camada de conexão Requests. Ao utilizar uma URL manipulada contendo uma barra invertida antes de uma sintaxe semelhante a informações de usuário, um invasor pode ignorar as proteções de SSRF (Server-Side Request Forgery). Neste cenário, a função de validação identifica um nome de host externo como o alvo, enquanto o cliente HTTP se conecta a um host interno, permitindo solicitações do lado do servidor a recursos de rede protegidos, como serviços de loopback ou internos. Este problema pode ser acionado através do endpoint `POST /mcp` ao fornecer uma URL maliciosa nos cabeçalhos `X-Atlassian-Jira-Url` ou `X-Atlassian-Confluence-Url`.

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 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.

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.

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.

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.

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.

O vLLM é um mecanismo de inferência e serviço para modelos de linguagem de grande porte (LLMs). Um mecanismo de proteção contra Falsificação de Solicitação do Lado do Servidor (SSRF) implementado na versão 0.15.1 pode ser contornado no método `load from url async`. Esse contorno ocorre devido ao comportamento inconsistente de análise de URL entre a camada de validação e o cliente HTTP real. A camada de validação utiliza `urllib3.util.parse url()`, enquanto o cliente HTTP usa `aiohttp` com a biblioteca `yarl` para análise de URL. Esses analisadores tratam os caracteres de barra invertida (``) de maneira diferente, permitindo que um atacante contorne a verificação da lista de permissões de hostname e possivelmente acesse serviços internos ou externos arbitrários, resultando em um ataque SSRF completo. O componente vulnerável está localizado no arquivo `vllm/connections.py`, especificamente dentro da função `load from url async`. O cenário de ataque envolve fornecer uma URL maliciosa como `https://httpbin.org@evil.com/`.

Nome do Software Vulnerável e Versões Afetadas: Versões do itranswarp até a 2.19 Descrição: Controle de acesso incorreto na função `doFilter` permite que atacantes acessem componentes sensíveis sem autenticação. Recomendações: Atualize o itranswarp para uma versão superior à 2.19.

Nome do Software Vulnerável e Versões Afetadas: Versões do WinterChenS my-site até o commit 6c79286 (2025-06-11) Descrição: Um bypass de autenticação permite acesso não autorizado à API `/admin/` sem um token. Recomendações: Versões anteriores ao commit 6c79286 (2025-06-11) devem ser atualizadas.

The issue is related to incorrect access control in the component `/admin/sys/datasource/ajaxList` of jeeweb-mybatis-springboot, allowing attackers to access sensitive information via a crafted payload. This can lead to unauthorized information disclosure.

O problema está relacionado a um controle de acesso incorreto na função `doFilter()`, o que permite que atacantes acessem informações sensíveis ao enviar um payload manipulado.

O problema está relacionado a um controle de acesso incorreto no endpoint da API "/system/user/findUserList", o que permite que atacantes acessem informações sensíveis ao enviar um payload manipulado.

Uma falha no componente /manage/ do itranswarp permite que invasores contornem a autenticação por meio de uma requisição manipulada.

O problema está relacionado ao controle de acesso incorreto no componente /user/list, o que permite que invasores acessem informações sensíveis por meio de um payload manipulado.

O problema está relacionado a um controle de acesso incorreto no endpoint da API "/admin/**", o que permite que atacantes obtenham privilégios de Administrador por meio de uma requisição manipulada.

O problema está relacionado a um controle de acesso incorreto no componente "/api/user/manager", que permite que atacantes acessem informações sensíveis por meio de um payload manipulado.