Skip to content

Changelog

New updates and improvements at Cloudflare.

You can now enable Access on a Worker or all Workers at once

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.

Access setting for protecting a single Worker

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.

Account-wide Access setting that protects all Workers

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

Make a Worker public when all Workers are protected

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.

Access policy configuration for controlling who can sign in

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.

Access tab showing all configured Access policies

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": "admin@example.com" }
    }
  }
}

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.

Detect and control software package downloads with package registry security

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.

Supported ecosystems

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.

Block emails by content with blocked content rules

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.

Independent MFA supports FIDO2 for infrastructure applications

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.

MCP protocol detection and AI Security dashboard

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
Example Gateway policy that blocks MCP traffic not arriving through an 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
AI security report dashboard showing MCP detection data including total MCP requests, users, servers, and Gateway policies for MCP

For more information, refer to HTTP policies.

Traffic Source selector in Gateway policies

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.

Hostname routing is now generally available, with a new public IP range for initial resolved IPs

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:

You can check your account's current range, or configure a custom range, at any time from Zero Trust > Team & Resources > Devices > Device profiles, or using the Initial Resolved IP Subnet API.

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.

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.

Stream live logs from Cloudflare Tunnel in the dashboard

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.

Stream live logs from a tunnel in the Cloudflare dashboard

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.

Container image for Cloudflare Mesh

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.

Identity-aware controls are now available in AI Gateway

AI Gateway now integrates with Cloudflare Access, giving you two new capabilities:

  • Protect your gateway endpoint. Put your AI Gateway behind Access so you can set policies that control who is allowed to call a specific gateway's endpoint.
  • Identity-aware controls. When traffic reaches AI Gateway through an Access-protected custom domain, AI Gateway can use the authenticated user's Access identity in logs, analytics, routing, and spend controls.

With identity-aware controls, you can set spend limits by authenticated user, control which gateways different users can access, filter logs by user, and build policies without passing user IDs from the client application. AI Gateway adds the verified Access user ID to request metadata as cf.user_id.

For setup instructions, refer to Cloudflare Access.

Control authorization cookies for multi-domain Access applications

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.

Cloudflare One Client for Windows (version 2026.7.1210.1)

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.
  • Increased tolerance for configurations with a large number of local domain fallback resolver IPs, so DNS resolution behaves correctly even when more fallback resolvers are configured than recommended.
  • Fixed a networking issue where IPv6 multicast routes were being assigned to the WARP tunnel interface.
  • Fixed fatal errors on UI load on Windows 10.
  • Fixed a crash during Windows notification initialization.
  • Made the Windows domain-joined posture check more reliable.
  • Fixed orphaned credentials left behind on multi-user uninstall.
  • A successful re-authentication will cause the device profile to be re-evaluated.
  • Improved dashboard-managed client updates by running the updater only when needed.

Cloudflare One Client for macOS (version 2026.7.1210.1)

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.
  • Increased tolerance for configurations with a large number of local domain fallback resolver IPs, so DNS resolution behaves correctly even when more fallback resolvers are configured than recommended.
  • Fixed the WARP client stealing window focus (for example, during reauth).
  • Fixed a client crash when connecting to a captive portal over Wi-Fi.
  • Fixed the system tray icon showing "disconnected" while the UI showed "connected".
  • A successful re-authentication will cause the device profile to be re-evaluated.
  • Improved dashboard-managed client updates by running the updater only when needed.

Static OAuth client credentials for MCP server portals

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.

Admins can turn on Code Mode by default for MCP portal users

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.

Control Cloudflare Gateway DNS caching with a maximum TTL setting

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.

Browser-based login for plaintext HTTP private applications

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.

Restart, reboot, or shut down a Cloudflare One Appliance from the dashboard

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.

New header control options for Gateway HTTP policies

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} Device posture check results (JSON string)

You can mix static text and dynamic variables in a single header value. For example, user-@{identity.email} resolves to user-jdoe@example.com.

For more information, refer to Custom headers.

Bulk print PDFs for browser-based RDP

Users in browser-based RDP sessions can now print multiple PDF files as a single print job. Copy the files to your clipboard on the remote machine, then select Print all PDFs in the clipboard panel. The files are combined into one PDF and sent to your local printer.

The clipboard panel showing the Print all PDFs option for multiple selected PDF files.

Bulk print is available in Chromium-based browsers and Firefox. For more information, refer to Print PDFs for browser-based RDP.

Internal DNS is now generally available

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.