Cloudflare Quiche (through version 0.19.1/0.20.0) was affected by an unlimited resource allocation vulnerability causing rapid increase of memory usage of the system running quiche server or client.
A remote attacker could take advantage of this vulnerability by repeatedly sending an unlimited number of 1-RTT CRYPTO frames after previously completing the QUIC handshake.
Exploitation was possible for the duration of the connection which could be extended by the attacker.
quiche 0.19.2 and 0.20.1 are the earliest versions containing the fix for this issue.
The Cloudflare Wordpress plugin was found to be vulnerable to improper authentication. The vulnerability enables attackers with a lower privileged account to access data from the Cloudflare API.
Cloudflare version of zlib library was found to be vulnerable to memory corruption issues affecting the deflation algorithm implementation (deflate.c). The issues resulted from improper input validation and heap-based buffer overflow.
A local attacker could exploit the problem during compression using a crafted malicious file potentially leading to denial of service of the software.
Patches: The issue has been patched in commit 8352d10 https://github.com/cloudflare/zlib/commit/8352d108c05db1bdc5ac3bdf834dad641694c13c . The upstream repository is not affected.
Sending specially crafted HTTP requests to Miniflare's server could result in arbitrary HTTP and WebSocket requests being sent from the server. If Miniflare was configured to listen on external network interfaces (as was the default in wrangler until 3.19.0), an attacker on the local network could access other local servers.
Sending specially crafted HTTP requests and inspector messages to Wrangler's dev server could result in any file on the user's computer being accessible over the local network. An attacker that could trick any user on the local network into opening a malicious website could also read any file.
The V8 inspector intentionally allows arbitrary code execution within the Workers sandbox for debugging. wrangler dev would previously start an inspector server listening on all network interfaces. This would allow an attacker on the local network to connect to the inspector and run arbitrary code. Additionally, the inspector server did not validate Origin/Host headers, granting an attacker that can trick any user on the local network into opening a malicious website the ability to run code. If wrangler dev --remote was being used, an attacker could access production resources if they were bound to the worker.
This issue was fixed in wrangler@3.19.0 and wrangler@2.20.2. Whilst wrangler dev's inspector server listens on local interfaces by default as of wrangler@3.16.0, an SSRF vulnerability in miniflare https://github.com/cloudflare/workers-sdk/security/advisories/GHSA-fwvg-2739-22v7 (CVE-2023-7078) allowed access from the local network until wrangler@3.18.0. wrangler@3.19.0 and wrangler@2.20.2 introduced validation for the Origin/Host headers.
quiche v. 0.15.0 through 0.19.0 was discovered to be vulnerable to unbounded queuing of path validation messages, which could lead to excessive resource consumption.
QUIC path validation (RFC 9000 Section 8.2) requires that the recipient of a PATH_CHALLENGE frame responds by sending a PATH_RESPONSE. An unauthenticated remote attacker can exploit the vulnerability by sending PATH_CHALLENGE frames and manipulating the connection (e.g. by restricting the peer's congestion window size) so that PATH_RESPONSE frames can only be sent at the slower rate than they are received; leading to storage of path validation data in an unbounded queue.
Quiche versions greater than 0.19.0 address this problem.
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.
Zero Trust Administrators have the ability to disallow end users from disabling WARP on their devices. Override codes can also be created by the Administrators to allow a device to temporarily be disconnected from WARP, however, due to lack of server side validation, an attacker with local access to the device, could extend the maximum allowed disconnected time of WARP client granted by an override code by changing the date & time on the local device where WARP is running.
Due to a misconfiguration, the WARP Mobile Client (< 6.29) for Android was susceptible to a tapjacking attack. In the event that an attacker built a malicious application and managed to install it on a victim's device, the attacker would be able to trick the user into believing that the app shown on the screen was the WARP client when in reality it was the attacker's app.