Summary

A 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 cause

The 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.

Impact

This 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.

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.

Credits

Disclosed responsibly by kny4hacker.

Summary PKCE was implemented in the OAuth implementation in workers-oauth-provider that is part of MCP framework. However, it was found that an attacker could cause the check to be skipped.

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.

Patches Fixed in: https://github.com/cloudflare/workers-oauth-provider/pull/27

We patched up the vulnerabilities in the latest version, v 0.0.5 of the Workers OAuth provider (https://www.npmjs.com/package/@cloudflare/workers-oauth-provider). You'll need to update your MCP servers to use that version to resolve the vulnerability.

Workarounds None

The Cloudflare Image Resizing plugin for WordPress is vulnerable to Remote Code Execution due to missing authentication and insufficient sanitization within its hookrestpredispatch() method in all versions up to, and including, 1.5.6. This makes it possible for unauthenticated attackers to inject arbitrary PHP into the codebase, achieving remote code execution.

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 .

OctoRPKI does not escape a URI with a filename containing "..", this allows a repository to create a file, (ex. rsync://example.org/repo/../../etc/cron.daily/evil.roa), which would then be written to disk outside the base cache folder. This could allow for remote code execution on the host machine OctoRPKI is running on.

Patches

For more information If you have any questions or comments about this advisory email us at security@cloudflare.com

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.

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.

Impact Pingora versions prior to 0.8.0 would immediately forward bytes following a request with an Upgrade header to the backend, without waiting for a 101 Switching Protocols response. This allows an attacker to smuggle requests to the backend and bypass proxy-level security controls.

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, or perform cross-user attacks by hijacking sessions.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were 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.

Patches Pingora users should upgrade to Pingora v0.8.0 or higher, which fixes this issue by only switching connection modes after receiving a 101 Switching Protocols response from the backend (hash 824bdeefc61e121cc8861de1b35e8e8f39026ecd). Without a 101 response, subsequent bytes continue to be parsed as HTTP requests.

Workarounds 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.

References See CVE-2026-2833 and the Cloudflare blog post for more details.

Credits Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program.

Impact Pingora versions prior to 0.8.0 improperly allowed HTTP/1.0 request bodies to be close-delimited and incorrectly handled multiple Transfer-Encoding values. This allows an attacker to desync Pingora's request framing from backend servers and smuggle requests to the backend.

This vulnerability primarily affects standalone Pingora deployments in front of certain backends that accept HTTP/1.0 requests. An attacker could exploit this to bypass proxy-level ACL controls and WAF logic, poison caches and upstream connections, or perform cross-user attacks by hijacking sessions.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were not affected by this vulnerability, as its ingress proxy layers rejected ambiguous framing such as invalid Content-Length values and internally forwarded non-ambiguous message length framing headers.

Patches 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 (commits 7f7166d62fa916b9f11b2eb8f9e3c4999e8b9023, 40c3c1e9a43a86b38adeab8da7a2f6eba68b83ad, and 87e2e2fb37edf9be33e3b1d04726293ae6bf2052).

Workarounds 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.

References See CVE-2026-2835 and the Cloudflare blog post for more details.

Credits Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program.

Impact 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.

Patches 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 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.

Workarounds Unfortunately, Wrangler doesn't provide any configuration for which host that inspector server should listen on. Please upgrade to at least wrangler@3.16.0, and configure Wrangler to listen on local interfaces instead with wrangler dev --ip 127.0.0.1 to prevent SSRF. This removes the local network as an attack vector, but does not prevent an attack from visiting a malicious website.

References - https://github.com/cloudflare/workers-sdk/issues/4430 - https://github.com/cloudflare/workers-sdk/pull/4437 - https://github.com/cloudflare/workers-sdk/pull/4535 - https://github.com/cloudflare/workers-sdk/pull/4550

supporturi parameter in the WARP client local settings file (mdm.xml) lacked proper validation which allowed for privilege escalation and launching an arbitrary executable on the local machine upon clicking on the "Send feedback" option. An attacker with access to the local file system could use a crafted XML config file pointing to a malicious file or set a local path to the executable using Cloudflare Zero Trust Dashboard (for Zero Trust enrolled clients).

The Offload, AI & Optimize with Cloudflare Images plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 1.10.2 via the 'account-id' parameter parameter. This is due to insufficient privilege enforcement on the cfimagesdosetup AJAX handler, which requires only the uploadfiles capability (Author+) rather than manageoptions before writing to wp-config.php, combined with the absence of single-quote escaping — sanitizetextfield() does not strip single quotes, and filterinput(INPUTPOST) bypasses wpmagicquotes() slashing — allowing a single quote in the account-id or api-key parameter to break out of the single-quoted PHP string literal in the writeconfig() define() statement. This makes it possible for authenticated attackers, with author-level access and above, to execute code on the server. This is possible because the 'cf-images-nonce' nonce required by the AJAX handler is exposed to all Author-level and above users on wp-admin/upload.php via the CFImages JavaScript object, meaning any upload-capable user can satisfy the nonce check and reach the vulnerable wp-config.php write path.

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.

Impact

Cloudflare quiche was discovered to be vulnerable to an infinite loop when sending packets containing RETIRECONNECTIONID frames.

QUIC connections possess a set of connection identifiers (IDs); see Section 5.1 of RFC 9000. 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 RETIRECONNECTIONID frames, Section 19.16 of RFC 9000 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.

Patches

quiche 0.24.5 is the earliest version containing the fix for the issue

An unchecked read in NTP server in github.com/cloudflare/cfnts prior to commit 783490b https://github.com/cloudflare/cfnts/commit/783490b913f05e508a492cd7b02e3c4ec2297b71  enabled a remote attacker to trigger a panic by sending an NTSAuthenticator packet with extension length longer than the packet contents.

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.

Impact Pingora versions prior to 0.8.0 generated cache keys using only the URI path, excluding critical factors such as the host header. This allows an attacker to poison the cache and serve cross-origin responses to users.

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, or serve malicious content to legitimate users by poisoning shared cache entries.

Note: Cloudflare customers and Cloudflare's CDN infrastructure were 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.

Patches We strongly suggest users should upgrade to Pingora v.0.8.0 or higher, which removes the default CacheKey implementation.

Workarounds Do not rely on the provided CacheKey default, and at minimum use the host / :authority and the upstream peer TLS scheme as part of building the CacheKey, as well as other factors that may apply to the deployment e.g. HTTP method.

References See CVE-2026-2836 and the Cloudflare blog post for more details.

Credits Disclosed responsibly by Rajat Raghav (@xclow3n) through the Cloudflare Bug Bounty Program.

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.

Impact 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.

Patches The fix was introduced in CIRCL v. 1.3.3

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.

Impact 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.

Patches 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.

References Release - https://github.com/cloudflare/workerd/releases/tag/v1.20230419.0

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'.

Impact 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.

Patches The issue was fixed in miniflare@3.20231030.2.

Workarounds Ensure Miniflare is configured to listen on just local interfaces. This is the default behaviour, but can also be configured with the host: "127.0.0.1" option.

References - https://github.com/cloudflare/workers-sdk/pull/4532

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: Pull request 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

Package dependency update: Pull request 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 at create-cloudflare@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 filter in Next config if they need to allow-list external urls with images assets.

Credits

Disclosed responsibly by security researcher Edward Coristine. Thank you for the report.

References

https://www.cve.org/cverecord?id=CVE-2025-6087

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.

cloudflared versions prior to 2020.8.1 contain a local privilege escalation vulnerability on Windows systems. When run on a Windows system, cloudflared searches for configuration files which could be abused by a malicious entity to execute commands as a privileged user. Version 2020.8.1 fixes this issue.

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.

A vulnerability has been discovered in cloudflared's installer (<= 2023.3.0) for Windows 32-bits devices that allows a local attacker with no administrative permissions to escalate their privileges on the affected device. This vulnerability exists because the MSI installer used by cloudflared relied on a world-writable directory.

An attacker with local access to the device (without Administrator rights) can use symbolic links to trick the MSI installer into deleting files in locations that the attacker would otherwise have no access to. By creating a symlink from the world-writable directory to the target file, the attacker can manipulate the MSI installer's repair functionality to delete the target file during the repair process.

Exploitation of this vulnerability could allow an attacker to delete important system files or replace them with malicious files, potentially leading to the affected device being compromised.

The cloudflared client itself is not affected by this vulnerability, only the installer for 32-bit Windows devices.

An unprivileged (non-admin) user can exploit an Improper Access Control vulnerability in the Cloudflare WARP Client for Windows (<= 2022.12.582.0) to perform privileged operations with SYSTEM context by working with a combination of opportunistic locks (oplock) and symbolic links (which can both be created by an unprivileged user).

After installing the Cloudflare WARP Client (admin privileges required), an MSI-Installer is placed under C:\Windows\Installer. The vulnerability lies in the repair function of this MSI.

ImpactAn unprivileged (non-admin) user can exploit this vulnerability to perform privileged operations with SYSTEM context, including deleting arbitrary files and reading arbitrary file content. This can lead to a variety of attacks, including the manipulation of system files and privilege escalation.

PatchesA new installer with a fix that addresses this vulnerability was released in version 2023.3.381.0. While the WARP Client itself is not vulnerable (only the installer), users are encouraged to upgrade to the latest version and delete any older installers present in their systems.