Changelog

Python web frameworks following the Web Server Gateway Interface (WSGI) ↗︎ or Asynchronous Server Gateway Interface (ASGI) ↗︎ specification can now be used in Python Workers.

Based on the web framework you are using, you can use either wsgi or asgi from the workers module.

For WSGI frameworks like Django or Flask:

from workers import wsgi

from django.core.wsgi import get_wsgi_application

app = get_wsgi_application()
Default = wsgi.entrypoint(app)

The wsgi.entrypoint is equivalent to creating a WorkerEntrypoint class and using the wsgi.fetch method. If you want more control over the WorkerEntrypoint class, you can do so:

from workers import wsgi, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return await wsgi.fetch(app, request, self.env)

For ASGI frameworks like FastAPI or Starlette:

from workers import asgi

from fastapi import FastAPI

app = FastAPI()
Default = asgi.entrypoint(app)

For more information about using individual web frameworks, refer to the packages documentation in Python Workers.

Cloudflare Load Balancing now supports pool sets through the API. Pool sets combine geographic matching with location-specific traffic steering. One load balancer can now use different routing behavior for different locations.

Each pool set can match a Cloudflare data center, country, or region. It then supplies the candidate pools and can apply its own steering policy, pool weights, and fallback pool. Cloudflare evaluates pool sets in array order and applies the first matching pool set.

For example, this pool set uses Dynamic Latency steering for traffic from Germany:

{
	"pool_sets": [
		{
			"name": "germany-lowest-latency",
			"match": { "topology": { "countries": ["DE"] } },
			"overrides": {
				"pools": [
					"0930eec54a4c7ae6616985b79f678210",
					"c8b4f5a6d7e84910a2b3c4d5e6f70819"
				],
				"steering_policy": "dynamic_latency"
			}
		}
	]
}

Use pool sets for active-active traffic distribution, location-specific failover, and regional routing policies. For proxied traffic, a pool set can also return a fixed HTTP response instead of selecting a pool.

For configuration details and more examples, refer to Pool sets.

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

This hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

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

Fixed a rare but critical issue where the client could fail to connect or switch organizations due to an invalid registration after switching installed client versions. Additionally, this hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

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

This hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

Durable Objects can have up to ten distinct Dynamic Workers with in-flight requests, increased from four. This limit applies across all concurrent requests to the same Durable Object because they share an input/output (I/O) context. Other Workers can have up to four distinct Dynamic Workers with in-flight requests per request.

Multiple in-flight requests to the same Dynamic Worker count as one toward this limit.

For more information, refer to Dynamic Workers limits.

Cloudflare Access service token Client Secrets created on or after August 26, 2026, use the format cfast_[40 alphanumeric characters][8-character checksum]. The prefix and checksum make these credentials easier for secret scanning tools to identify with fewer false positives.

Existing service token secrets continue to work and do not require rotation. Both formats use the same Client ID and the same CF-Access-Client-Id and CF-Access-Client-Secret authentication headers.

For more information, refer to Service tokens.

Cloudflare Access administrators can now choose a grace period when rotating a service token secret. Both secrets remain valid during the grace period, giving administrators time to update services without interrupting authentication.

The dashboard offers grace periods from one hour to 30 days. Administrators can also revoke the previous secret immediately. The API accepts an RFC 3339 expiration time for custom rotation schedules.

For configuration instructions, refer to Rotate service token secrets.

Cloudflare Access administrators can now temporarily turn off service tokens without deleting them. A disabled token cannot authenticate, but its configuration remains available so administrators can turn it on again later.

Turning off a token also stops any previous secret in an active rotation grace period. Use this control to contain suspected credential exposure or pause an automated service.

For configuration instructions, refer to Turn a service token on or off.

MCP server portals support the stateless MCP 2026-07-28 specification for client and upstream server connections.

The portal's /mcp endpoint automatically accepts stateless MCP 2026-07-28 requests and earlier 2025 Streamable HTTP clients. When the portal connects to an upstream Streamable HTTP server, it checks for MCP 2026-07-28 support and falls back to the 2025 handshake when needed. Client and upstream protocol selection are independent, so clients and servers can upgrade separately without portal configuration changes.

SSE connections continue to use the legacy protocol. For details, refer to MCP server portal transport and protocol compatibility.

When you register a Cloudflare One Virtual Appliance, you can now select your hypervisor and download the appliance directly from the dashboard — no need to look up asset URLs.

• On the Connectors page, select Add an appliance, choose Virtual appliance, then select your hypervisor: VMware ESXi, Proxmox, or libvirt/KVM.
• Download the OVA image (VMware ESXi) or the install script (Proxmox and libvirt/KVM) for the selected hypervisor.
• Use View setup guide to open deployment instructions for your platform.

This complements the existing self-serve registration and license key generation in the dashboard.

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

Console methods now preserve exception details in your Worker's logs. When your Worker logs an exception, the corresponding log entry includes the exception name, message, and stack.

For example, your Worker can catch and log an exception:

try {
	throw new Error("Deliberately created exception");
} catch (error) {
	console.error("caught exception:", error);
}

try {
	throw new Error("Deliberately created exception");
} catch (error) {
	console.error("caught exception:", error);
}

If you use Workers Observability, your log is automatically enriched with structured error information. The following example shows how the enriched log appears in the Cloudflare dashboard:

The exception's stack trace appears directly in the log message.

If you send telemetry to a Tail Worker, the Tail Worker now receives a log entry with an errorInfo array:

{
	"message": ["Request failed:", "RangeError: Value out of range"],
	"errorInfo": [
		null,
		{
			"name": "RangeError",
			"message": "Value out of range",
			"stack": "RangeError: Value out of range\n    at ..."
		}
	],
	"level": "error",
	"timestamp": 1784851200000
}

Each errorInfo item corresponds to the console argument at the same index in message. Arguments that are not exceptions have a null entry.

Cloudflare CASB is an API-based (agentless) tool that continuously scans your SaaS and cloud applications for security misconfigurations and data exposure. You can now use CASB remediation policies to automatically fix a finding or send a webhook the moment CASB detects it, without manual triage.

A policy can perform a first-party remediation action directly against the SaaS integration API. When a policy triggers, Cloudflare revokes the external sharing configuration without human intervention.

Remediation is currently supported for file-sharing findings in Microsoft 365 and Google Workspace. Support for additional finding types and integrations is coming soon. For the full list of supported finding types, refer to Run remediations in the CASB remediation policies documentation.

A policy can send posture finding data to Slack, ServiceNow, or any other webhook destination. Webhook actions are supported for all posture finding types across CASB integrations.

A single policy can perform both actions: remediate a finding and send a webhook.

1. In Cloudflare One ↗︎, go to Cloud & SaaS findings > Policies.
2. Select Create a policy.
3. Under Basic information, enter a Policy name and, optionally, a Description.
4. Under Choose how you want to trigger the policy, select a Vendor, Integration, and Finding type.
5. Under Define what to do with findings that match your trigger, choose Run Remediation, Send webhooks, or both.
6. Under Status, turn on Enable policy.
7. Select Create policy.

• Learn how to create and manage CASB remediation policies in Cloudflare One.
• Configure CASB webhooks as a policy destination.
• Learn how to manage findings in Cloudflare One.

CASB remediation policies are now available in Cloudflare One.

Test scan lets you check how Data Loss Prevention (DLP) evaluates sample content before you apply a profile to production traffic. Paste text, upload a file, or upload a HAR file, then select the profiles you want to test.

Test scan sends content directly to the DLP scanner. Gateway policies are not evaluated, no traffic passes through Gateway, and no Gateway activity logs are created. Results include matched profiles, detection entries, confidence levels, match context, proximity keywords, file metadata, antivirus status, and OCR output.

Test scan is available to all Cloudflare Zero Trust customers. Profile availability depends on your Zero Trust plan.

For more details, refer to the Test scan documentation.

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.

Additional changes and improvements

• 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

• If a user upgrades to version 2026.7.1343.0, downgrades to an earlier version, re-registers, and then upgrades back to 2026.7.1343.0, the client might fail to connect or switch organizations. To resolve this issue, run warp-cli registration delete or warp-cli registration delete-all.

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

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.

Members with only resource-scoped Access roles can now open Access resource list pages in the Cloudflare dashboard and call list endpoints in the API. They no longer need an additional account-scoped read-only role to list resources.

The dashboard and API return only resources included in the member's permission policy scopes. Filtering applies to Access applications, policies, service tokens, and identity providers. This allows administrators to delegate specific Access resources without granting account-wide visibility. Previously, the dashboard blocked these list pages and API list requests returned 403 responses.

For members with the Cloudflare Access App Admin role, policy lists include policies attached directly to the selected application. Reusable policies appear only when the member has the Cloudflare Access Policy Admin role for those policies.

For role definitions and assignment details, refer to Resource-scoped roles and Role scopes.

Cloudflare Advanced Network Firewall Threat Intel Lists are now supported for accounts using Unified Routing mode. This feature requires a Cloudflare Advanced Network Firewall subscription.

Support for additional features - Rate Limiting and Managed Rulesets - is planned.

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

Version 1 of the Workers Vitest integration is published as @cloudflare/vitest-plugin ↗︎. The package was formerly named @cloudflare/vitest-pool-workers.

The Vitest configuration API is unchanged. Existing projects must update the dependency name, package imports, and TypeScript types entries.

To migrate automatically, run:

npx @cloudflare/codemods vitest:pool-workers-to-vitest-plugin

yarn @cloudflare/codemods vitest:pool-workers-to-vitest-plugin

pnpm @cloudflare/codemods vitest:pool-workers-to-vitest-plugin

The codemod updates your dependency, imports, and test TypeScript configuration. For manual migration steps, refer to Migrate to Vitest plugin.

For outbound request mocks in Workers tests, use the @msw/cloudflare ↗︎ integration. Refer to Mock outbound requests.

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.

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.

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.