Changelog

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.

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

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

Load balancing analytics now filters traffic data by pool name instead of pool ID, aligning the query behavior with the pool names displayed in the filter dropdown.

Previously, the analytics pool filter queried by internal pool ID while displaying pool names in the UI dropdown. This mismatch caused filtering issues when pools shared similar names or when you expected results based on the visible pool name. Because the underlying query used a different identifier than what appeared on screen, the displayed data could be confusing or incorrect.

The pool filter now queries by the same pool name shown in the dropdown. When you select a pool from the filter, the analytics graphs and tables display data for that specific pool as you would expect. This change affects:

• Requests over time, filtering the chart series to the selected pool.
• Pool distribution, showing only the selected pool segment.
• Top endpoints, displaying cards for origins in the selected pool.
• Latency, showing latency data for the selected pool.

The Logs view and health event filtering are unchanged.

To use this, go to Traffic > Load Balancing Analytics for a zone. The same pool filter appears in the analytics view for an individual load balancer under Load Balancing at the account level.

For more information about analytics filters and metrics, refer to Load Balancing Analytics.

R2 now supports a us jurisdiction, which guarantees that bucket data is stored and processed within the United States. Use this jurisdiction when you need explicit US data residency guarantees.

Use the jurisdiction-specific S3 endpoint to create and access buckets in the us jurisdiction:

https://<ACCOUNT_ID>.us.r2.cloudflarestorage.com

To access a bucket in the us jurisdiction from Workers, set jurisdiction in your R2 binding:

{
	"r2_buckets": [
		{
			"binding": "MY_BUCKET",
			"bucket_name": "<YOUR_BUCKET_NAME>",
			"jurisdiction": "us"
		}
	]
}

[[r2_buckets]]
binding = "MY_BUCKET"
bucket_name = "<YOUR_BUCKET_NAME>"
jurisdiction = "us"

Once an R2 bucket is created, its jurisdiction cannot be changed.

For setup instructions and the full list of supported jurisdictions, refer to R2 data location.

This release updates WordPress remote code execution rule metadata in the Cloudflare Managed Ruleset and Cloudflare Free Ruleset to identify CVE-2026-65640.

Key Findings

• CVE-2026-65640: A remote code execution vulnerability affecting WordPress core and plugin components. Remote, unauthenticated attackers can execute arbitrary system commands to gain unauthorized access or establish backdoors on host servers.

Impact

The WordPress changes update rule metadata only; detection behavior and actions remain unchanged.

@cf/qwen/qwen3.8-27b is now available on Workers AI.

Qwen 3.8 27B is a 27-billion-parameter instruction-tuned vision language model from Alibaba's Qwen family. It processes images and text together, with reasoning and function calling for agentic workflows.

Key capabilities:

• Vision: Accept image and text inputs and generate text responses.
• Reasoning: Support thinking mode for complex, step-by-step problem-solving.
• Function calling: Build agents that invoke tools and APIs across multiple conversation turns.
• 262,144 token context window: Retain long conversations and multimodal inputs across extended agent sessions.

Use Qwen 3.8 27B through the Workers AI binding (env.AI.run()) or the REST API at /ai/run. You can also use AI Gateway with these endpoints.

For more information, refer to the Qwen 3.8 27B model page and pricing.

Cloudflare has fixed an issue affecting WebSocket data transfer reporting. HTTP Traffic Analytics and HTTP request logs now correctly count data transferred throughout a WebSocket connection, restoring the correct behavior. During the affected period, reporting captured only the initial 101 Switching Protocols handshake for some WebSocket connections, which could underreport their data transfer.

Customers with WebSocket traffic will see the correct Data Transfer in the dashboard and EdgeResponseBytes in analytics and HTTP request logs. The change reflects restored accounting of existing WebSocket traffic, not an increase in traffic caused by this change. WebSocket connection behavior is unaffected.

The separate WebSocket Analytics Logpush dataset continues to provide per-connection directional byte counts, timestamps, and close details.

For more information about HTTP Traffic Analytics, refer to Zone Analytics.

@cf/deepseek-ai/deepseek-v4-pro-0813 and @cf/deepseek-ai/deepseek-v4-flash-0731 are now available on Workers AI.

DeepSeek V4 Flash and DeepSeek V4 Pro are the first Workers AI models with a full one million (1,048,576) token context window. Use them for long-horizon agentic workflows, large codebases, and multi-step reasoning that exceed the context limits of every other model hosted on the platform.

DeepSeek V4 Flash is the faster, lower-cost sibling. This release supersedes the preview version with substantially enhanced agentic capabilities.

Key capabilities:

• Reasoning: Both models support thinking mode for complex, step-by-step problem-solving.
• Function calling: Build agents that invoke tools and APIs across multiple conversation turns.
• Long context: Both models support a full 1,048,576 token context window.

Both models require the Workers Paid plan or prepaid AI Gateway credits.

Use these models through the Workers AI binding (env.AI.run()), the REST API, the OpenAI-compatible endpoint, or AI Gateway.

For more information, refer to the DeepSeek V4 Pro model page, the DeepSeek V4 Flash model page, and pricing.

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": "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.

Artifacts now supports jurisdictions, allowing you to select the European Union or the United States as the only location where repo data is stored and processed.

Select a jurisdiction when you create a namespace. Every repo in that namespace automatically uses the selected jurisdiction.

curl --request POST \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/artifacts/namespaces" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "namespace": "my-eu-namespace",
    "jurisdiction": "eu"
  }'

Jurisdictions cannot be changed after namespace creation. If you omit the jurisdiction, Artifacts creates an unrestricted namespace.

For supported jurisdictions and usage details, refer to Data localization.

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:

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:

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.

Cloudflare Realtime SFU is a WebRTC selective forwarding unit that runs on Cloudflare's global network. It forwards audio, video, and application data between WebRTC clients without requiring you to manage SFU infrastructure or regions.

DataChannels are WebRTC channels for application messages. A client publishes a named DataChannel to Realtime SFU, and the SFU forwards its messages to every client that subscribes to that channel. Use DataChannels for low-latency payloads such as chat messages, game state, sensor updates, and control events.

Realtime SFU DataChannels now support unordered and partially reliable delivery. DataChannels remain reliable and ordered by default, so existing channels keep their current behavior.

With ordered delivery, a delayed message can block later messages. For game state or sensor updates, recent data may be more useful than recovering an older message. Unordered delivery lets later messages proceed, while partial reliability limits retransmission attempts or delivery time.

Delivery settings answer two questions: whether newer messages can bypass a delayed message, and when the transport should stop retrying delivery.

Choose the policy that matches how long your payload remains useful:

ordered controls ordering independently from retries. maxRetransmits and maxPacketLifeTime are alternative retry budgets, so set at most one for each channel. Omit both for reliable delivery, whether ordered or unordered.

Realtime DataChannels use negotiated IDs, so browsers do not receive delivery settings from the remote peer. Apply the same settings when the publisher creates the local channel, each subscriber pulls the remote channel, and each client calls createDataChannel().

The following example configures unordered delivery with no retransmissions. It begins after you establish a DataChannel transport on both sessions and complete any required SDP exchange. Run the API requests from your backend with APP_ID, APP_TOKEN, PUBLISHER_SESSION_ID, and SUBSCRIBER_SESSION_ID set in your environment.

curl --request POST \
	--url "https://rtc.live.cloudflare.com/v1/apps/$APP_ID/sessions/$PUBLISHER_SESSION_ID/datachannels/new" \
	--header "Authorization: Bearer $APP_TOKEN" \
	--header "Content-Type: application/json" \
	--data @- <<EOF
{
	"dataChannels": [
		{
			"location": "local",
			"dataChannelName": "player-state",
			"ordered": false,
			"maxRetransmits": 0
		}
	]
}
EOF

curl --request POST \
	--url "https://rtc.live.cloudflare.com/v1/apps/$APP_ID/sessions/$SUBSCRIBER_SESSION_ID/datachannels/new" \
	--header "Authorization: Bearer $APP_TOKEN" \
	--header "Content-Type: application/json" \
	--data @- <<EOF
{
	"dataChannels": [
		{
			"location": "remote",
			"sessionId": "$PUBLISHER_SESSION_ID",
			"dataChannelName": "player-state",
			"ordered": false,
			"maxRetransmits": 0
		}
	]
}
EOF

const channel = pc.createDataChannel("player-state", {
	negotiated: true,
	id: channelId,
	ordered: false,
	maxRetransmits: 0,
});

• Realtime SFU overview
• DataChannels
• Connection API

Cloud Connector now supports public Oracle Cloud Infrastructure (OCI) Object Storage buckets. You can route matching requests to OCI without managing a separate origin-routing configuration.

OCI support uses the Amazon S3 Compatibility API. Both path-style and virtual-hosted endpoint formats are supported, including traditional oraclecloud.com and dedicated customer-oci.com path-style endpoints.

Set provider to oci_storage and provide a supported OCI hostname. The following rule uses a virtual-hosted endpoint:

{
	"expression": "http.request.uri.path wildcard \"/assets/*\"",
	"provider": "oci_storage",
	"description": "Route assets to OCI Object Storage",
	"enabled": true,
	"parameters": {
		"host": "<BUCKET_NAME>.vhcompat.objectstorage.<REGION>.oci.customer-oci.com"
	}
}

For endpoint formats and bucket requirements, refer to Supported cloud providers in Cloud Connector.

Certificate Transparency Monitoring is now generally available ↗ across all Cloudflare plans.

Alerts for certificates Cloudflare issues on your behalf (Universal SSL renewals, backup certificates, Advanced Certificate Manager, Total TLS) are now automatically filtered out. Alert emails are also clearer and more actionable, with structured certificate details and a direct link to manage CT Monitoring in the Cloudflare dashboard.

Learn more in the launch blog post ↗ or the CT Monitoring docs.

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.

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.

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.

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:

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.

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.

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

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.

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

Pages now automatically skips a queued build when a newer build for the same project, branch, and deployment target is also queued.

The Cloudflare Status page at www.cloudflarestatus.com ↗ has been rebuilt. It is available at the same address, and every previously documented Status API ↗ endpoint remains supported, so existing bookmarks, integrations, and monitoring continue to work.

The status page now has its own notification system, delivered independently of Cloudflare infrastructure. You can subscribe by email, webhook, Slack, Discord, or Google Chat.

The Maintenance Notification and Incident Alerts in Cloudflare Notifications remain supported, and deliver to the destinations already configured on your account.

Every page on the status page returns Markdown when requested with an Accept: text/markdown header, so agents can read the current status without parsing HTML:

curl -H "Accept: text/markdown" https://www.cloudflarestatus.com/locations

Incidents and maintenance are published as separate feeds, each available in RSS and Atom, so you can subscribe to one without the other:

https://www.cloudflarestatus.com/api/v3/incidents.rss
https://www.cloudflarestatus.com/api/v3/incidents.atom
https://www.cloudflarestatus.com/api/v3/maintenance.rss
https://www.cloudflarestatus.com/api/v3/maintenance.atom

For more information, refer to Cloudflare Status.

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.

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.

This release introduces new protection for a remote code execution vulnerability in vBulletin and improves two existing detections.

Key Findings

• A new detection provides protection against vBulletin CVE-2026-61511.
• Two existing detections have been improved to strengthen coverage.

Impact

Successful exploitation of CVE-2026-61511 may lead to remote code execution on affected vBulletin systems, potentially resulting in unauthorized access, data exposure, service disruption, and broader compromise of the hosting environment. Administrators are strongly encouraged to apply vendor updates and recommended mitigations.

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

This hotfix addresses an uncommon and intermittent case on Windows devices where the device is unable to reconnect after the device is woken from sleep.

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.

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