Changelog

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

This release introduces the new Cloudflare One Client UI for macOS! You can expect a cleaner and more intuitive design as well as easier access to common actions and information. Here are some of the many things we have found our users appreciate:

• Right click context menu to access the most common client actions quickly
• Built-in captive portal login experience

Additional Changes and improvements

• Added a new CLI command: warp-cli mdm refresh. This command executes an immediate refresh of the Mobile Device Management (MDM) configuration file.

Known issues

• Registration may hang at "Checking your organization configuration" due to IPC errors. A system reboot should resolve the error, allowing registration to proceed.
• Split tunnel list configuration is not available in the new UI. Management of split tunnel entries is currently only possible via warp-cli tunnel ip and warp-cli tunnel host. UI support will be added in a future release.

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This release introduces the new Cloudflare One Client UI for Linux! You can expect a cleaner and more intuitive design as well as easier access to common actions and information. Here are some of the many things we have found our users appreciate:

• Right click context menu to access the most common client actions quickly
• Built-in captive portal login experience

Changes and improvements

• Added a new CLI command: warp-cli mdm refresh. This command executes an immediate refresh of the Mobile Device Management (MDM) configuration file.
• Official support for RHEL 9 has been added for Cloudflare Mesh nodes. To install the RHEL 9 package, the Extra Packages for Enterprise Linux (EPEL) repository must be active, as it contains dependencies required for the tray icon and captive portal webview.

Known issues

• Registration may hang at "Checking your organization configuration" due to IPC errors. A system reboot should resolve the error, allowing registration to proceed.
• Split tunnel list configuration is not available in the new UI. Management of split tunnel entries is currently only possible via warp-cli tunnel ip and warp-cli tunnel host. UI support will be added in a future release.

Cloudflare IPsec now supports the standard NAT traversal (NAT-T) flow, where IKE begins on UDP port 500 and switches to UDP port 4500 after NAT is detected.

Previously, devices behind NAT had to be configured to initiate IKE on UDP port 4500 directly. Devices that started on UDP port 500 could not complete the IKE handshake when NAT was in the path. This required custom configuration on devices such as VeloCloud SD-WAN edges, Cisco IOS-XE routers, and Juniper SRX firewalls, and was not possible on every platform.

What changed:

• Devices behind NAT can now initiate IKE on either UDP port 500 or UDP port 4500.
• Devices that start IKE on UDP port 500 and switch to UDP port 4500 after NAT detection now complete the handshake successfully.
• No configuration change is required on Cloudflare. The change is available for all IPsec tunnels on Cloudflare WAN and Magic Transit.

This change does not affect existing tunnels:

• Tunnels using UDP port 500 with no NAT detected continue to operate as before.
• Tunnels configured to start IKE on UDP port 4500 continue to operate as before.
• NAT detection logic is unchanged.

For configuration details, refer to GRE and IPsec tunnels.

Multiple security vulnerabilities were disclosed by the React team and Vercel affecting React Server Components and Next.js. These include denial of service, middleware and proxy bypass, server-side request forgery, cross-site scripting, and cache poisoning issues across a range of severity levels.

We strongly recommend updating your application and its dependencies immediately. Patched versions are available for React (react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack 19.0.6, 19.1.7, and 19.2.6) and Next.js (15.5.16 and 16.2.5).

Cloudflare WAF rules deployed in response to prior React Server Component CVEs (CVE-2025-55184 ↗︎ and CVE-2026-23864 ↗︎) already provide coverage for the newly disclosed denial-of-service vulnerabilities. These rules are enabled by default with a Block action for all customers using the Cloudflare Managed Ruleset, including Free plan customers using the Free Managed Ruleset.

The existing rules detect the underlying attack patterns generically. As a result, they apply to the new CVE-2026-23870 ↗︎ denial-of-service vulnerability in Server Components and the corresponding Next.js advisory GHSA-8h8q-6873-q5fj ↗︎.

Cloudflare is investigating whether WAF rules can be safely and effectively deployed for three of the high-severity advisories: CVE-2026-23870 ↗︎ / GHSA-8h8q-6873-q5fj ↗︎, GHSA-267c-6grr-h53f ↗︎, and GHSA-mg66-mrh9-m8jx ↗︎. If it is possible to create a managed WAF rule that mitigates these CVEs and does not potentially break application behavior, Cloudflare will add additional managed WAF rules. These rules will be announced through the WAF changelog. Because these vulnerabilities were shared with Cloudflare with minimal advance notice, we are still investigating what WAF mitigations are possible.

Several of the disclosed vulnerabilities are not possible to block in WAF. We strongly recommend updating your applications so they are not purely reliant on WAF mitigations.

Customers on Pro, Business, or Enterprise plans should ensure that Managed Rules are enabled.

Vinext: Vinext ↗︎ is a Vite plugin that reimplements the Next.js API surface. Vinext's latest release is not vulnerable to any of the disclosed CVEs. Vinext's architecture differs from stock Next.js in ways that sidestep the affected code paths. For example, it does not implement the PPR resume protocol, does not expose Pages Router data-route endpoints, and strips internal headers such as x-nextjs-data at request boundaries. As an extra layer of defense, we added a React 19.2.6 or later requirement when running vinext init (PR #1118 ↗︎, PR #1112 ↗︎) to prevent accidentally running a vulnerable version of React with Vinext.

OpenNext on Cloudflare: OpenNext is an adapter that lets you deploy Next.js apps to the Cloudflare Workers platform. OpenNext itself is not directly vulnerable to the React denial-of-service CVE, but users must update the Next.js version in their application. The OpenNext team has updated the adapter to further harden against these vectors and released a new version of the Cloudflare adapter. Test fixtures and examples have been updated to use patched versions (PR #1255 ↗︎).

When the Cloudflare One Appliance is acting as the DHCP server for a LAN, you can now configure custom DHCP options on the leases it issues. This unlocks workflows such as PXE / iPXE boot, VoIP phone provisioning, and vendor-specific client configuration.

Each option is defined by option_number, value, and one of four value types: text, integer, hex, or ip. Configurations are validated on the appliance before being applied — invalid configurations are rejected and the underlying error is returned to the API caller, so a bad option will not disrupt the live DHCP service.

For details, refer to DHCP server options.

Breakout and traffic prioritization rules on the Cloudflare One Appliance can now match by source in addition to destination application. You can pin breakout or priority behavior to:

• A source LAN interface — VLANs attached to that LAN are included automatically.
• A source IP address, range, or CIDR block.

This is the natural way to break out a guest VLAN to the local Internet, or to prioritize traffic from a specific subnet, without enumerating destination applications.

For details, refer to Breakout traffic.

You can now create, rotate, and delete Cloudflare One Virtual Appliance instances and their license keys directly via the API and Terraform.

• Create a virtual appliance and receive a license key: POST /accounts/{account_id}/magic/connectors with device.provision_license: true.
• Rotate the license key for an existing virtual appliance: PATCH /accounts/{account_id}/magic/connectors/{connector_id} with provision_license: true. The previous key is immediately and irrevocably revoked.
• Delete a virtual appliance to release the associated licensed device.

The license key is returned in the response only once, at create or rotate time. Copy and store it securely.

For details, refer to Configure a Cloudflare One Virtual Appliance.

You can now interact with your Stream video library using new bindings for Workers! This allows customers to upload content to Stream, provision direct uploads, manage videos, and generate signed URLs from a Worker without making authenticated API calls. We're excited to bring Stream and Workers closer together to empower more programmatic pipelines, tighter integrations, and support generative AI and inference workloads.

Use the Stream binding when you want to:

• Upload videos from URLs or create basic direct upload links for end users
• Generate signed playback tokens without managing signing keys
• Manage video metadata, captions, downloads, and watermarks
• Build video pipelines entirely within Workers

To get started, add the Stream binding to your Wrangler configuration:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "stream": {
    "binding": "STREAM"
  }
}

[stream]
binding = "STREAM"

Generate a video with AI and upload directly to Stream or send a URL of a file you already have:

const aiResponse = await env.AI.run(
	"google/veo-3.1",
	{
		prompt: "A dog walking next to a river",
		duration: "10s",
		aspect_ratio: "16:9",
		resolution: "1080p",
		generate_audio: true,
	},
	{
		gateway: { id: "experiments" },
	},
);

// Veo will return a URL of the generated asset.
const videoUrl = aiResponse.result.video;

// Alternative option: a video of the Austin Office mobile
// const videoUrl = 'https://pub-d9fcbc1abcd244c1821f38b99017347f.r2.dev/aus-mobile.mp4';

// Upload to Stream by providing a URL
const streamVideo = await env.STREAM.upload(videoUrl);

// The streamVideo response will include the video ID, playback and manifest
// URLs, and other information, just like the REST API.

const aiResponse = await env.AI.run(
	'google/veo-3.1',
	{
		prompt: 'A dog walking next to a river',
		duration: '10s',
		aspect_ratio: '16:9',
		resolution: '1080p',
		generate_audio: true,
	},
	{
		gateway: { id: 'experiments' },
	},
);

// Veo will return a URL of the generated asset.
const videoUrl = aiResponse.result.video;

// Alternative option: a video of the Austin Office mobile
// const videoUrl = 'https://pub-d9fcbc1abcd244c1821f38b99017347f.r2.dev/aus-mobile.mp4';

// Upload to Stream by providing a URL
const streamVideo = await env.STREAM.upload(videoUrl);

// The streamVideo response will include the video ID, playback and manifest
// URLs, and other information, just like the REST API.

Generate a signed URL without using a signing key or an API call:

const video_id = "ce800be43a9772f4bb02f35b860fb516";
const token = await env.STREAM.video(video_id).generateToken();

// Use the "token" in an iframe embed code, manifest URL, or thumbnail:
const embedUrl = `https://customer-igynxd2rwhmuoxw8.cloudflarestream.com/${token}/iframe`;

const video_id = 'ce800be43a9772f4bb02f35b860fb516';
const token = await env.STREAM.video(video_id).generateToken();

// Use the "token" in an iframe embed code, manifest URL, or thumbnail:
const embedUrl = `https://customer-igynxd2rwhmuoxw8.cloudflarestream.com/${token}/iframe`;

Get and set video properties easily:

const video_id = "46c8b7f480d410840758c1cb14a72e47";
const result = await env.STREAM.video(video_id).details();

await env.STREAM.video(video_id).update({
	meta: { name: "sample video" },
});

const video_id = '46c8b7f480d410840758c1cb14a72e47';
const result = await env.STREAM.video(video_id).details();

await env.STREAM.video(video_id).update({
  meta: { name: 'sample video' }
});

For setup instructions and the full API reference, refer to Bind to Workers API.

Add a binding for Cloudflare Stream (env.STREAM). On the watch page, use the Stream binding to get info based on the ID, and leverage video.meta.name as the page title.

You can now get a single unified trace across Worker-to-Worker subrequests, with trace context propagating automatically. Previously, automatic tracing produced disconnected traces when a Worker called another Worker through a service binding or Durable Object.

This means you can:

• Follow a request through your entire Worker architecture in one trace view
• See service binding and Durable Object calls as nested child spans instead of separate traces
• Debug cross-Worker request flows in the Cloudflare dashboard or in an external observability platform via OpenTelemetry

Tracing must be enabled in your Wrangler configuration for traces to be recorded. Checkout Workers tracing to get started.

Up next, we are working on external trace context propagation using W3C Trace Context standards ↗︎, which will allow traces from your Workers to link with traces from services outside of Cloudflare.

PhishNet users can now access Cloudy summaries directly within the email investigation experience. When reviewing a message in PhishNet, users will see an AI-generated summary that provides additional context and key details about the email.

These summaries help users quickly understand the nature of a message without needing to manually parse through headers, body content, and detection signals. Cloudy surfaces the most relevant information so users can make faster, more informed decisions about suspicious emails.

These summaries are not trained on customer data. They are generated using the outputs of our existing detection models and analysis systems.

This feature is available for PhishNet with Office 365. Support for Gmail will be available by the end of the quarter.

Cloudflare Mesh nodes now support IPv6 CIDR routes. You can advertise both IPv4 and IPv6 subnets through your Mesh nodes, making IPv6-only or dual-stack private networks reachable from any enrolled device.

To add an IPv6 route, follow the same steps as adding an IPv4 route — enter the IPv6 CIDR (for example, fd00::/64) when configuring the route in the dashboard ↗︎ or via the API.

Cloudflare IPsec now supports post-quantum key agreement with compatible third-party devices. Cisco ↗︎ and Fortinet ↗︎ are the first third-party vendors validated to interoperate with Cloudflare IPsec using ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism).

Post-quantum IPsec uses RFC 9370 ↗︎ and draft-ietf-ipsecme-ikev2-mlkem ↗︎ to negotiate hybrid key agreement during the IKEv2 IKE_INTERMEDIATE phase. This combines classical Diffie-Hellman (Group 20) with ML-KEM-768 or ML-KEM-1024 to protect against harvest-now, decrypt-later ↗︎ attacks.

Key details:

• Compatible with Cisco 8000 Series Secure Routers with IOS XR Release 26.1.1 and Fortinet FortiOS 7.6.6 and later.
• Uses ML-KEM-768 or ML-KEM-1024 as an additional Key Exchange to DH Group 20.
• Follows RFC 9370 and draft-ietf-ipsecme-ikev2-mlkem standards.
• No additional licensing required.

Post-quantum IPsec with third-party devices is now generally available with confirmed interoperability for the platforms listed above. Cloudflare intends to support interoperability with more vendors as they build out support for draft-ietf-ipsecme-ikev2-mlkem. Contact your account team to discuss support for additional vendors.

For supported key exchange methods and the list of validated platforms, refer to GRE and IPsec tunnels.

Cloudflare DLP now includes Data Classification, which lets administrators organize and label sensitive content using labels, templates, and reusable data classes.

With Data Classification, administrators can define labels such as sensitivity schemas and levels, and data tag groups and tags. Administrators can also build from Cloudflare-managed templates and create reusable data classes that combine detection entries, other data classes, sensitivity levels, and data tags.

You can then use those classifications in custom DLP profiles to identify the severity of sensitive content, understand where it exists, and apply that logic consistently across DLP profiles.

For more information, refer to Data Classification.

Cloudflare DLP now includes new predefined detection entries.

The expanded catalog includes detections for specific credential types, webhooks, addresses, tax identifiers, national IDs, financial data, and crypto wallets.

Examples include GitHub PAT, OpenAI API Key, Slack Webhook, Discord Webhook, US Physical Address, and Bitcoin Wallet.

For the full list, refer to Predefined detection entries.

Digital experience tests now support testing applications protected by Cloudflare Access or third-party authentication. All authentication secrets are managed via Cloudflare Secret Store.

Digital experience tests also have enhanced configuration options including:

• New HTTP methods (DELETE, PATCH, POST, PUT)
• Secret Store headers, custom plain text headers, and custom request bodies
• Advanced settings: follow redirects, response bodies, response headers, and allow untrusted certificates

The Gateway Authorization Proxy and hosted PAC files are now generally available for all plan types.

Authorization proxy endpoints add an identity-aware option alongside the existing source IP proxy endpoints, using Cloudflare Access authentication to verify who a user is before applying Gateway filtering — without installing the Cloudflare One Client. Cloudflare-hosted PAC files let you create and distribute PAC files directly from Cloudflare One on Cloudflare's global network.

These features are ideal for environments where deploying a device client is not an option, such as virtual desktops (VDI) or compliance-restricted endpoints.

To get started, refer to the proxy endpoints documentation.

Digital Experience will display a dashboard notification when an Internet outage or traffic anomaly may impact a Cloudflare One Client device based on its geographic location or network connection.

This Internet outage and traffic anomaly data is pulled from Cloudflare Radar ↗︎. All Internet outage and traffic anomaly observations can be viewed in the Radar Outage Center ↗︎.

IT teams can now remotely run speed tests from the Cloudflare One Client to Cloudflare's network edge.

Each speed test includes the following metrics:

• Internet speed: download and upload throughput
• Latency: download, upload, unloaded latency, and jitter
• Network quality score: video streaming, webchat/real-time communication (RTC)

In the Cloudflare dashboard ↗︎, go to Zero Trust > Insights > Digital experience > Diagnostics and select Run diagnostics to use the feature today.

You can now create, view, and manage DLP detection entries outside of profiles.

Detection entries are no longer hidden inside individual profiles. Administrators can manage detection entries directly from the Detection entries section and use them in custom DLP profiles.

For more information, refer to Configure detection entries.

Cloudflare DLP now includes a new predefined profile designed to detect PII records that contain multiple types of personal data: Personally Identifiable Information (PII) Record.

Most predefined and custom DLP profiles match when any enabled detection entry matches. The Personally Identifiable Information (PII) Record profile is different. It only matches when at least three unique detection entries are found in close proximity, which reduces false positives from standalone values that may not represent a real PII record.

Detection entries included in the profile:

• AU Passport Number
• American Express Card Number
• Diners Club Card Number
• US Driver's License Number
• Email Address
• Full Name
• US Mailing Address
• Mastercard Card Number
• US Individual Tax Identification Number (ITIN)
• US Passport Number
• US Phone Number
• Union Pay Card Number
• United States SSN Numeric Detection
• Visa Card Number

For more information, refer to predefined DLP profiles.

Zero Trust Network Session Logs are now generated for all traffic proxied through Cloudflare Gateway, regardless of on-ramp type. This includes traffic from proxy endpoints (PAC files) and Browser Isolation egress — on-ramps that previously did not generate session logs.

Customers who already consume the zero_trust_network_sessions dataset via Logpush or Log Explorer may see increased log volume if they use these on-ramps.

For field definitions, refer to Zero Trust Network Session Logs. For traffic analysis, refer to Network session analytics.

Independent MFA in Cloudflare Access now supports two additional organization-level controls:

• Restrict authenticators by AAGUID — Limit enrollment to a specific set of WebAuthn authenticators using their AAGUID ↗︎. This is useful for organizations that require FIPS-validated security keys or company-issued hardware. AAGUIDs are managed through a new List type.
• AMR matching — Skip the independent MFA prompt when the identity provider has already performed an equivalent MFA. Access reads the amr claim defined in RFC 8176 ↗︎ and matches supported values such as hwk, otp, and fpt to the authenticator types allowed on the application or policy. This prevents users from having to complete MFA twice when their identity provider already enforces it.

To get started, refer to Independent MFA.

Cloudflare Advanced Network Firewall Country rules are now supported for accounts using Unified Routing mode. This feature requires a Cloudflare Advanced Network Firewall subscription.

You can create firewall rules that match traffic based on source or destination country to enforce geographic access policies across your network.

This is the first of the Cloudflare Advanced Network Firewall features to become available in Unified Routing. Support for additional features - IP Lists, ASN Lists, Threat Intel Lists, IDS, Rate Limiting, SIP, and Managed Rulesets - is planned.

For the full list of current beta limitations, refer to Traffic steering beta limitations.

Pay-as-you-go customers can now monitor usage-based costs and configure spend alerts through two new features: the Billable Usage dashboard and Budget alerts.

The Billable Usage dashboard provides daily visibility into usage-based costs across your Cloudflare account. The data comes from the same system that generates your monthly invoice, so the figures match your bill.

The dashboard displays:

• A bar chart showing daily usage charges for your billing period
• A sortable table breaking down usage by product, including total usage, billable usage, and cumulative costs
• Ability to view previous billing periods

Usage data aligns to your billing cycle, not the calendar month. The total usage cost shown at the end of a completed billing period matches the usage overage charges on your corresponding invoice.

To access the dashboard, go to Manage Account > Billing > Billable Usage.

Budget alerts allow you to set dollar-based thresholds for your account-level usage spend. You receive an email notification when your projected monthly spend reaches your configured threshold, giving you proactive visibility into your bill before month-end.

To configure a budget alert:

1. Go to Manage Account > Billing > Billable Usage.
2. Select Set Budget Alert.
3. Enter a budget threshold amount greater than $0.
4. Select Create.

Alternatively, configure alerts via Notifications > Add > Budget Alert.

You can create multiple budget alerts at different dollar amounts. The notifications system automatically deduplicates alerts if multiple thresholds trigger at the same time. Budget alerts are calculated daily based on your usage trends and fire once per billing cycle when your projected spend first crosses your threshold.

Both features are available to Pay-as-you-go accounts with usage-based products (Workers, R2, Images, etc.). Enterprise contract accounts are not supported.

For more information, refer to the Usage based billing documentation.

Binary frames received on a WebSocket are now delivered to the message event as Blob ↗︎ objects by default. This matches the WebSocket specification ↗︎ and standard browser behavior. Previously, binary frames were always delivered as ArrayBuffer ↗︎. The binaryType property on WebSocket controls the delivery type on a per-WebSocket basis.

This change has been active for Workers with compatibility dates on or after 2026-03-17, via the websocket_standard_binary_type compatibility flag. We should have documented this change when it shipped but didn't. We're sorry for the trouble that caused. If your Worker handles binary WebSocket messages and assumes event.data is an ArrayBuffer, the frames will arrive as Blob instead, and a naive instanceof ArrayBuffer check will silently drop every frame.

To opt back into ArrayBuffer delivery, assign binaryType before calling accept(). This works regardless of the compatibility flag:

const resp = await fetch("https://example.com", {
	headers: { Upgrade: "websocket" },
});
const ws = resp.webSocket;

// Opt back into ArrayBuffer delivery for this WebSocket.
ws.binaryType = "arraybuffer";
ws.accept();

ws.addEventListener("message", (event) => {
	if (typeof event.data === "string") {
		// Text frame.
	} else {
		// event.data is an ArrayBuffer because we set binaryType above.
	}
});

If you are not ready to migrate and want to keep ArrayBuffer as the default for all WebSockets in your Worker, add the no_websocket_standard_binary_type flag to your Wrangler configuration file.

This change has no effect on the Durable Object hibernatable WebSocket webSocketMessage handler, which continues to receive binary data as ArrayBuffer.

For more information, refer to WebSockets binary messages.