Fushuling

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.

DataEase is an open source data visualization and analysis tool. The H2 database JDBC URL validation logic can be bypassed using special Unicode characters. This occurs because the case-conversion behavior of these characters differs between the validation process in DataEase and the parsing process in H2. This discrepancy allows attackers to smuggle dangerous parameters, such as `init`, within malicious H2 JDBC connection strings to achieve arbitrary code execution.

Incorrect host parsing in the `UriComponentsBuilder` component may allow applications that use it to parse and validate externally provided URL strings to be exposed to a server-side request forgery (SSRF) attack. SSRF is a flaw that allows an attacker to induce the server-side application to make requests to an unintended location.

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.

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.

An issue exists in the OSS file service URL fetch endpoint "chat/api/oss/get url" where inconsistent URL parsing between the `urlparse` validation function and the `requests` HTTP client allows for a server-side request forgery (SSRF) bypass. This enables attackers to access internal network services.

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.

An issue allows the driver to load and execute arbitrary classes when processing JDBC connection URL parameters. An actor capable of influencing the connection URL could potentially execute code within the application context, provided a suitable class exists on the application's classpath.

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 vLLM versions 0.16.0 through 0.18.99 Description vLLM, an inference and serving engine for large language models, contains a server-side request forgery (SSRF) flaw in the `download bytes from url` function. This allows an attacker who can control the batch input JSON to make the vLLM batch runner issue arbitrary HTTP/HTTPS requests from the server, without any URL validation or domain restrictions. The vulnerability resides in the `run batch.py` file, specifically within the `download bytes from url` function, which directly calls `session.get(url)` on a URL provided in the batch input JSON. The `file url` parameter within `BatchTranscriptionRequest` and `BatchTranslationRequest` is vulnerable, as it lacks domain, IP, or port restrictions. This can be exploited to target internal services reachable from the vLLM host. Recommendations Update to vLLM version 0.19.0 or later.

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.

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.

A weakness exists in the `SdkProxyRoutePlanner` function within the `JDBC URL Handler` component of snowflakedb snowflake-jdbc. Manipulation of the `nonProxyHosts` argument can lead to inefficient regular expression complexity. This issue is locally exploitable and the exploit has been publicly released. The vulnerable code is located in the file src/main/java/net/snowflake/client/internal/core/SdkProxyRoutePlanner.java.

A server-side request forgery condition exists in the IP Address Handler component of lintsinghua DeepAudit. The issue is related to unknown processing within the file `backend/app/api/v1/endpoints/embedding config.py`. Successful exploitation allows for remote initiation of the attack. The affected API endpoint is `/api/v1/endpoints/embedding config`.

A security issue exists in MindsDB related to server-side request forgery. This occurs through manipulation of the `clear filename` function within the `mindsdb/utilities/security.py` file, specifically in the File Upload component. The issue is exploitable remotely and has been publicly disclosed.

A security flaw exists in jeecgboot jeewx-boot. Manipulation of the `imgurl` argument in the `getImgUrl` function within the WxActGoldeneggsPrizesController.java file can lead to path traversal. Remote exploitation is possible, and an exploit has been publicly released. The issue's initial fix can be bypassed with additional encoding.

Name of the Vulnerable Software and Affected Versions: DataEase versions prior to 2.10.12 Description: DataEase is an open-source business intelligence and data visualization tool. Prior to version 2.10.12, a H2 JDBC Remote Code Execution (RCE) bypass exists. If the JDBC URL meets specific criteria, the `getJdbcUrl` method returns the `JdbcUrl` parameter, bypassing H2’s filtering logic and allowing the specification of the H2 driver for the JDBC connection via `"driver":"org.h2.Driver"`. Recommendations: Update DataEase to version 2.10.12 or later.