Cloudflare One Updates & Release Notes

Cloudflare Access administrators can now control whether a self-hosted application preemptively sets authorization cookies across its public hostnames.

Previously, Access automatically used eager redirects for applications with five or fewer hostnames. Applications with more than five hostnames received cookies as users visited each hostname. Administrators can now choose either behavior, regardless of the number of hostnames.

The new Eager redirect cookie setting is turned on by default for new applications. After a user signs in, Access redirects the browser through each hostname and sets a CF_Authorization cookie. This supports applications that need to make requests across hostnames before the user visits each one.

For applications with many hostnames, the redirect chain can cause sign-in loops in some browsers. Turn off the setting to issue the cookie only when a user visits each hostname.

To configure the setting, refer to Authorization cookie.

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

This beta release includes the following changes and improvements:

• Improved connection reliability: the client now swaps protocol order after repeated connectivity-check failures, which helps when HTTP/3 is blocked after the QUIC handshake.
• Fixed issue where a certificate error could be incorrectly displayed right after the connection is established.
• A DNS search domain parsing failure no longer prevents connection.
• Fixed a MASQUE issue where the tunnel could stall while uploading at a high rate.
• Fixed being unable to switch organizations when the client was stuck in the "Device not in organization" state.
• Fixed the Home Screen dropdown popup not anchoring correctly.
• Fixed a crash during dialog dismissal. …

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

This beta release includes the following changes and improvements:

• Improved connection reliability: the client now swaps protocol order after repeated connectivity-check failures, which helps when HTTP/3 is blocked after the QUIC handshake.
• Fixed issue where a certificate error could be incorrectly displayed right after the connection is established.
• A DNS search domain parsing failure no longer prevents connection.
• Fixed a MASQUE issue where the tunnel could stall while uploading at a high rate.
• Fixed being unable to switch organizations when the client was stuck in the "Device not in organization" state.
• Fixed the Home Screen dropdown popup not anchoring correctly.
• Fixed a crash during dialog dismissal. …

MCP server portals can now connect to upstream MCP servers that require a pre-registered OAuth client. This supports OAuth providers that do not offer Dynamic Client Registration or have disabled it. This unlocks portal connections to major SaaS providers such as Slack and GitHub, whose MCP servers do not yet support DCR.

When adding an MCP server, administrators can enter the client ID and client secret from an OAuth application registered with the upstream provider. The configuration also supports custom OAuth endpoints, scopes, and the client_secret_post and client_secret_basic token endpoint authentication methods.

Cloudflare stores the client secret encrypted. Users still authenticate to the upstream server with their own accounts when they connect through a portal.

For setup instructions, refer to Configure manual OAuth credentials.

MCP server portals now support four Code Mode policies: Off, Opt-in, On by default, and Enforced. Admins can choose whether Code Mode is unavailable, optional, enabled by default, or required for every session.

Existing portals retain their current behavior. Portals that previously allowed Code Mode use Opt-in, while portals that did not allow Code Mode use Off. New portals also use Opt-in by default.

Clients turn on Code Mode for an Opt-in portal with ?codemode=search_and_execute. The On by default policy lets clients opt out with ?codemode=off, which avoids nested code execution when a client runs its own Code Mode implementation. The Off and Enforced policies ignore client overrides.

The Cloudflare API exposes these policies through the code_mode field:

{
	"code_mode": "default_on"
}

The supported values are off, opt_in, default_on, and enforced. The previous allow_code_mode boolean is deprecated.

For configuration details and client behavior, refer to Code Mode policies.

You can now set a maximum time-to-live (TTL) for DNS responses returned by Gateway. When an upstream DNS record has a TTL that exceeds the configured maximum, Gateway caps it to your specified value. This ensures that DNS policy changes - such as blocking a newly identified malicious domain - take effect faster across all clients.

The maximum DNS TTL setting in Traffic policies > Traffic settings, showing a numeric input field that accepts values between 60 and 36,000 seconds

The setting is available at two levels:

• Account level - In Traffic Policies > Traffic Settings, under Proxy and inspection. This sets the default cap for all DNS locations.
• Per-location - Each DNS location can inherit the account setting, disable the cap, or override it with a custom value.

Two new fields are also available in DNS logs: upstream_record_ttls (the original TTL from the upstream response) and applied_max_ttl (the cap Gateway applied). These appear in the DNS logs column picker and in Logpush datasets.

For more information, refer to Maximum DNS TTL.

Cloudflare Access now uses the standard browser-based login flow for private applications served over plaintext HTTP on port 80.

Previously, plaintext HTTP private apps fell back to the same session flow used for SSH, RDP, and other non-HTTP protocols: users got an Authentication required pop-up from the Cloudflare One Client, then had to select the notification to open a browser and log in. Now, users hitting an HTTP private app see the Access login page directly in the browser and receive a standard Access application token on success.

This brings the HTTP experience in line with HTTPS apps (with Gateway TLS decryption turned on). No configuration change is required. The Cloudflare One Client is still required to route traffic to the private network, but it no longer manages the Access session for HTTP apps.

Other non-HTTP protocols (SSH, RDP, arbitrary TCP/UDP) continue to use the Cloudflare One Client notification flow.

You can now restart, reboot, or shut down a Cloudflare One Appliance directly from the dashboard or via API.

Restarting a Cloudflare One Appliance from the Operations section of the Edit Appliance page

• Restart — Restart managed services. Purges temporary and (optionally) persistent state.
• Reboot — Power cycle the appliance. Optionally, purge persistent state. Re-applies configuration starting from scratch.
• Shutdown — Power off the appliance. Optionally, purge persistent state. The machine will be offline until manually powered on again.

In the dashboard, go to Networking > Connectors > Appliances, select an appliance, then Edit > Operations to send an operation. Via API, POST to the /accounts/{account_id}/magic/connectors/{connector_id}/interrupts endpoint.

For details, refer to Appliance operations.

Cloudflare Gateway now supports advanced header control on Allow policies. Administrators can add, overwrite, or delete headers on matching requests using static values or dynamic variables.

Header operations

Gateway HTTP policies using the Allow action support three operations in rule_settings:

Operation

API field

Behavior

Add

add_headers

Appends a value to the header. Existing values are preserved.

Overwrite

set_headers

Replaces the header value. Creates the header if it does not exist.

Delete

delete_headers

Removes the header from the request.

Gateway applies operations in order: delete, then overwrite, then add.

Dynamic variables

Header values can include dynamic variables using the @{...} syntax. Gateway resolves variables at request time from identity, device, and network context.

Variable

Description

@{identity.email}

User email from the identity provider

@{identity.name}

User display name from the identity provider

@{identity.id}

Cloudflare identity UUID

@{identity.groups}

Identity provider group memberships

@{identity.SAML}

SAML attributes (if configured)

@{identity.OIDC}

OIDC claims (if configured)

@{source.ip}

Source IP of the connection

@{destination.ip}

Destination IP of the request

@{device.id}

Cloudflare One Client device UUID

@{device.posture} …

Internal DNS is now generally available. Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane you already use for public DNS, Zero Trust, and application services.

Why it matters

• Consolidate DNS operations. Public and private DNS run on one platform, with one API, one audit trail, and one place to set policy.
• Simplify split-horizon DNS. Internal and external resolution are defined as separate views over shared zones, managed from a single control plane — so there is no drift to chase down.
• Extend Zero Trust to DNS. Resolver policies decide which users and devices resolve against which view, enforced by the same Gateway that already governs the rest of your traffic.

Setting up Internal DNS takes three steps: create a zone, create a view, and define a resolver policy.

POST /zones
{
  "account": {
    "id": "<ACCOUNT_ID>"
  },
  "name": "corp.internal",
  "type": "internal"
}

Internal DNS is included with Cloudflare Gateway for Enterprise customers. To get started, refer to the Internal DNS documentation.

Data Loss Prevention (DLP) source code detection now focuses on identifying whole source code file uploads and downloads. Previously, source code detection performed partial scans resulting in a higher rate of false positives. Since only whole source code files are evaluated, code embedded in other content — such as chat messages, documentation, or code samples — is no longer flagged as source code, removing a common source of false positives.

Source code detection requires a minimum of 500 characters to evaluate a file. Files below this threshold are not flagged to reduce noise. This threshold filters out small fragments that lack enough context for reliable classification.

Enable and set confidence levels to tune match sensitivity. A higher confidence level reduces false positives by requiring stronger signals that the content is truly source code. A lower confidence level catches more files at the cost of additional noise.

Source code detection applies to standalone source code files in Gateway HTTP policies. It does not detect source code embedded within other file types or payloads, such as .docx files or chat messages. …

Digital Experience Monitoring (DEX) provides visibility into device, network, and application performance across your Cloudflare SASE deployment.

The Device Monitoring page now analyzes hardware and network data between a Cloudflare One Client device and Cloudflare's edge, so you can diagnose connectivity and performance issues. Previously, this data was only available in raw DEX Device State Event logs, which required you to build your own analytics to interpret it.

Device Monitoring summary with connection status, connection mode, Wi-Fi signal strength, traffic performance, and device health

A summary at the top of the page shows the health of each category at a glance, using Good, Fair, and Poor labels:

• Connection — connection status, Cloudflare One Client mode, and tunnel type over time
• Wi-Fi signal strength — signal measured in dBm over time, with thresholds that flag a weak signal
• Traffic performance — upstream and downstream performance, including network throughput on the active interface
• Device health — hardware metrics such as CPU, memory, and disk …

On October 5, 2026, two changes take effect across the Zero Trust Networks API and Cloudflare Tunnel API: the CIDR-encoded route endpoints are removed, and tunnel list and get responses no longer include the connections field. If you manage private network routes or read tunnel connection details through the API, cloudflared, Terraform, or another integration, review the changes in the following sections and migrate before the removal date.

Route endpoints

The CIDR-encoded route endpoints are deprecated in favor of the standard, route_id-based endpoints that already exist today. Both sets of endpoints route a private network through Cloudflare Tunnel or Cloudflare Mesh (the API still refers to Mesh nodes as warp_connector) — only the request shape changes.

Deprecated endpoints (removed October 5, 2026):

• Create a tunnel route (CIDR Endpoint): POST /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded} …

Cloudflare IPsec now supports the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH ↗︎ IKEv2 extension to protect against downgrade attacks on IPsec tunnels.

IKEv2's original authentication design has each endpoint sign only its own outbound messages, not the full handshake transcript. A quantum-capable on-path attacker ↗︎ can exploit this to bypass post-quantum key exchange by downgrading the connection to classical cryptography. The IKE_SA_INIT_FULL_TRANSCRIPT_AUTH extension addresses this by having both peers sign the entire handshake transcript during the authentication exchange, preventing an attacker from manipulating the negotiation without detection.

Key details:

• Available in beta for Cloudflare WAN and Magic Transit IPsec tunnels.
• Cloudflare sends the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification unconditionally as a responder when the feature flag is enabled.
• Both the initiator (your device) and responder (Cloudflare) must support the extension for downgrade protection to be effective.
• This feature is currently gated by a per-account feature flag. Contact your account team to turn it on.

Refer to Downgrade protection for more details.

Cloudflare Advanced Network Firewall IP lists, IDS, and SIP rules are now supported for accounts using Unified Routing mode. These features require a Cloudflare Advanced Network Firewall subscription.

Support for additional features - Threat Intel Lists, Rate Limiting, and Managed Rulesets - is planned.

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