Skip to content

Changelog

New updates and improvements at Cloudflare.

Connect multiple clients to one Browser Run session

Browser Run sessions now accept multiple concurrent connections. Before, a session accepted only one connection at a time, and other Workers had to wait until that connection closed. Now multiple Workers can connect to the same browser at the same time.

Each puppeteer.connect() call opens its own Chrome DevTools Protocol (CDP) connection. Create a separate browser context for each request to keep its pages, cookies, and storage apart from other clients.

const browser = await puppeteer.connect(env.MYBROWSER, sessionId);
const context = await browser.createBrowserContext();

try {
	const page = await context.newPage();
	await page.goto("https://example.com");
	// ...
} finally {
	await context.close();
	await browser.disconnect(); // keep the shared browser running
}
const browser = await puppeteer.connect(env.MYBROWSER, sessionId);
const context = await browser.createBrowserContext();

try {
	const page = await context.newPage();
	await page.goto("https://example.com");
	// ...
} finally {
	await context.close();
	await browser.disconnect(); // keep the shared browser running
}

Sharing sessions means fewer new browsers to launch, less cold-start time, and fewer concurrent browsers counted against your limits.

Concurrent connections require @cloudflare/puppeteer version 1.1.0 or later.

Refer to Reuse sessions for a full example.

Browser Run adds WebMCP to Kitesurf and moves to document.modelContext

WebMCP now works in Kitesurf sessions as well as Lab sessions. Both backends use the document.modelContext API from the WebMCP Community Group draft ↗︎. Lab sessions no longer expose navigator.modelContextTesting.

To list and run page tools:

  • Chrome DevTools: Use the Application > WebMCP panel in the live view of a Lab session or in the Kitesurf playground ↗︎.
  • AI agents: Start Chrome DevTools MCP with the --category-experimental-webmcp flag to add the list_webmcp_tools and execute_webmcp_tool tools.
  • CDP clients: Use the WebMCP CDP domain.

Call Workflows declared in `exports` through `ctx.exports`

A Worker can now call the Workflows it declares in the exports field of its Wrangler configuration through ctx.exports. You no longer need a workflows binding to call a Workflow from the Worker that defines it.

Each Workflow is keyed by class name, and has the same API as a Workflow binding:

src/index.jsjs
export default {
	async fetch(request, env, ctx) {
		const instance = await ctx.exports.MyWorkflow.create({
			params: { name: "World" },
		});
		return Response.json({ id: instance.id });
	},
};
src/index.tsts
export default {
	async fetch(request, env, ctx): Promise<Response> {
		const instance = await ctx.exports.MyWorkflow.create({
			params: { name: "World" },
		});
		return Response.json({ id: instance.id });
	},
} satisfies ExportedHandler<Env>;

A workflows binding and a workflow export with the same name share their instances. You can move a Workflow from a binding to an export without losing its instances.

wrangler dev, the Cloudflare Vite plugin, and the Workers Vitest integration run Workflows on ctx.exports locally. Local development requires Wrangler 4.142.0, @cloudflare/vite-plugin 1.61.0, or @cloudflare/vitest-plugin 1.3.0 or above.

In Vitest, introspectWorkflow() and introspectWorkflowInstance() still need a Workflow binding. To introspect a Workflow declared in exports, add a test-only binding to it.

For more information, refer to Call a Workflow through ctx.exports.

Subscribe to Browser Run crawl events

Browser Run crawl jobs can publish lifecycle events to Cloudflare Queues. Subscribe to started, updated, and finished events to track progress or trigger downstream processing without polling.

To create an account-level subscription, run the following command:

npx wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished

For payload examples, refer to the Browser Run event schemas.

Suppress recipients for one sending domain

Email Sending suppressions now have a scope:

  • account: The suppression applies to every sending domain and subdomain in your account. This is the default.
  • sending_domain: The suppression applies to one sending domain only. A suppression for mail.myappexample.com does not block mail from myappexample.com.

Most importantly, Email Sending now automatically creates bounce and complaint suppressions at the sending-domain level. This provides greater granularity by preventing an issue with one sending domain from suppressing the recipient across your entire account.

To add a suppression for one sending domain in the dashboard, go to Email Sending > Suppressions and select Sending domain in Scope. Imports can also set a scope for each row or a default scope.

In the API, pass scope when you create the suppression:

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/email/sending/suppressions \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "email": "user@example.net",
    "scope": { "type": "sending_domain", "value": "mail.myappexample.com" }
  }'

The suppressions API returns scope on every suppression. To list the suppressions for one domain, use scope_type=sending_domain&scope_value=mail.myappexample.com. If you omit scope, the API creates an account suppression, so existing integrations continue to work.

Refer to Suppression lists and Manage suppressions for details.

WAF Release - 2026-09-25 - Emergency

This update provides immediate defense against critical vulnerabilities affecting WordPress and JFrog Artifactory, including path traversal, local file inclusion (LFI), cross-site scripting (XSS), and authentication bypass exploits.

Key Findings

  • CVE-2026-87902: A high-severity Path Traversal and Local File Inclusion (LFI) vulnerability affecting WordPress. Unauthenticated attackers can exploit this flaw to read arbitrary files on the host server, potentially exposing sensitive configuration data or system files.

  • CVE-2026-42018 & CVE-2026-82329: Critical authentication bypass vulnerabilities affecting JFrog Artifactory. Successful exploitation allows unauthenticated attackers to bypass security controls and achieve unauthorized access to the Artifactory instance.

Impact

We strongly recommend that administrators apply the latest vendor patches for WordPress and JFrog Artifactory to fully secure origin servers.

Detailed Rule Changes

RulesetRule IDLegacy Rule IDDescriptionPrevious ActionNew ActionComments
Cloudflare Managed RulesetN/AWordpress - Path Traversal, Local File Inclusion - CVE:CVE-2026-87902N/ABlockThis is a new detection.
Cloudflare Managed RulesetN/AWordpress - XSS - CommentN/ABlockThis is a new detection.
Cloudflare Managed RulesetN/AJFrog Artifactory - Authentication Bypass - CVE:CVE-2026-42018N/ABlockThis is a new detection.
Cloudflare Managed RulesetN/AJFrog Artifactory - Authentication Bypass - CVE:CVE-2026-82329N/ABlockThis is a new detection.

Workers tracing — new getActiveSpan(), recordException(), startSpan(), and setAttributes() APIs

Custom spans in Workers now support more of the OpenTelemetry span API, so you can instrument more of your code and record errors directly on your spans.

  • tracing.startSpan(name) creates a span without making it the active span, and returns it. Other spans do not nest under it. Call span.end() when the operation is complete.
  • tracing.getActiveSpan() returns the currently active span. Use it to annotate the current span from helper functions and libraries without passing the span object through your code. Outside any custom span, it returns the invocation's root span.
  • span.recordException(exception) records an exception event on a span. It accepts an Error, a string, or an object with a code, name, or message.
  • span.setAttributes(attributes) sets multiple attributes at once. setAttribute() and setAttributes() now return the span, so you can chain calls.
src/index.jsjs
import { tracing } from "cloudflare:workers";

export default {
	async fetch(request, env) {
		const user = await authenticate(request, env);

		// Annotate the invocation's root span
		tracing.getActiveSpan()?.setAttributes({
			"user.id": user.id,
			"user.plan": user.plan,
		});

		const span = tracing.startSpan("load-profile");
		try {
			return Response.json(await loadProfile(env, user.id));
		} catch (err) {
			span.recordException(err);
			throw err;
		} finally {
			span.end();
		}
	},
};
src/index.tsts
import { tracing } from "cloudflare:workers";

export default {
	async fetch(request: Request, env: Env): Promise<Response> {
		const user = await authenticate(request, env);

		// Annotate the invocation's root span
		tracing.getActiveSpan()?.setAttributes({
			"user.id": user.id,
			"user.plan": user.plan,
		});

		const span = tracing.startSpan("load-profile");
		try {
			return Response.json(await loadProfile(env, user.id));
		} catch (err) {
			span.recordException(err as Error);
			throw err;
		} finally {
			span.end();
		}
	},
};

For more details, refer to the custom spans documentation.

See every release and gradual deployment on Workers Metrics charts

Workers Metrics charts now show every release in the selected time range, including the full progression of gradual deployments. This makes it easier to correlate changes in memory, CPU time, errors, or latency with the code that was serving traffic.

Memory usage chart showing a gradual deployment as a shaded rollout band

A gradual deployment appears as a single rollout across the chart, with shading that increases as more traffic moves to the new version. Hover over a rollout to see the previous and new versions, the rollout duration, and the traffic percentage configured at each step.

Invocations chart showing traffic shifting from the previous version to the new version during a gradual deployment

Use these annotations to:

  • Find when a regression started — See which traffic percentage was configured when errors, latency, CPU time, or wall time changed.
  • Compare rollout stages — Check whether a metric changed as more traffic moved to the new version.
  • Confirm rollbacks — Rollbacks appear as separate release events, so you can check whether metrics recovered after a rollback.

Direct deployments that send 100% of traffic to a single version still appear as individual markers. Nearby direct deployments are grouped to reduce visual clutter. Versions that are only uploaded, or only configured at 0%, do not appear on metrics charts.

To view release annotations, open the Metrics tab for your Worker ↗︎.

RFC 8509 root key trust anchor sentinel support

1.1.1.1 now supports RFC 8509 ↗︎ root key trust anchor sentinels. They let you check whether the responding resolver trusts a DNSSEC root key ahead of a key rollover.

To check for KSK-2024 (key tag 38696), query DNSSEC-signed names in dnstest.dev:

# On a sentinel-aware resolver that trusts KSK-2024:

# Returns NOERROR with an A answer.
dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer

# Returns SERVFAIL without an answer.
dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer

# CD bypasses sentinel processing and returns the original A answer.
dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +cdflag +noall +comments +answer

For background on DNSSEC validation, refer to DNSKEY.

MCP server portals are now generally available

MCP server portals are now generally available to all Cloudflare customers. A portal gives users one endpoint for approved Model Context Protocol (MCP) servers. Cloudflare Access logs tool, prompt, and resource activity.

Since the open beta, MCP server portals have added:

To create a portal and connect an MCP client, refer to MCP server portals.

Declare Workflows in the `exports` configuration

You can now declare the Workflows a Worker defines in the exports field of your Wrangler configuration file. Previously, a Worker could only define a Workflow through a workflows binding, even when the Worker never called the Workflow itself.

Key each entry by the name of the class that extends WorkflowEntrypoint:

{
	"exports": {
		"MyWorkflow": {
			"type": "workflow",
			"name": "my-workflow",
			"limits": {
				"steps": 25000,
			},
			"schedules": ["0 * * * *"],
		},
	},
}
[exports.MyWorkflow]
type = "workflow"
name = "my-workflow"
schedules = [ "0 * * * *" ]

  [exports.MyWorkflow.limits]
  steps = 25_000

A workflow export accepts the same settings as a workflows binding: limits, schedules, and default_retention. When you run wrangler deploy, Wrangler creates or updates the Workflow with these settings.

You can declare a Workflow as both a binding and an export. Both declarations must use the same class, and cannot set the same setting to different values.

A workflows binding to a Workflow in another Worker cannot use the same name as a Workflow export in this Worker. Workflow names are unique per account.

Workflow exports require Wrangler 4.139.0 or above.

For more information, refer to Declare Workflows in exports.

Traffic Destination selector in Gateway policies

Gateway HTTP and Network policies now include a Traffic Destination selector that identifies how traffic exits Cloudflare. This allows administrators to write policies that target specific off-ramp methods - for example, applying different rules to traffic destined for the public Internet compared to traffic routed through Cloudflare Tunnel or Cloudflare WAN.

Available traffic destination values

UI name API value Description
Internet internet Traffic to the public Internet
Cloudflare WAN cloudflare_wan Traffic through a Cloudflare WAN connection
Cloudflare Tunnel cloudflare_tunnel Traffic to a private origin through Cloudflare Tunnel
Cloudflare One Client device_client Traffic to another device running the Cloudflare One Client
Mesh mesh Traffic through a Cloudflare Mesh node

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

UI name API example
Traffic Destination net.offramp.type == "internet"

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

View transformation analytics in Images

You can now view account-level analytics for your Images transformation usage.

Go to Images & Stream > Transformations > Analytics to view sampled estimates of image transformation request traffic, including:

  • Requests by source, split between URL-based transformations and Images binding transformations
  • Top zones, transformation configurations, and origin hosts for URL-based requests
  • Top Worker scripts for Images binding requests

Use these analytics to identify the zones, configurations, origins, and Workers generating the most image transformation requests.

Add Mesh participants with guided onboarding

Cloudflare Mesh now makes it faster to add and manage participants from the dashboard. Select Add participant from Networking > Mesh to deploy a Mesh node or find the information needed to connect a client device.

Adding a Cloudflare Mesh node through the guided dashboard workflow

The updated dashboard includes the following improvements:

  • More Mesh node deployment options — Install a node on Linux, Kubernetes, Docker Compose, or Docker CLI. The dashboard provides requirements, commands, configuration, and links for each method. Refer to Run Mesh in Docker / Kubernetes for container deployment details.
  • Client device installation guidance — Access platform-specific Cloudflare One Client installers, mobile QR codes, and your Cloudflare One organization name. Use the organization name to log in from the client after installation.
  • Unified participant management — View Mesh nodes and enrolled client devices in one table. Search devices, filter participants by type or status, open device details, and load additional results from each participant source. If one source fails, participants from the other source remain available while you retry the request.

You must still install the Cloudflare One Client, log in to your organization, and test the connection.

For complete setup instructions, refer to Get started with Cloudflare Mesh.

Automatically manage inactive Access service tokens

Cloudflare Access administrators can now automatically disable or delete inactive service tokens. Administrators can set an inactivity period from 30 to 365 days and choose what Access does when a token reaches that limit.

To be eligible for cleanup, a token must be older than the configured period, must not have successfully authenticated during that period, and must not be directly referenced by an Access policy rule. Cleanup runs gradually in the background, so eligible tokens may not be disabled or deleted immediately.

For configuration instructions, refer to Manage inactive service tokens.

Private MCP server support for MCP server portals

MCP server portals can now connect to MCP servers available only on your private network. The portal uses Cloudflare Gateway to reach private hostnames and IP addresses without exposing the MCP server to the public Internet.

Connect the server network to Cloudflare with Cloudflare Tunnel, Cloudflare Mesh, or another Cloudflare One connector. Configure a private hostname or CIDR route, then turn on Route traffic through Cloudflare Gateway when you add the server. OAuth authorization server endpoints, such as the authorization and token endpoints, must be accessible on the public Internet. If Cloudflare automatically registers the OAuth client through Dynamic Client Registration (DCR), the registration endpoint must also be accessible on the public Internet.

For setup instructions, refer to Connect a private MCP server.

concat() now supports up to 32 arguments

The concat() function in Cloudflare Rules now accepts up to 32 arguments, increased from 16. This allows you to build richer dynamic values directly in Rules expressions and simplify configurations that combine request data.

A common use case is adding a request header that sends context to your origin. The following Rulesets API request adds a Request Header Transform Rule to an existing http_request_late_transform phase ruleset. Its 18-argument expression combines request and network information into one header value:

curl --request POST \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets/$RULESET_ID/rules" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "ref": "add_request_context_header",
    "description": "Add request context for the origin",
    "expression": "true",
    "action": "rewrite",
    "action_parameters": {
      "headers": {
        "X-Request-Context": {
          "operation": "set",
          "expression": "concat(\"ip=\", to_string(ip.src), \";country=\", ip.src.country, \";host=\", http.host, \";method=\", http.request.method, \";path=\", http.request.uri.path, \";query=\", http.request.uri.query, \";ray-id=\", cf.ray_id, \";asn=\", to_string(ip.src.asnum), \";user-agent=\", http.user_agent)"
        }
      }
    }
  }'

For more information, refer to the concat() function reference and HTTP request header modification.

WAF Release - 2026-09-22

This release introduces new threat detections to enhance protection against Server-Side Request Forgery (SSRF) attempts using non-standard IP notations or jar loopback payloads, alongside new defenses against Server-Side Template Injection (SSTI) targeting Jinja environments.

RulesetRule IDLegacy Rule IDDescriptionPrevious ActionNew ActionComments
Cloudflare Managed RulesetN/ASSRF - Cloud,Link-Local non-standard IP notationLogBlockThis is a new detection.
Cloudflare Managed RulesetN/ASSRF - Block jar HTTP loopback payloadLogBlockThis is a new detection.
Cloudflare Managed RulesetN/ASSRF - Local non-standard IP notationLogBlockThis is a new detection.
Cloudflare Managed RulesetN/ASSTI - Jinja Dangerous Globals ChainLogBlockThis is a new detection.

WAF Release - Scheduled changes for 2026-09-29

Announcement DateRelease DateRelease BehaviorLegacy Rule IDRule IDDescriptionComments
2026-09-222026-09-29LogN/ABroken Access Control - Directory Traversal

This is a new detection.

2026-09-222026-09-29LogN/AHTTP Request Smuggling - Request Body Anomaly - Beta

This rule will be merged into the original rule "HTTP/2 Request Smuggling - Request Body Anomaly" (ID: ).

2026-09-222026-09-29DisabledN/ACommand Injection - Generic 8 - body - Beta

This rule will be merged into the original rule "Command Injection - Generic 8 - body" (ID: ).

2026-09-222026-09-29LogN/ACommand Injection - Generic 8 - uri - Beta

This rule will be merged into the original rule "Command Injection - Generic 8 - uri" (ID: ).

2026-09-222026-09-29LogN/AGitLab - Path Traversal- CVE:CVE-2026-85706

This is a new detection.

Workers Builds now supports Cursor Origin

Workers Builds now supports repositories hosted in Cursor Origin. Connect a Cursor Origin repository to automatically build and deploy production changes, preview non-production branches, and see build status in pull requests.

Pushes to your production branch automatically build and deploy your Worker. When you enable non-production branch builds, each branch receives a version-specific preview URL and a stable preview URL that follows the latest build.

Cloudflare posts build status and preview links to the Cursor Origin pull request and creates a check run for each triggered build.

To get started, install the Cloudflare app in Cursor ↗︎, choose the Cursor Origin repositories Cloudflare can access, and follow the prompts to configure your Worker build. For details, refer to the Cursor Origin integration.

Test every pull request in an isolated environment with Worker Previews

You can now test every change you make in an isolated, production-like environment with Worker Previews ↗︎. Each Preview runs under the same Worker with its own code, configuration, URL, and observability, isolated from production and every other Preview.

Configure each Preview

Define the variables, bindings, and settings that new Previews start with in the previews block of your Wrangler configuration file. Set secrets with Wrangler commands. You can override one Preview without changing production or other Previews.

For Durable Objects and Containers, Cloudflare automatically provisions separate namespaces, storage, apps, and instances for every Preview. State changes, sessions, memory, migrations, and concurrent tests remain scoped to that Preview. To isolate KV, D1, R2, or another account-level resource, bind the Preview to a separate resource.

Diagram comparing production with three Previews, each with its own URL, code, configuration, and Durable Object state

Deploy and share every change

Use Wrangler 4.135.0 or later to deploy a Preview:

npx wrangler preview

Or connect your repository to Workers Builds to create Previews automatically and post their URLs to pull requests.

Each Preview gets a stable URL that updates with every push, so reviewers always see the latest changes. Each deployment also gets an immutable URL, so you can compare or return to an exact version.

After you create a Preview, use the environment breadcrumb next to your Worker's name to switch between Production and every Preview:

Worker dashboard showing the Preview dropdown and an overview of bindings, metrics, and deployments

Inspect and revise before production

Each Preview has its own logs, errors, metrics, and traces. Send traffic to its URL, inspect what happened, push a fix, and verify the next deployment before production.

Preview Observability tab showing success and error events for a pull request

Use production-like hostnames

Serve Preview URLs on workers.dev, a custom domain, or both. Custom domains let authentication providers, cookies, cross-origin resource sharing (CORS), and OAuth redirects work as they will in production. You can also protect Preview URLs with Cloudflare Access.

Configure a domain for Preview traffic from the Worker's Domains tab:

Domains tab showing a custom domain configured for Preview traffic

For setup instructions and current limitations, refer to the Worker Previews documentation.

Cloudflare One Client for macOS (version 2026.8.1755.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:

  • Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
  • Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
  • Improved client reaction to the current network lowering its MTU.
  • Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
  • Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
  • Improved API reliability by retrying requests dropped when reusing pooled connections.
  • Fixed Extra Logging failing to capture packets across all interfaces.
  • Fixed an issue that could prevent remote diagnostics from completing.
  • Fixed DNS connectivity checks failing on IPv6-only networks.
  • Fixed the client service exiting when its route-monitoring socket was closed after sleep or wake.
  • Fixed DNS enforcement checks making the client service unresponsive on systems with large routing tables.
  • Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
  • Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
  • Fixed the client continuing to report 'No network' after a successful manual disconnect.
  • Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
  • Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

  • None

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