Zer0Yu

The Jetty URI parser exhibits differences in how it evaluates invalid or unusual URIs compared to other common parsers. This differential parsing of URIs, particularly in systems with multiple components, can lead to security bypasses. A component enforcing a blacklist, for example, might interpret URIs differently from a component generating a response. At a minimum, this discrepancy can reveal implementation details.

An issue exists that allows an attacker to cause a Denial-of-Service (DoS) condition. This is achieved by using a specially crafted JSON Web Encryption (JWE) token that has an exceptionally high compression ratio.

Name of the Vulnerable Software and Affected Versions: symfony/http-foundation versions prior to 5.4.46 symfony/http-foundation versions prior to 6.4.14 symfony/http-foundation versions prior to 7.1.7 Description: The `Request` class in symfony/http-foundation does not parse URI with special characters the same way browsers do. As a result, an attacker can trick a validator relying on the `Request` class to redirect users to another domain. The issue has been patched, and users are advised to upgrade. There are no known workarounds for this issue. Recommendations: For versions prior to 5.4.46, upgrade to version 5.4.46 or later. For versions prior to 6.4.14, upgrade to version 6.4.14 or later. For versions prior to 7.1.7, upgrade to version 7.1.7 or later. As a temporary workaround, consider validating URLs manually to ensure they do not contain invalid characters as defined by https://url.spec.whatwg.org/ until a patch is applied.

The HttpURI class in Eclipse Jetty does insufficient validation on the authority segment of a URI, which can lead to differences in how it handles invalid URIs compared to common browsers. This discrepancy can make a combination of Jetty and a vulnerable browser susceptible to open redirect attacks or Server-Side Request Forgery (SSRF) attacks if the URI is used after passing validation checks. The vulnerability can be exploited by an attacker to bypass protections set up by developers for specific hosts, resulting in SSRF and URL redirection vulnerabilities.

The issue is related to the incorrect functioning of the `Is` methods (such as `IsPrivate`, `IsLoopback`, etc.) in the net-ip component of the Golang programming language. This incorrect functioning occurs when handling IPv4-mapped IPv6 addresses, where these methods return `false` for addresses that would return `true` in their traditional IPv4 forms. This could allow an attacker to bypass existing access restriction policies.

The issue is related to the incorrect handling of highly compressed input data in the go-jose package, which implements the Javascript Object Signing and Encryption set of standards. An attacker could send a JWE containing compressed data that uses large amounts of memory and CPU when decompressed by `Decrypt` or `DecryptMulti` functions. These functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger).

This issue allows an attacker with a trusted public key to cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the recipient, it results in significant memory allocation and processing time during decompression. The attacker needs to obtain a valid public key to compress the payload, which must be valid so that the recipient can use it to successfully decompress the payload. The attacker then crafts a message with a high compression ratio, such as a payload with a very high frequency of repeating patterns that can decompress to a much larger size. If the payload is large enough, the recipient who is decompressing the data will have to allocate a large amount of memory, which can lead to a denial of service.

A Server-Side Request Forgery (SSRF) issue in the `installUpdateThemePluginAction` function allows attackers to force the application to make arbitrary requests via injection of crafted URLs into the `installThemePlugin` parameter.

A Server-Side Request Forgery (SSRF) issue in the `getFileFromRepo` function allows attackers to force the application to make arbitrary requests via injection of crafted URLs into the `pluginThemeUrl` parameter. This enables attackers to manipulate the application into accessing unauthorized resources.

A Server-Side Request Forgery (SSRF) issue in weixin.php of ChatGPT-wechat-personal allows attackers to force the application to make arbitrary requests. This enables attackers to potentially access or manipulate internal or external services.

A server-side request forgery (SSRF) vulnerability exists in the `pictureproxy.php` file of ChatGPT, specifically within commit f9f4bbc. This flaw allows attackers to force the application to make arbitrary requests by injecting crafted URLs into the `url` parameter. The vulnerability is actively being exploited, with over 10,000 attack attempts recorded in a single week, primarily targeting financial and government organizations in the United States, as well as entities in Germany, Thailand, Indonesia, Colombia, and the United Kingdom. The vulnerability does not require authentication and a proof-of-concept exploit is publicly available. Approximately 35% of organizations are potentially vulnerable due to misconfigured firewalls, IPS, and WAFs. The issue was initially identified in September 2023. Exploitation can lead to unauthorized access to internal resources and potential data theft. The **API endpoint** involved is related to image proxying through `pictureproxy.php`, and the vulnerable **parameter** is `url`.

The issue allows authenticated attackers to make arbitrary requests via injection of crafted URLs, exploiting a Server-Side Request Forgery (SSRF) vulnerability. This is achieved through the `path b` parameter in the `doDiff` function of the `/classes/compareClass.php` endpoint.

The issue allows authenticated attackers to make arbitrary requests via injection of crafted URLs, exploiting a Server-Side Request Forgery (SSRF) vulnerability. This is achieved through the `path` parameter at the "/ajaxGetFileByPath.php" API endpoint.

The issue is related to a Server-Side Request Forgery (SSRF) that allows authenticated attackers to make arbitrary requests via injection of crafted URLs. This is achieved through the `path a` parameter in the `doDiff` function of the `/classes/compareClass.php` endpoint.

The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren't IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.

A security issue was discovered that allows remote attackers to force the application to make arbitrary requests via injection of arbitrary URLs into the `source` parameter, due to a Server-Side Request Forgery (SSRF) vulnerability in the zb users/plugin/UEditor/php/action crawler.php file.

The issue is related to a Server-Side Request Forgery (SSRF) that can be exploited via the `performFetchRequest` function at `HTTPFetcher.php`. This allows for potential unauthorized access to internal resources.

A Server-Side Request Forgery (SSRF) issue was found in the Index function of the PluginsController.php file, located in app/admin/c/. This allows for potential exploitation.

A Server-Side Request Forgery (SSRF) issue exists in the `getFileBinary` function, allowing attackers to force the application to make arbitrary requests by injecting arbitrary URLs into the `URL` parameter.

The issue is related to a Server-Side Request Forgery (SSRF) that was discovered in Kity Minder. This SSRF occurs via the `init` function at `ImageCapture.class.php`.