Filtered by vendor Cloudflare
Subscriptions
Total
55 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-7054 | 1 Cloudflare | 1 Quiche | 2025-08-07 | N/A |
| Cloudflare quiche was discovered to be vulnerable to an infinite loop when sending packets containing RETIRE_CONNECTION_ID frames. QUIC connections possess a set of connection identifiers (IDs); see Section 5.1 of RFC 9000 https://datatracker.ietf.org/doc/html/rfc9000#section-5.1 . Once the QUIC handshake completes, a local endpoint is responsible for issuing and retiring Connection IDs that are used by the remote peer to populate the Destination Connection ID field in packets sent from remote to local. Each Connection ID has a sequence number to ensure synchronization between peers. An unauthenticated remote attacker can exploit this vulnerability by first completing a handshake and then sending a specially-crafted set of frames that trigger a connection ID retirement in the victim. When the victim attempts to send a packet containing RETIRE_CONNECTION_ID frames, Section 19.16 of RFC 9000 https://datatracker.ietf.org/doc/html/rfc9000#section-19.6 requires that the sequence number of the retired connection ID must not be the same as the sequence number of the connection ID used by the packet. In other words, a packet cannot contain a frame that retires itself. In scenarios such as path migration, it is possible for there to be multiple active paths with different active connection IDs that could be used to retire each other. The exploit triggered an unintentional behaviour of a quiche design feature that supports retirement across paths while maintaining full connection ID synchronization, leading to an infinite loop.This issue affects quiche: from 0.15.0 before 0.24.5. | ||||
| CVE-2025-6087 | 2 Cloudflare, Opennextjs | 2 Create-cloudflare, Opennext For Cloudflare | 2025-08-06 | 9.1 Critical |
| 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/[email protected] 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: [email protected] 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. | ||||
| CVE-2025-4821 | 1 Cloudflare | 1 Quiche | 2025-08-06 | 7.5 High |
| Impact Cloudflare quiche was discovered to be vulnerable to incorrect congestion window growth, which could cause it to send data at a rate faster than the path might actually support. An unauthenticated remote attacker can exploit the vulnerability by first completing a handshake and initiating a congestion-controlled data transfer towards itself. Then, it could manipulate the victim's congestion control state by sending ACK frames covering a large range of packet numbers (including packet numbers that had never been sent); see RFC 9000 Section 19.3. The victim could grow the congestion window beyond typical expectations and allow more bytes in flight than the path might really support. In extreme cases, the window might grow beyond the limit of the internal variable's type, leading to an overflow panic. Patches quiche 0.24.4 is the earliest version containing the fix for this issue. | ||||
| CVE-2025-4820 | 1 Cloudflare | 1 Quiche | 2025-08-06 | 5.3 Medium |
| Impact Cloudflare quiche was discovered to be vulnerable to incorrect congestion window growth, which could cause it to send data at a rate faster than the path might actually support. An unauthenticated remote attacker can exploit the vulnerability by first completing a handshake and initiating a congestion-controlled data transfer towards itself. Then, it could manipulate the victim's congestion control state by sending ACK frames exercising an opportunistic ACK attack; see RFC 9000 Section 21.4. The victim could grow the congestion window beyond typical expectations and allow more bytes in flight than the path might really support. Patches quiche 0.24.4 is the earliest version containing the fix for this issue. | ||||
| CVE-2025-4366 | 1 Cloudflare | 1 Pingora | 2025-08-06 | 6.1 Medium |
| 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. | ||||
| CVE-2024-1765 | 1 Cloudflare | 1 Quiche | 2025-08-06 | 5.9 Medium |
| 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. | ||||
| CVE-2024-1410 | 1 Cloudflare | 1 Quiche | 2025-08-06 | 3.7 Low |
| Cloudflare quiche was discovered to be vulnerable to unbounded storage of information related to connection ID retirement, which could lead to excessive resource consumption. Each QUIC connection possesses a set of connection Identifiers (IDs); see RFC 9000 Section 5.1 https://datatracker.ietf.org/doc/html/rfc9000#section-5.1 . Endpoints declare the number of active connection IDs they are willing to support using the active_connection_id_limit transport parameter. The peer can create new IDs using a NEW_CONNECTION_ID frame but must stay within the active ID limit. This is done by retirement of old IDs, the endpoint sends NEW_CONNECTION_ID includes a value in the retire_prior_to field, which elicits a RETIRE_CONNECTION_ID frame as confirmation. An unauthenticated remote attacker can exploit the vulnerability by sending NEW_CONNECTION_ID frames and manipulating the connection (e.g. by restricting the peer's congestion window size) so that RETIRE_CONNECTION_ID frames can only be sent at a slower rate than they are received, leading to storage of information related to connection IDs in an unbounded queue. Quiche versions 0.19.2 and 0.20.1 are the earliest to address this problem. There is no workaround for affected versions. | ||||
| CVE-2025-0651 | 1 Cloudflare | 1 Warp | 2025-07-31 | 7.1 High |
| Improper Privilege Management vulnerability in Cloudflare WARP on Windows allows File Manipulation. User with a low system privileges can create a set of symlinks inside the C:\ProgramData\Cloudflare\warp-diag-partials folder. After triggering the 'Reset all settings" option the WARP service will delete the files that the symlink was pointing to. Given the WARP service operates with System privileges this might lead to deleting files owned by the System user. This issue affects WARP: before 2024.12.492.0. | ||||
| CVE-2021-3978 | 1 Cloudflare | 1 Octorpki | 2025-07-29 | 7.5 High |
| When copying files with rsync, octorpki uses the "-a" flag 0, which forces rsync to copy binaries with the suid bit set as root. Since the provided service definition defaults to root ( https://github.com/cloudflare/cfrpki/blob/master/package/octorpki.service ) this could allow for a vector, when combined with another vulnerability that causes octorpki to process a malicious TAL file, for a local privilege escalation. | ||||
| CVE-2024-0212 | 1 Cloudflare | 1 Cloudflare | 2025-06-06 | 8.1 High |
| 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. | ||||
| CVE-2022-2529 | 1 Cloudflare | 1 Goflow | 2025-05-20 | 7.5 High |
| 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. | ||||
| CVE-2025-4143 | 1 Cloudflare | 1 Workers-oauth-provider | 2025-05-12 | 6.1 Medium |
| The OAuth implementation in workers-oauth-provider that is part of MCP framework https://github.com/cloudflare/workers-mcp , did not correctly validate that redirect_uri was on the allowed list of redirect URIs for the given client registration. Fixed in: https://github.com/cloudflare/workers-oauth-provider/pull/26 https://github.com/cloudflare/workers-oauth-provider/pull/26 Impact: Under certain circumstances (see below), if a victim had previously authorized with a server built on workers-oath-provider, and an attacker could later trick the victim into visiting a malicious web site, then attacker could potentially steal the victim's credentials to the same OAuth server and subsequently impersonate them. In order for the attack to be possible, the OAuth server's authorized callback must be designed to auto-approve authorizations that appear to come from an OAuth client that the victim has authorized previously. The authorization flow is not implemented by workers-oauth-provider; it is up to the application built on top to decide whether to implement such automatic re-authorization. However, many applications do implement such logic. Note: It is a basic, well-known requirement that OAuth servers should verify that the redirect URI is among the allowed list for the client, both during the authorization flow and subsequently when exchanging the authorization code for an access token. workers-oauth-provider implemented only the latter check, not the former. Unfortunately, the former is the much more important check. Readers who are familiar with OAuth may recognize that failing to check redirect URIs against the allowed list is a well-known, basic mistake, covered extensively in the RFC and elsewhere. The author of this library would like everyone to know that he was, in fact, well-aware of this requirement, thought about it a lot while designing the library, and then, somehow, forgot to actually make sure the check was in the code. That is, it's not that he didn't know what he was doing, it's that he knew what he was doing but flubbed it. | ||||
| CVE-2025-4144 | 1 Cloudflare | 1 Workers-oauth-provider | 2025-05-12 | 9.8 Critical |
| PKCE was implemented in the OAuth implementation in workers-oauth-provider that is part of MCP framework https://github.com/cloudflare/workers-mcp . However, it was found that an attacker could cause the check to be skipped. Fixed in: https://github.com/cloudflare/workers-oauth-provider/pull/27 https://github.com/cloudflare/workers-oauth-provider/pull/27 Impact: PKCE is a defense-in-depth mechanism against certain kinds of attacks and was an optional extension in OAuth 2.0 which became required in the OAuth 2.1 draft. (Note that the MCP specification requires OAuth 2.1.). This bug completely bypasses PKCE protection. | ||||
| CVE-2022-3321 | 1 Cloudflare | 1 Warp Mobile Client | 2025-05-08 | 6.7 Medium |
| 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. | ||||
| CVE-2022-3512 | 1 Cloudflare | 1 Warp | 2025-05-06 | 6.7 Medium |
| Using warp-cli command "add-trusted-ssid", a user was able to disconnect WARP client and bypass the "Lock WARP switch" feature resulting in Zero Trust policies not being enforced on an affected endpoint. | ||||
| CVE-2022-3337 | 1 Cloudflare | 1 Warp Mobile Client | 2025-05-06 | 6.7 Medium |
| 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. | ||||
| CVE-2022-3322 | 1 Cloudflare | 1 Warp Mobile Client | 2025-05-05 | 6.7 Medium |
| 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. | ||||
| CVE-2022-3616 | 1 Cloudflare | 1 Octorpki | 2025-05-05 | 5.4 Medium |
| Attackers can create long chains of CAs that would lead to OctoRPKI exceeding its max iterations parameter. In consequence it would cause the program to crash, preventing it from finishing the validation and leading to a denial of service. Credits to Donika Mirdita and Haya Shulman - Fraunhofer SIT, ATHENE, who discovered and reported this vulnerability. | ||||
| CVE-2022-3320 | 1 Cloudflare | 1 Warp | 2025-05-05 | 6.7 Medium |
| 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. | ||||
| CVE-2014-125026 | 1 Cloudflare | 1 Golz4 | 2025-04-11 | 9.8 Critical |
| LZ4 bindings use a deprecated C API that is vulnerable to memory corruption, which could lead to arbitrary code execution if called with untrusted user input. | ||||