| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Summary
Before version 0.8.1, Pingora's HTTP/2 server used the h2 crate's default limits unless the application set its own 16 MiB decoded header-list size and no limit on concurrent streams. A remote, unauthenticated client can send 1-byte HPACK references to a near-empty header, making the server allocate hundreds of thousands of header fields per stream across an unlimited number of streams on one connection, and use HTTP/2 flow control to keep those streams open. This can exhaust memory and degrade or terminate the Pingora process.
Impact
Remote, unauthenticated denial of service against any Pingora service that terminates HTTP/2 (h2 or h2c) without explicitly setting max_header_list_size and max_concurrent_streams. The reporter showed that a single connection could get a Pingora process with a 2 GiB memory limit OOM-killed.
Note that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.
Mitigation:
*
Upgrade to pingora 0.8.1 or later (fix: https://github.com/cloudflare/pingora/commit/d193c8d49b8b7c1c1ede93183759caa4f6906bbd ). When no H2Options are supplied, Pingora now advertises and enforces a 64 KiB decoded header-list limit and at most 100 concurrent streams per connection.
*
Applications that supply their own H2Options are not covered by these defaults and must set max_header_list_size and max_concurrent_streams explicitly (this also works on versions before 0.8.1), or, on 0.8.1 and later, start from pingora_core::protocols::http::v2::server::default_h2_options(). H2Options::default() does not include these limits. |
| Summary
Before version 0.9.0, Pingora accepted HTTP/2 requests whose Host header differed from the :authority pseudo-header. Request filters, cache keys, and logs that read the request URI (session.req_header().uri) saw the :authority value, but the upstream received the client-supplied Host value. Pingora also accepted :authority values containing userinfo (for example, user@example.com). This violates RFC 9113 Section 8.3.1, which requires an intermediary to use the :authority value for Host and replace any existing Host field.
Root cause
*
HTTP/2 to HTTP/1.1: Host was generated from :authority only when the request had no Host header, so a conflicting client Host was forwarded unchanged.
*
HTTP/2 to HTTP/2: the client Host header was removed and used to overwrite the upstream :authority, after request filters had already run against the original :authority.
*
The HTTP/2 server did not compare Host with :authority and did not reject userinfo in the authority.
Impact
A remote, unauthenticated attacker can send a single HTTP/2 request that the application sees as one host and the upstream receives as another. Where request filters, access controls, or cache keys use the URI authority and the upstream routes by Host, this can lead to:
*
Cache poisoning: a response from another virtual host is stored under the victim host's cache key and served to other users (this also requires the upstream to serve different content per Host).
*
Host-based access control bypass: a request approved for one host is served by a different virtual host on the upstream.
Deployments that do not accept HTTP/2 from clients, or that do not use the request authority for security or caching decisions, are not affected.
Note that Cloudflare CDN customers were unaffected, as internal Pingora services at Cloudflare do not have HTTP/2 clients.
Mitigation:
*
Upgrade to pingora 0.9.0 or later. Pingora now returns 400 Bad Request for HTTP/2 requests whose Host differs from :authority, that contain more than one Host, or whose authority contains userinfo, and keeps the upstream Host or :authority consistent with the request authority. Fix commits: https://github.com/cloudflare/pingora/commit/915590a91811877795531f6ba0927a3138b5cb4b , https://github.com/cloudflare/pingora/commit/ffab8302d08d4292d1924eb8fe84647fd5cb8e76
*
If you cannot upgrade: in request_filter, reject HTTP/2 requests that carry a Host header different from the URI authority, or whose authority contains '@'. |
| Summary
Before version 0.9.0, the HTTP/1 upstream path in pingora-proxy passed the downstream request through upstream_request_filter and wrote it to the upstream without removing the client's Connection header, other hop-by-hop headers, or the headers Connection nominated, although RFC 9110 Section 7.6.1 requires intermediaries to remove them. The HTTP/2 upstream path already removed Connection and related HTTP/1-specific headers. A client could therefore nominate a header that the application adds in upstream_request_filter (for example, Connection: keep-alive, X-Forwarded-For). A downstream HTTP/1 intermediary that honors Connection would then strip the Pingora-added header before it reached the origin.
Impact
Specifically affects chained deployments where an HTTP/1 intermediary between Pingora and the origin processes Connection nominations (for example, Go's net/http/httputil.ReverseProxy) and the origin trusts headers added by that intermediary (for example, X-Forwarded-For for IP-based authorization). A remote, unauthenticated attacker can have those headers removed, potentially bypassing authorization. The reporter demonstrated access to an IP-restricted endpoint using X-Forwarded-For for IP validation on the origin. This is the same class of issue as CVE-2022-31813 in Apache HTTP Server.
Note that Cloudflare CDN customers were unaffected, as no such chained deployment as described above exists with internal Pingora services, and Connection headers are sanitized before arriving at Pingora gateways.
Mitigation:
*
Upgrade to pingora 0.9.0 or later. By default, Pingora now removes hop-by-hop and Connection-nominated headers from upstream requests, and rejects requests whose Connection header nominates Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, or a pseudo-header. This is controlled by PeerOptions::http_upstream_request_policy (HttpUpstreamRequestPolicy). Fix commits: https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded , https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee
*
Do not use HttpUpstreamRequestPolicy::preserve() if the origin relies on headers added by Pingora; it restores the old passthrough behavior.
*
If you cannot upgrade: in upstream_request_filter, remove the Connection header and every header it nominates before adding trusted headers. |
| Description
Cloudflare was recently notified by external researchers of vulnerabilities in this archived repository, including a remote code execution issue in `src/index.ts` reachable from certain GitHub Actions workflow configurations. Successful exploitation may expose workflow secrets such as CLOUDFLARE_API_TOKEN and GITHUB_TOKEN to an attacker. Because this repository has been deprecated since 2024, Cloudflare will not be issuing patches. To remediate this issue, we recommend migrating to `cloudflare/wrangler-action` immediately. Consumers who have already migrated are not affected.
Sunset Date
The cloudflare/pages-action repository will be removed on 2026-09-18. Consumers must complete migration before 18th September to avoid CI disruption.
Affected Versions
All published versions of cloudflare/pages-action, including consumers pinned to the v1 moving tag.
Patched Versions
None. This repository will not receive further updates, including security patches.
Resolution / Migration Path
Migrate all workflows using cloudflare/pages-action to `cloudflare/wrangler-action` before 2026-09-18. Refer to the wrangler-action README for the equivalent step configuration and migration guidance.
Credit
Thanks to @agentka99 and @beg1nn3r for reporting their findings via Cloudflare's HackerOne program that informe |
| Summary
Cloudflare quiche's HTTP/3 layer was discovered to be vulnerable to resource exhaustion (i.e., memory) by means of specially crafted HTTP/3 frames.
Impact
HTTP/3 defines multiple frame types to support HTTP message exchanges and connection management. Each frame has a length and a payload whose length depends on the frame type. quiche was found to be vulnerable when parsing some frame types to pre-allocating memory based on the declared length. An attacker would not need to send the number of declared bytes to trigger this issue.
In addition, quiche was found to not apply QPACK decompression limits correctly. This could allow an attacker to send specially crafted HEADERS frames that would cause more memory commitment than otherwise advertised by MAX_FIELD_SECTION_SIZE (configured by set_max_field_section_size()).
Mitigation:
*
Users are requested to upgrade to quiche 0.29.3 which is the earliest version containing the fix for this issue.
Credits: Disclosed responsibly by Sébastien Féry |
| Summary
Cloudflare quiche was discovered to be vulnerable to memory resource exhaustion due to unbounded queuing of post-handshake client migration events.
Impact
quiche supports the connection migration features described in Section 9 of RFC 9000, which allows a single QUIC connection to survive changes in the network path. Although quiche implements the protections described in Section 9.3 of RFC 9000 to limit server state commitment, it was discovered that the collection of PathEvents, intended to be consumed by applications via the path_event_next() function, was not bounded.
Once the QUIC handshake completed, a peer could exploit rapid source address migration in order to cause unbounded queuing of the PathEvent::ReusedSourceConnectionId type. Servers are vulnerable even if active connection migration is disabled.
Mitigation:
*
Applications can call path_event_next() to drain the PathEvent collection, mitigating the attack.
*
Users are requested to upgrade to quiche 0.29.3 which is the earliest version that prevents excessive queueing of PathEvent::ReusedSourceConnectionId. |
| Description:
To issue and renew TLS certificates on behalf of customers, Cloudflare's Universal SSL feature automatically manages the CAA RRset for the customer's zone. This auto-managed RRset is permissive by design (e.g. 'issue "letsencrypt.org"' without parameters). On Universal SSL zones, Cloudflare's authoritative DNS serves this auto-managed RRset at query time, superseding any customer-configured CAA records on the zone. When a customer publishes a stricter CAA record using the RFC 8657 accounturi or validationmethods parameters, the Certificate Authority does not observe those parameters when evaluating the served RRset under RFC 8659. As a result, the RFC 8657 account-binding and validation-method-binding protections are not enforced end-to-end on Universal SSL zones. Successful exploitation could result in issuance of a browser-trusted TLS certificate to an attacker, enabling MITM against the affected domain.
Exploitation is non-trivial in practice: an attacker would need to hold an ACME account at one of the Certificate Authorities in the served CAA RRset and to simultaneously satisfy domain control validation across the multiple geographically distinct Network Perspectives the CA relies on for Multi-Perspective Issuance Corroboration. Cloudflare prefixes are anycast-announced from hundreds of locations globally, raising the bar against single-vantage-point BGP hijacks. Any resulting misissuance of a browser-trusted certificate is subject to Certificate Transparency logging required by major browsers, and would be visible to CT monitoring.
Mitigation:
Customers requiring strict RFC 8657 enforcement need to disable Universal SSL on the affected zone.
Universal SSL's automatic CAA management and customer-set RFC 8657 accounturi and validationmethods enforcement are mutually exclusive by the nature of the issue, so there is no in-product workaround that preserves both.
Certificate Transparency monitoring is recommended for all customers as a general detection control.
Credits:
David Osipov (ORCID: https://orcid.org/0009-0005-2713-9242), independent researcher |
| Cloudflare Quiche was affected by 2 use-after-free vulnerabilities in the connection ID iterator FFI functions.
The “quiche_connection_id_iter_next” and “quiche_conn_retired_scid_next” functions would return a pointer to a “ConnectionId” to the applications via function arguments, but the owned “ConnectionId” would be dropped at the end of those functions' scope.
Only applications using those FFI functions are affected. The FFI API is disabled by default by a build-time feature flag.
Impact
If unpatched, an application calling the affected FFI functions will dereference freed memory. The most likely outcome is undefined behavior leading to a process crash (denial of service). Depending on allocator state, the read may also return adjacent heap contents, resulting in limited information disclosure or incorrect connection identifier handling.
Mitigation
Users are requested to upgrade to quiche 0.29.2 which is the earliest version containing the fix for this issue. |
| SummaryA command injection vulnerability (CWE-78) has been found to exist in the `wrangler pages deploy` command. The issue occurs because the `--commit-hash` parameter is passed directly to a shell command without proper validation or sanitization, allowing an attacker with control of `--commit-hash` to execute arbitrary commands on the system running Wrangler.
Root causeThe commitHash variable, derived from user input via the --commit-hash CLI argument, is interpolated directly into a shell command using template literals (e.g., execSync(`git show -s --format=%B ${commitHash}`)). Shell metacharacters are interpreted by the shell, enabling command execution.
ImpactThis vulnerability is generally hard to exploit, as it requires --commit-hash to be attacker controlled. The vulnerability primarily affects CI/CD environments where `wrangler pages deploy` is used in automated pipelines and the
--commit-hash parameter is populated from external, potentially untrusted sources. An attacker could exploit this to:
* Run any shell command.
* Exfiltrate environment variables.
* Compromise the CI runner to install backdoors or modify build artifacts.
Credits Disclosed responsibly by kny4hacker.
Mitigation
* Wrangler v4 users are requested to upgrade to Wrangler v4.59.1 or higher.
* Wrangler v3 users are requested to upgrade to Wrangler v3.114.17 or higher.
* Users on Wrangler v2 (EOL) should upgrade to a supported major version. |
| Summary
An Insecure Direct Object Reference has been found to exist in `createHeaderBasedEmailResolver()` function within the Cloudflare Agents SDK. The issue occurs because the `Message-ID` and `References` headers are parsed to derive the target agentName and agentId without proper validation or origin checks, allowing an external attacker with control of these headers to route inbound mail to arbitrary Durable Object instances and namespaces .
Root cause
The `createHeaderBasedEmailResolver()` function lacks cryptographic verification or origin validation for the headers used in the routing logic, effectively allowing external input to dictate internal object routing.
Impact
Insecure Direct Object Reference (IDOR) in email routing lets an attacker steer inbound mail to arbitrary Agent instances via spoofed Message-ID.
Mitigation:
* PR: https://github.com/cloudflare/agents/blob/main/docs/email.md ] provides the necessary architectural context for coding agents to mitigate the issue by refactoring the resolver to enforce strict identity boundaries.
* Agents-sdk users should upgrade to agents@0.3.7 |
| Summary
A Reflected Cross-Site Scripting (XSS) vulnerability was discovered in the AI Playground's OAuth callback handler. The `error_description` query parameter was directly interpolated into an HTML script tag without proper escaping, allowing attackers to execute arbitrary JavaScript in the context of the victim's session.
Root cause
The OAuth callback handler in `site/ai-playground/src/server.ts` directly interpolated the `authError` value, sourced from the `error_description` query parameter, into an inline `<script>` tag.
Impact
An attacker could craft a malicious link that, when clicked by a victim, would:
* Steal user chat message history - Access all LLM interactions stored in the user's session.
* Access connected MCP Servers - Interact with any MCP servers connected to the victim's session (public or authenticated/private), potentially allowing the attacker to perform actions on the victim's behalf
Mitigation:
* PR: https://github.com/cloudflare/agents/pull/841 https://github.com/cloudflare/agents/pull/841
* Agents-sdk users should upgrade to agents@0.3.10
* Developers using configureOAuthCallback with custom error handling in their own applications should ensure all user-controlled input is escaped before interpolation. |
| 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 . |
| An HTTP request smuggling vulnerability (CWE-444) was found in Pingora'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.
Impact
This vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this 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 ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.
Mitigation:
Pingora users should upgrade to Pingora v0.8.0 or higher
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. |
| 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. |
| 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. |
| OctoRPKI crashes when encountering a repository that returns an invalid ROA (just an encoded NUL (\0) character). |
| The Cloudflare Vite plugin enables a full-featured integration between Vite and the Workers runtime. When utilising the Cloudflare Vite plugin in its default configuration, all files are exposed by the local dev server, including files in the root directory that contain secret information such as .env and .dev.vars. This vulnerability is fixed in 1.6.0. |
| 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. |
| 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. |
| 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. |
