Search 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. Impact This vulnerability affects users of Pingora's alpha proxy caching feature who relied on the default CacheKey implementation. An attacker could exploit this for: * Cross-tenant data leakage: In multi-tenant deployments, poison the cache so that users from one tenant receive cached responses from another tenant * Cache poisoning attacks: Serve malicious content to legitimate users by poisoning shared cache entries Cloudflare's CDN infrastructure was not affected by this vulnerability, as Cloudflare's default cache key implementation uses multiple factors to prevent cache key poisoning and never made use of the previously provided default. Mitigation: 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. 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'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’. Impact 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: * Bypass proxy-level ACL controls and WAF logic * Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests * Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP Cloudflare'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. Mitigation: 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. 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.

The CombinedMult function in the CIRCL ecc/p384 package (secp384r1 curve) produces an incorrect value for specific inputs. The issue is fixed by using complete addition formulas. ECDH and ECDSA signing relying on this curve are not affected. The bug was fixed in v1.6.3 https://github.com/cloudflare/circl/releases/tag/v1.6.3 .

In gokey versions <0.2.0, a flaw in the seed decryption logic resulted in passwords incorrectly being derived solely from the initial vector and the AES-GCM authentication tag of the key seed. This issue has been fixed in gokey version 0.2.0. This is a breaking change. The fix has invalidated any passwords/secrets that were derived from the seed file (using the -s option). Even if the input seed file stays the same, version 0.2.0 gokey will generate different secrets. Impact This vulnerability impacts generated keys/secrets using a seed file as an entropy input (using the -s option). Keys/secrets generated just from the master password (without the -s option) are not impacted. The confidentiality of the seed itself is also not impacted (it is not required to regenerate the seed itself). Specific impact includes: * keys/secrets generated from a seed file may have lower entropy: it was expected that the whole seed would be used to generate keys (240 bytes of entropy input), where in vulnerable versions only 28 bytes was used * a malicious entity could have recovered all passwords, generated from a particular seed, having only the seed file in possession without the knowledge of the seed master password Patches The code logic bug has been fixed in gokey version 0.2.0 and above. Due to the deterministic nature of gokey, fixed versions will produce different passwords/secrets using seed files, as all seed entropy will be used now. System secret rotation guidance It is advised for users to regenerate passwords/secrets using the patched version of gokey (0.2.0 and above), and provision/rotate these secrets into respective systems in place of the old secret. A specific rotation procedure is system-dependent, but most common patterns are described below. Systems that do not require the old password/secret for rotation Such systems usually have a "Forgot password" facility or a similar facility allowing users to rotate their password/secrets by sending a unique "magic" link to the user's email or phone. In such cases users are advised to use this facility and input the newly generated password secret, when prompted by the system. Systems that require the old password/secret for rotation Such systems usually have a modal password rotation window usually in the user settings section requiring the user to input the old and the new password sometimes with a confirmation. To generate/recover the old password in such cases users are advised to: * temporarily download gokey version 0.1.3 https://github.com/cloudflare/gokey/releases/tag/v0.1.3 for their respective operating system to recover the old password * use gokey version 0.2.0 or above to generate the new password * populate the system provided password rotation form Systems that allow multiple credentials for the same account to be provisioned Such systems usually require a secret or a cryptographic key as a credential for access, but allow several credentials at the same time. One example is SSH: a particular user may have several authorized public keys configured on the SSH server for access. For such systems users are advised to: * generate a new secret/key/credential using gokey version 0.2.0 or above * provision the new secret/key/credential in addition to the existing credential on the system * verify that the access or required system operation is still possible with the new secret/key/credential * revoke authorization for the existing/old credential from the system Credit This vulnerability was found by Théo Cusnir ( @mister_mime https://hackerone.com/mister_mime ) and responsibly disclosed through Cloudflare's bug bounty program.

A Server-Side Request Forgery (SSRF) vulnerability was identified in the @opennextjs/cloudflare package. The vulnerability stems from an unimplemented feature in the Cloudflare adapter for Open Next, which allowed unauthenticated users to proxy arbitrary remote content via the /_next/image endpoint. This issue allowed attackers to load remote resources from arbitrary hosts under the victim site’s domain for any site deployed using the Cloudflare adapter for Open Next.  For example: https://victim-site.com/_next/image?url=https://attacker.com In this example, attacker-controlled content from attacker.com is served through the victim site’s domain (victim-site.com), violating the same-origin policy and potentially misleading users or other services. Impact: * SSRF via unrestricted remote URL loading * Arbitrary remote content loading * Potential internal service exposure or phishing risks through domain abuse Mitigation: The following mitigations have been put in place: * Server side updates to Cloudflare’s platform to restrict the content loaded via the /_next/image endpoint to images. The update automatically mitigates the issue for all existing and any future sites deployed to Cloudflare using the affected version of the Cloudflare adapter for Open Next * Root cause fix https://github.com/opennextjs/opennextjs-cloudflare/pull/727  to the Cloudflare adapter for Open Next. The patched version of the adapter is found here  @opennextjs/cloudflare@1.3.0 https://www.npmjs.com/package/@opennextjs/cloudflare/v/1.3.0 * Package dependency update https://github.com/cloudflare/workers-sdk/pull/9608  to create-cloudflare (c3) to use the fixed version of the Cloudflare adapter for Open Next. The patched version of create-cloudflare is found here:  create-cloudflare@2.49.3 https://www.npmjs.com/package/create-cloudflare/v/2.49.3 In addition to the automatic mitigation deployed on Cloudflare’s platform, we encourage affected users to upgrade to @opennext/cloudflare v1.3.0 and use the remotePatterns https://nextjs.org/docs/pages/api-reference/components/image#remotepatterns filter in Next config https://nextjs.org/docs/pages/api-reference/components/image#remotepatterns if they need to allow-list external urls with images assets.

A request smuggling vulnerability identified within Pingora’s proxying framework, pingora-proxy, allows malicious HTTP requests to be injected via manipulated request bodies on cache HITs, leading to unauthorized request execution and potential cache poisoning. Fixed in:  https://github.com/cloudflare/pingora/commit/fda3317ec822678564d641e7cf1c9b77ee3759ff https://github.com/cloudflare/pingora/commit/fda3317ec822678564d641e7cf1c9b77ee3759ff Impact: The issue could lead to request smuggling in cases where Pingora’s proxying framework, pingora-proxy, is used for caching allowing an attacker to manipulate headers and URLs in subsequent requests made on the same HTTP/1.1 connection.

The tokio-boring library in version 4.0.0 is affected by a memory leak issue that can lead to excessive resource consumption and potential DoS by resource exhaustion. The set_ex_data function used by the library did not deallocate memory used by pre-existing data in memory each time after completing a TLS connection causing the program to consume more resources with each new connection.

A vulnerability was discovered in the odoh-rs rust crate that stems from faulty logic during the parsing of encrypted queries. This issue specifically occurs when processing encrypted query data received from remote clients and enables an attacker with knowledge of this vulnerability to craft and send specially designed encrypted queries to targeted ODOH servers running with odoh-rs. Upon successful exploitation, the server will crash abruptly, disrupting its normal operation and rendering the service temporarily unavailable.

Prior to version v1.20230419.0, the FormData API implementation was subject to an integer overflow. If a FormData instance contained more than 2^31 elements, the forEach() method could end up reading from the wrong location in memory while iterating over elements. This would most likely lead to a segmentation fault, but could theoretically allow arbitrary undefined behavior. In order for the bug to be exploitable, the process would need to be able to allocate 160GB of RAM. Due to this, the bug was never exploitable on the Cloudflare Workers platform, but could theoretically be exploitable on deployments of workerd running on machines with a huge amount of memory. Moreover, in order to be remotely exploited, an attacker would have to upload a single form-encoded HTTP request of at least tens of gigabytes in size. The application code would then have to use request.formData() to parse the request and formData.forEach() to iterate over this data. Due to these limitations, the exploitation likelihood was considered Low. A fix that addresses this vulnerability has been released in version v1.20230419.0 and users are encouraged to update to the latest version available.

When sampling randomness for a shared secret, the implementation of Kyber and FrodoKEM, did not check whether crypto/rand.Read() returns an error. In rare deployment cases (error thrown by the Read() function), this could lead to a predictable shared secret. The tkn20 and blindrsa components did not check whether enough randomness was returned from the user provided randomness source. Typically the user provides crypto/rand.Reader, which in the vast majority of cases will always return the right number random bytes. In the cases where it does not, or the user provides a source that does not, the blinding for blindrsa is weak and integrity of the plaintext is not ensured in tkn20.

Lock Warp switch is a feature of Zero Trust platform which, when enabled, prevents users of enrolled devices from disabling WARP client. Due to insufficient policy verification by WARP iOS client, this feature could be bypassed by using the "Disable WARP" quick action.

It was possible to bypass policies configured for Zero Trust Secure Web Gateway by using warp-cli 'set-custom-endpoint' subcommand. Using this command with an unreachable endpoint caused the WARP Client to disconnect and allowed bypassing administrative restrictions on a Zero Trust enrolled endpoint.

It was possible to bypass Lock WARP switch feature https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/warp-settings/#lock-warp-switch  on the WARP iOS mobile client by enabling both "Disable for cellular networks" and "Disable for Wi-Fi networks" switches at once in the application settings. Such configuration caused the WARP client to disconnect and allowed the user to bypass restrictions and policies enforced by the Zero Trust platform.

It was possible for a user to delete a VPN profile from WARP mobile client on iOS platform despite the Lock WARP switch https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/warp-settings/#lock-warp-switch  feature being enabled on Zero Trust Platform. This led to bypassing policies and restrictions enforced for enrolled devices by the Zero Trust platform.

sflow decode package does not employ sufficient packet sanitisation which can lead to a denial of service attack. Attackers can craft malformed packets causing the process to consume large amounts of memory resulting in a denial of service.

By using warp-cli subcommands (disable-ethernet, disable-wifi), it was possible for a user without admin privileges to bypass configured Zero Trust security policies (e.g. Secure Web Gateway policies) and features such as 'Lock WARP switch'.

Cloudflare WARP client for Windows (up to v. 2022.5.309.0) allowed creation of mount points from its ProgramData folder. During installation of the WARP client, it was possible to escalate privileges and overwrite SYSTEM protected files.

Cloudflare Warp for Windows from version 2022.2.95.0 contained an unquoted service path which enables arbitrary code execution leading to privilege escalation. The fix was released in version 2022.3.186.0.

Cloudflare WARP for Windows allows privilege escalation due to an unquoted service path. A malicious user or process running with non-administrative privileges can become an administrator by abusing the unquoted service path issue. Since version 1.2.2695.1, the vulnerability was fixed by adding quotes around the service's binary path. This issue affects Cloudflare WARP for Windows, versions prior to 1.2.2695.1.