Vulnerabilities

A cache poisoning vulnerability has been found in the Pingora HTTP proxy framework’s default cache key construction. The issue occurs because the default HTTP cache key implementation generates cache keys using only the URI path, excluding critical factors such as the host header (authority). Operators relying on the default are vulnerable to cache poisoning, and cross-origin responses may be improperly served to users.<br /> <br /> <br /> Impact<br /> <br /> This vulnerability affects users of Pingora&amp;#39;s alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for:<br /> <br /> * Cross-tenant data leakage: In multi-tenant deployments, poison the cache so that users from one tenant receive cached responses from another tenant<br /> <br /> <br /> * Cache poisoning attacks: Serve malicious content to legitimate users by poisoning shared cache entries<br /> <br /> <br /> <br /> <br /> Cloudflare&amp;#39;s CDN infrastructure was not affected by this vulnerability, as Cloudflare&amp;#39;s default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default.<br /> <br /> <br /> Mitigation:<br /> <br /> We strongly recommend Pingora users to upgrade to Pingora v0.8.0 or higher, which removes the insecure default cache key implementation. Users must now explicitly implement their own callback that includes appropriate factors such as Host header, origin server HTTP scheme, and other attributes their cache should vary on.<br /> <br /> <br /> Pingora users on previous versions may also remove any of their default CacheKey usage and implement their own that should at minimum include the host header / authority and upstream peer’s HTTP scheme.

An HTTP Request Smuggling vulnerability (CWE-444) has been found in Pingora&amp;#39;s parsing of HTTP/1.0 and Transfer-Encoding requests. The issue occurs due to improperly allowing HTTP/1.0 request bodies to be close-delimited and incorrect handling of multiple Transfer-Encoding values, allowing attackers to send HTTP/1.0 requests in a way that would desync Pingora’s request framing from backend servers’.<br /> <br /> Impact<br /> <br /> This vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could craft a malicious payload following this request that Pingora forwards to the backend in order to:<br /> <br /> * Bypass proxy-level ACL controls and WAF logic<br /> <br /> <br /> <br /> <br /> * Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests<br /> <br /> <br /> <br /> <br /> * Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP<br /> <br /> <br /> <br /> <br /> Cloudflare&amp;#39;s CDN infrastructure was not affected by this vulnerability, as its ingress proxy layers forwarded HTTP/1.1 requests only, rejected ambiguous framing such as invalid Content-Length values, and forwarded a single Transfer-Encoding: chunked header for chunked requests.<br /> <br /> <br /> Mitigation:<br /> <br /> Pingora users should upgrade to Pingora v0.8.0 or higher that fixes this issue by correctly parsing message length headers per RFC 9112 and strictly adhering to more RFC guidelines, including that HTTP request bodies are never close-delimited.<br /> <br /> As a workaround, users can reject certain requests with an error in the request filter logic in order to stop processing bytes on the connection and disable downstream connection reuse. The user should reject any non-HTTP/1.1 request, or a request that has invalid Content-Length, multiple Transfer-Encoding headers, or Transfer-Encoding header that is not an exact “chunked” string match.

An HTTP request smuggling vulnerability (CWE-444) was found in Pingora&amp;#39;s handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking.<br /> <br /> Impact<br /> <br /> This vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to:<br /> <br /> * Bypass proxy-level ACL controls and WAF logic<br /> <br /> <br /> <br /> <br /> * Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests<br /> <br /> <br /> <br /> <br /> * Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP<br /> <br /> <br /> <br /> <br /> Cloudflare&amp;#39;s CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.<br /> <br /> <br /> Mitigation:<br /> <br /> Pingora users should upgrade to Pingora v0.8.0 or higher<br /> <br /> <br /> As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.

ONTAP versions 9.12.1 and higher with S3 NAS buckets are susceptible to an information disclosure vulnerability. Successful exploit could allow an authenticated attacker to view a listing of the contents in a directory for which they lack permission.

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.12.4, when using serveStatic together with route-based middleware protections (e.g. app.use(&amp;#39;/admin/*&amp;#39;, ...)), inconsistent URL decoding allowed protected static resources to be accessed without authorization. The router used decodeURI, while serveStatic used decodeURIComponent. This mismatch allowed paths containing encoded slashes (%2F) to bypass middleware protections while still resolving to the intended filesystem path. This issue has been patched in version 4.12.4.

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.12.4, when using streamSSE() in Streaming Helper, the event, id, and retry fields were not validated for carriage return (\r) or newline (\n) characters. Because the SSE protocol uses line breaks as field delimiters, this could allow injection of additional SSE fields within the same event frame if untrusted input was passed into these fields. This issue has been patched in version 4.12.4.

Hono is a Web application framework that provides support for any JavaScript runtime. Prior to version 4.12.4, the setCookie() utility did not validate semicolons (;), carriage returns (\r), or newline characters (\n) in the domain and path options when constructing the Set-Cookie header. Because cookie attributes are delimited by semicolons, this could allow injection of additional cookie attributes if untrusted input was passed into these fields. This issue has been patched in version 4.12.4.

The import hook in CPython that handles legacy *.pyc files (SourcelessFileLoader) is incorrectly handled in FileLoader (a base class) and so does not use io.open_code() to read the .pyc files. sys.audit handlers for this audit event therefore do not fire.

Suprema’s BioStar 2 in version 2.9.11.6 allows users to set new password without providing the current one. Exploiting this flaw combined with other vulnerabilities can lead to unauthorized account access and potential system compromise.

Open OnDemand is an open-source high-performance computing portal. The Files application in OnDemand versions prior to 4.0.9 and 4.1.3 is susceptible to malicious input when navigating to a directory. This has been patched in versions 4.0.9 and 4.1.3. Versions below this remain susceptible.

Vaultwarden is an unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs. Prior to version 1.35.4, there is a privilege escalation vulnerability via bulk permission update to unauthorized collections by Manager. This issue has been patched in version 1.35.4.

Vaultwarden is an unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs. Prior to version 1.35.4, when a Manager has manage=false for a given collection, they can still perform several management operations as long as they have access to the collection. This issue has been patched in version 1.35.4.