Racerz-Fighting

An issue exists where the `MediaFilter` Guice mapping in `WebModule.java` and the Jetty `ResourceServlet` in `WebServer.java` interpret path parameters differently at the '/api/media/*' endpoint. An unauthenticated attacker can bypass session and device authorization checks by inserting a semicolon at the Servlet boundary if they know or guess a device unique ID and media filename. This occurs because Jetty dispatches the noncanonical path to the `ResourceServlet`, allowing read-only disclosure of protected media files such as photographs, audio, or video. Reverse proxies that reject or rewrite semicolon path parameters may block these requests.

A backslash authority confusion exists in the header-based Jira and Confluence URL authentication flow. The `validate url for ssrf()` function interprets the authority of a URL differently than the Requests connection layer. By using a crafted URL containing a backslash before userinfo-like syntax, an attacker can bypass SSRF (Server-Side Request Forgery) protections. In this scenario, the validation function identifies an external hostname as the target, while the HTTP client connects to an internal host, allowing unauthorized server-side requests to protected network resources, such as loopback or internal services. This issue can be triggered via the `POST /mcp` endpoint by providing a malicious URL in the `X-Atlassian-Jira-Url` or `X-Atlassian-Confluence-Url` headers.

A logical flaw exists in the URL validation process that allows for Server-Side Request Forgery (SSRF). The ` is safe url()` function uses `urlparse` to validate remote media URLs, while `requests.Session().get` interprets backslashes differently when sending the request. An attacker can provide a specially crafted URL containing a backslash that causes `urlparse` to identify a globally routable hostname, while the actual request is routed to an internal host. This discrepancy allows attackers to bypass non-global address checks and induce applications to access internal HTTP services, potentially exposing sensitive data.

Restrictions on redirect URLs can be bypassed, leading to open redirect attacks. The issue occurs because the validation logic only verifies that the host and schema of the redirect URL match the current website, subsequently using only the path part for the redirection. An attacker can bypass this by providing a URL where the path begins with `//`, such as `http://127.0.0.1:25222//fushuling.com`. Browsers interpret paths starting with `//` as protocol-relative URLs, which redirects the user to an external domain. This is triggered via the `Referer` header.

Speakr is a self-hosted web application for transcribing audio recordings. The `is safe url()` helper function, used to validate post-login redirect targets, incorrectly applies `urljoin(request.host url, target)` before parsing, while the controller passes the raw target to the `redirect()` function. This allows a scheme-relative input, such as `////evil.com`, to be validated as a same-host URL but interpreted by the browser as a network-path-relative redirect to an external attacker-controlled host via the Location header.

A logical flaw in the URL checking logic allows attackers to bypass security filters, leading to Server-Side Request Forgery (SSRF). The software uses the `validate url` function to perform security checks on the host portion of a URL extracted by `urlparse`. However, a discrepancy exists between how `urlparse` and the `requests` library parse URLs. For example, in the `safe get()` function, `validate url` may identify a URL as pointing to a public IP, while `requests.get` interprets the same URL as pointing to an internal address. This occurs because `urlparse` may treat certain characters, such as backslashes, as regular characters, whereas `requests` may treat them as path characters, allowing an attacker to redirect requests to internal network resources.

A mismatch in URL parsing allows the bypass of webhook URL validation. The system used Python's `urllib.parse.urlparse` for validation but `requests.post` to send the request. For malformed inputs containing backslashes and @, these components may disagree on the target hostname. This allows a URL to appear as an allowlisted public hostname during validation while the HTTP client connects to a different host, such as loopback, private, or non-allowlisted destinations. This results in a Server-Side Request Forgery (SSRF), where the server is induced to make an unintended outbound HTTP POST request.

A logical flaw in the URL checking logic allows attackers to bypass security filters, leading to Server-Side Request Forgery (SSRF). The system uses the ` validate url()` function to perform security checks on the host portion of a URL extracted by `urlparse()`. However, a discrepancy exists between how `urlparse()` and the `requests` library parse certain URLs. For example, in a URL like `http://127.0.0.1:6666@1.1.1.1`, `urlparse()` identifies the hostname as `1.1.1.1` (a public address), while `requests` interprets it as `127.0.0.1` (an internal address). This inconsistency allows requests to be routed to internal network addresses despite passing the initial validation.

Name of the Vulnerable Software and Affected Versions JupyterHub versions prior to 5.4.4 Description A flaw in JupyterHub allows attackers to create links that redirect users to a JupyterHub login page, and then to an attacker-controlled site instead of a legitimate JupyterHub page. This bypasses JupyterHub's security checks. Recommendations Upgrade to JupyterHub version 5.4.4.

Windows media loaders fail to perform local-path validation before accepting remote-host file URLs and UNC-style paths (Universal Naming Convention, a standard for specifying the location of shared resources on a network). This allows attackers to provide network-hosted file targets that the system treats as local content, bypassing intended access restrictions.

vLLM is an inference and serving engine for large language models (LLMs). A Server-Side Request Forgery (SSRF) protection mechanism implemented in version 0.15.1 can be bypassed in the `load from url async` method. This bypass occurs due to inconsistent URL parsing behavior between the validation layer and the actual HTTP client. The validation layer uses `urllib3.util.parse url()` while the HTTP client uses `aiohttp` with the `yarl` library for URL parsing. These parsers handle backslash characters (``) differently, allowing an attacker to bypass the hostname allowlist check and potentially access arbitrary internal or external services, resulting in a full SSRF attack. The vulnerable component is located in the `vllm/connections.py` file, specifically within the `load from url async` function. The attack scenario involves providing a malicious URL such as `https://httpbin.org@evil.com/`.

Name of the Vulnerable Software and Affected Versions: itranswarp versions up to 2.19 Description: Incorrect access control in the `doFilter` function allows attackers to access sensitive components without authentication. Recommendations: Update itranswarp to a version later than 2.19.

Name of the Vulnerable Software and Affected Versions: WinterChenS my-site versions through commit 6c79286 (2025-06-11) Description: An authentication bypass allows unauthorized access to the `/admin/` API without a token. Recommendations: Versions prior to commit 6c79286 (2025-06-11) should be updated.

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.

The issue is related to incorrect access control in the `doFilter()` function, which allows attackers to access sensitive information by sending a crafted payload.

The issue is related to incorrect access control in the "/system/user/findUserList" API endpoint, which allows attackers to access sensitive information by sending a crafted payload.

An issue in the component /manage/ of itranswarp allows attackers to bypass authentication via a crafted request.

The issue is related to incorrect access control in the component /user/list, which allows attackers to access sensitive information via a crafted payload.

The issue is related to incorrect access control in the "/admin/**" API endpoint, which allows attackers to gain access to Admin rights via a crafted request.

The issue is related to incorrect access control in the component "/api/user/manager" that allows attackers to access sensitive information via a crafted payload.