Cloudflare One Updates & Release Notes

Additional changes and improvements

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

This release introduces multiple features from our previous beta release into stable release, including:

When reauthentication is needed for any reason, the notifications are clearer and reduce the actions needed to get you back to work by redirecting to the browser for authentication instead of the app window when necessary.

When a network is blocking or otherwise not supportive of HTTP/3, the client will learn and adapt by switching the order of fallback for that network by starting with HTTP/2 first and then trying HTTP/3 if needed. This reduces delays in time to connectivity when joining older or heavily filtered networks.

• Fixed a process leak in the Windows GUI that could exhaust system resources during IPC client-creation failures.
• Fixed being unable to switch organizations when the client was stuck in the "Device not in organization" state.
• Fixed an issue where Microsoft Defender would falsely flag the Cloudflare One Client installation as malicious when installing with Intune.
• Made the Windows domain-joined posture check more reliable.
• A DNS search domain parsing failure no longer prevents connection.
• Cloud icon now correctly reflects actual connection status instead of showing disconnected while fully connected.
• Fixed missing certificate error display due to a race condition.
• Fixed empty black window after transitioning from docked dual displays to undocked/internal display.

Known issues

None

For Zero Trust documentation please see: https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/

For Consumer documentation please see: https://developers.cloudflare.com/warp-client/

Original source

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

This release introduces multiple features from our previous beta release into stable release, including:

When reauthentication is needed for any reason, the notifications are clearer and reduce the actions needed to get you back to work by redirecting to the browser for authentication instead of the app window when necessary.

When a network is blocking or otherwise not supportive of HTTP/3, the client will learn and adapt by switching the order of fallback for that network by starting with HTTP/2 first and then trying HTTP/3 if needed. This reduces delays in time to connectivity when joining older or heavily filtered networks.

Additional changes and improvements

• Fixed the client not allowing login to another organization when currently showing "Device not in organization."
• A DNS search domain parsing failure no longer prevents connection.
• Cloud icon now correctly reflects actual connection status instead of showing disconnected while fully connected.
• Fixed missing certificate error display due to a race condition.
• Fixed crash when trying to connect to captive portal on Wi-Fi.
• Fixed empty black window after transitioning from docked dual displays to undocked/internal display.

Known issues

None

For Zero Trust documentation please see: https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/

For Consumer documentation please see: https://developers.cloudflare.com/warp-client/

Original source

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

This release introduces multiple features from our previous beta release into stable release, including:

When reauthentication is needed for any reason, the notifications are clearer and reduce the actions needed to get you back to work by redirecting to the browser for authentication instead of the app window when necessary.

When a network is blocking or otherwise not supportive of HTTP/3, the client will learn and adapt by switching the order of fallback for that network by starting with HTTP/2 first and then trying HTTP/3 if needed. This reduces delays in time to connectivity when joining older or heavily filtered networks.

Additional changes and improvements

• Fixed the client not allowing login to another organization when currently showing "Device not in organization."
• A DNS search domain parsing failure no longer prevents connection.
• Cloud icon now correctly reflects actual connection status instead of showing disconnected while fully connected.
• Fixed missing certificate error display due to a race condition.
• Fixed empty black window after transitioning from docked dual displays to undocked/internal display.
• Fixed hostname routes not working for Cloudflare Mesh when the IP addresses of the hostnames are local addresses.

Known issues

• When in DNS Only mode, the client may send DNS queries for names that are configured for Local Domain Fallback to the encrypted DNS server instead of falling back to the system configuration. Local Domain Fallback works as expected in other client modes.

For Zero Trust documentation please see: https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/

For Consumer documentation please see: https://developers.cloudflare.com/warp-client/

Original source

You can now configure origin application settings directly in the Cloudflare dashboard when adding or editing a published application route for a Cloudflare Tunnel. These settings control how cloudflared connects to your origin server and were previously only available in the Cloudflare One dashboard or via local configuration files.

When editing a published application, expand Additional application settings to configure parameters organized into three categories:

HTTP

Set a custom HTTP Host header or disable chunked encoding.

TLS

Configure origin server name, CA pool, TLS timeout, disable TLS verification, match SNI to host, or enable HTTP/2 to origin.

Connection

Tune connect timeout, keep-alive timeout, keep-alive connections, TCP keep-alive interval, proxy type, or disable Happy Eyeballs.

Go to Tunnels ↗

For the full list of origin parameters, refer to Origin parameters.

Original source

Cloudflare Email Security now supports post-quantum hybrid key exchange with X25519MLKEM768 on the SMTP connections we make to receive and deliver mail. Deploying Email Security in front of a provider that supports post-quantum hybrid key agreement (like Google Workspace) will create a TLS 1.3 connection using post-quantum key agreement.

Inbound MX connections and outbound delivery connections now negotiate the X25519MLKEM768 hybrid key agreement when the peer supports it, protecting SMTP traffic against harvest-now, decrypt-later ↗ attacks.

Support is backwards compatible and enabled automatically for all customers. Senders and receivers that do not yet advertise post-quantum key agreement continue to connect with classical key exchange.

This applies to all Email Security packages:

• Advantage
• Enterprise
• Enterprise + PhishGuard

Original source

You now have two new ways to protect your Workers with Cloudflare Access.

Protect an application across all its domains at once

Until now, if a Worker was reachable on a route, a Custom Domain, and a workers.dev URL, you had to manually add each one to an Access application and keep the list in sync whenever routes or domains changed.

Now, Access attaches the policy to the Worker itself, so every associated domain and preview URL stays protected even when its routes or domains change.

Protect all new and existing Workers by default

Make all Workers private by default, so every existing and newly created Worker requires sign-in before anyone can reach it.

If a specific Worker should remain publicly accessible, add a Worker-level bypass to exempt it.

Whether you protect a single application or all Workers at once, you can choose whether to protect preview deployments only or both previews and production, and control who can sign in by Cloudflare account membership, email address, or email domain.

For more advanced policy options, edit the policy in Zero Trust ↗.

View all of your Worker Access policies

You can view and manage all of your Access policies in the Access tab of the Workers & Pages section in the dashboard.

See who is accessing your Worker

When Access is enabled on your Worker, every authenticated request includes ctx.access. Call ctx.access.getIdentity() to get the user's email, name, and groups — no manual JWT validation required.

export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response("Access did not run", { status: 401 });
}
const identity = await ctx.access.getIdentity();
return Response.json({ aud: ctx.access.aud, email: identity?.email });
},
};

Test Access locally

You can now test Cloudflare Access locally with wrangler dev. Add a dev block to your wrangler.jsonc:

{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "[email protected]" }
}
}
}

Your Worker will receive this identity through ctx.access and ctx.access.getIdentity(), letting you test authenticated and unauthenticated flows without deploying. Remove the dev block to simulate unauthenticated requests.

API and programmatic access

You can also set up these policies through the Workers API instead of the dashboard.

Original source

Supported ecosystems

Cloudflare Gateway can now detect software package downloads and give you policy control over supply chain traffic. When a developer or CI/CD pipeline downloads a package through Gateway, the proxy identifies the registry protocol from the request URL and extracts the package ecosystem, name, version, and namespace. You can then write HTTP policies using pkg.* selectors to allow or block package downloads.

Gateway detects package downloads for the following ecosystems:

Ecosystem Namespace npm Scope (for example, @babel) PyPI -- RubyGems -- Cargo -- Go Module path Maven Group ID NuGet --

Selectors

In the dashboard, select Package Ecosystem to access the package registry selectors. After selecting a single ecosystem, nested fields for package name, version, and namespace become available. Five pkg.* selectors are available for HTTP policies with the Allow and Block actions:

Selector Description pkg.ecosystem The package ecosystem detected from the request URL. pkg.name The package name extracted from the download URL. pkg.version The package version, with support for ecosystem-aware comparison operators. pkg.namespace The package namespace, when the ecosystem supports one. pkg.purl The Package URL (PURL) ↗ derived from the detected coordinates. Available in the API only.

Detection is based on the registry protocol rather than the hostname, so it works the same way whether traffic goes to a public registry, a corporate proxy such as Artifactory or Nexus, or a self-hosted mirror.

Package registry security requires TLS decryption to be turned on.

For more information, refer to Package registry security.

Original source

Cloudflare Gateway now automatically detects Model Context Protocol (MCP) ↗ traffic flowing through your network. MCP is the standard protocol used by AI agents to connect to external tools and data sources. Gateway identifies MCP requests by inspecting protocol-specific headers and payload characteristics.

MCP policy selector

A new Is MCP selector (experimental.is_mcp) is available in HTTP policies. Use this selector to build Gateway rules that allow, block, or isolate MCP traffic.

This selector is currently in beta and may change before general availability.

For example, the following policy blocks MCP traffic that does not arrive through an approved MCP portal:

Selector
Operator
Value
Logic
Action
Is MCP
is
True
And
Block
Traffic Source
is not
MCP portal

AI security report

A new AI security report dashboard under Insights & Logs > Dashboards provides visibility into MCP usage across your organization. The dashboard includes:

• Total MCP request volume, unique users, and unique MCP servers
• A timeseries chart of unique MCP servers observed over time
• A summary of Gateway policies that target MCP traffic

For more information, refer to HTTP policies.

Original source

Gateway HTTP and Network policies now include a Traffic Source selector that identifies how traffic reaches Cloudflare. This allows administrators to write policies that target specific on-ramp methods - for example, applying different rules to traffic arriving via the Cloudflare One Client compared to traffic routed through an MCP portal or a proxy endpoint.

Available traffic source values

UI name
API value
Description

• Device client
  device_client
  Traffic from the Cloudflare One Client (WARP)

• Mesh
  mesh
  Traffic from a Cloudflare Mesh connector

• Cloudflare WAN
  cloudflare_wan
  Traffic from Cloudflare WAN (Magic WAN)

• Clientless RDP
  clientless_rdp
  Traffic from a clientless RDP session

• Proxy endpoint
  proxy_endpoint
  Traffic from a proxy endpoint (PAC file)

• Clientless Browser Isolation
  agentless_biso
  Traffic from clientless Browser Isolation

• MCP portal
  mcp_portal
  Traffic from an MCP portal

The selector uses the net.onramp.type API field in both HTTP and Network policies.

UI name
API example

• Traffic Source
  net.onramp.type == "device_client"

Browser Isolation selector

A Browser Isolation selector is also available in Network and HTTP policies. This selector identifies whether the current session is running inside Remote Browser Isolation, allowing administrators to apply different policy behavior to isolated traffic.

UI name
API example

• Browser Isolation
  net.is_isolated == true

For more information, refer to HTTP policies and Network policies.

Original source

Cloudflare Email security now lets administrators write their own content-based blocking rules.

A new Blocked content area under Policies & rules lets you define a plaintext string or a regular expression, choose whether to scan the message subject, body, or both, and automatically block any message that matches.

Create rules using either plaintext matches or regular expressions — useful for blocking targeted phishing campaigns, known-bad phrases, or content patterns unique to your organization.

Choose the search location for each rule: subject, body, or subject and body.

Use the built-in regular expression checker to validate your pattern against sample text before saving, so you can confirm the rule matches what you expect and avoid false positives.

Matching messages are marked with a malicious disposition and prevented from reaching users' inboxes.

Blocked content rules currently only support the block action.

This feature is available for the following Email security packages:

• Enterprise
• Enterprise + PhishGuard

To get started, refer to Blocked content.

Original source

Infrastructure applications support independent multi-factor authentication (MFA) with FIDO2 keys. You can allow ssh_fido2_key, piv_key, or both in application-level and policy-level MFA settings.

Users enroll FIDO2 keys through the App Launcher and connect with the generated SSH identity. FIDO2 keys for SSH are separate from browser-based WebAuthn security keys and Personal Identity Verification (PIV) keys.

For setup instructions, refer to Enroll a FIDO2 key for infrastructure apps and Configure MFA for infrastructure applications.

Original source

Hostname routing ↗ is now generally available. Instead of managing static IP lists and routes, you can route traffic by hostname across multiple Cloudflare One connectors:

Cloudflare Tunnel: route a private hostname (for example, wiki.internal.local) to a private application behind your tunnel, or a public hostname (for example, bank.example.com) to egress through a specific tunnel and anchor traffic to a dedicated exit node.

Cloudflare Mesh: attract a private or public hostname's traffic to a Mesh node.

Alongside GA, the default IPv4 range used for initial resolved IPs (also called token IPs) is changing from a Carrier-Grade NAT (CGNAT) range to a public Cloudflare-owned range:

IPv4: 172.64.128.0/20

IPv6: 2606:4700:0cf1:4000::/64

This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

Why this is changing: Starting with Chrome 142 ↗, Local Network Access (LNA) restrictions block background requests to CGNAT addresses (100.64.0.0/10), which included the previous initial resolved IP default (100.80.0.0/16). LNA is implemented at the Chromium engine level, so it affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This could silently break hostname-based Gateway features for users of these browsers, and required Chrome Enterprise policy workarounds. The new default range is public Cloudflare address space, so it is not affected by this restriction.

What is affected: Initial resolved IPs are used by several features that associate a DNS query with the network connection that follows it:

• Private and public hostname routing for Cloudflare Tunnel
• Hostname routes for Cloudflare Mesh
• Access private applications on non-HTTPS ports
• Egress policy host selectors (Domain, Host, Application, and Content Categories)

You can check your account's current range, or configure a custom range, at any time from Networking > IP addresses > Address space > Custom IPs, or using the Initial Resolved IP Subnet API.

Go to Custom IPs ↗

For full instructions, refer to Configure initial resolved IPs. The IPv6 range (2606:4700:0cf1:4000::/64) is unchanged and is not affected by this restriction.

The default IPv4 range, and all Cloudflare One IPv6 ranges, are automatically routed through the Cloudflare One Client and do not require any Split Tunnel configuration. Refer to Automatically managed ranges for details.

If you were relying on a Chrome Enterprise policy workaround (such as LocalNetworkAccessRestrictionsTemporaryOptOut) while your account was still on the legacy CGNAT-based range, refer to Google Chrome restricts access to private hostnames for next steps.

Original source

Real-time Tunnel log streaming is now available in the Cloudflare dashboard under Networking > Tunnels. This brings the same live debugging capability previously only available in the Cloudflare One dashboard, including multi-connector aggregated streaming for high-availability deployments.

In the tunnel detail view, a new Live logs tab lets you:

• Stream logs from single or multiple connectors — In highly available deployments with multiple cloudflared replicas, logs from all connectors are merged into a single stream grouped by hostname, making it easy to identify which host machine produced each log entry.
• Filter by log level, event type, and HTTP method — Narrow the stream to only the events you care about (HTTP, TCP, UDP, or cloudflared internal), at any log level.

Go to Tunnels ↗

For more information, refer to Monitor tunnels and Tunnel log streams.

Original source

Cloudflare Mesh nodes can now run as Docker containers. The cloudflare/mesh ↗ image is available on Docker Hub for Docker Compose, Kubernetes, and any OCI-compatible runtime — no host-level package installation required.

The image supports amd64 and arm64 architectures and includes built-in source NAT so return traffic routes correctly without VPC route table changes.

Deployment patterns

• Docker Compose — add a cloudflare-mesh service to your compose.yaml and connect your entire stack to a private network.
• Kubernetes StatefulSet — deploy a standalone Mesh node with persistent registration state.
• Kubernetes sidecar — add the Mesh image as a sidecar container in a Pod to connect an application to Cloudflare without application changes.
• CI/CD — pull the image in a pipeline step, join the Mesh, run integration tests against private infrastructure, and tear down. The node disappears when the container exits.

For high availability, run multiple replicas with the same Mesh node token. Cloudflare operates replicas in active-passive mode with automatic failover.

Go to Mesh ↗

For setup steps, runtime configuration, and deployment examples, refer to Run Mesh in Docker / Kubernetes.

Original source