Skip to content

Changelog

New updates and improvements at Cloudflare.

Workers tracing — write custom spans with new startActiveSpan() and span.end() runtime APIs

The Workers runtime now provides built-in tracing.startActiveSpan() and span.end() APIs, allowing you to write custom spans for operations that last beyond a single callback — for example, instrumenting a stream pipeline where the span should stay open until the stream is fully consumed.

This augments the existing API for writing custom spans, tracing.enterSpan(), which automatically ends a span when its callback is returned. With startActiveSpan(), the span remains open after the callback returns, and you call span.end() when the work is complete:

src/index.jsjs
import { tracing } from "cloudflare:workers";

const encoder = new TextEncoder();

export default {
	fetch() {
		return tracing.startActiveSpan("stream-response", (span) => {
			let timer;

			const body = new ReadableStream({
				start(controller) {
					controller.enqueue(encoder.encode("Starting...\n"));

					timer = setTimeout(() => {
						controller.enqueue(encoder.encode("Complete.\n"));
						controller.close();

						span.setAttribute("stream.status", "complete");
						span.end();
					}, 1000);
				},

				cancel() {
					if (timer !== undefined) clearTimeout(timer);

					span.setAttribute("stream.status", "cancelled");
					span.end();
				},
			});

			return new Response(body, {
				headers: { "content-type": "text/plain" },
			});
		});
	},
};
src/index.tsts
import { tracing } from "cloudflare:workers";

const encoder = new TextEncoder();

export default {
	fetch(): Response {
		return tracing.startActiveSpan("stream-response", (span) => {
			let timer: ReturnType<typeof setTimeout> | undefined;

			const body = new ReadableStream<Uint8Array>({
				start(controller) {
					controller.enqueue(encoder.encode("Starting...\n"));

					timer = setTimeout(() => {
						controller.enqueue(encoder.encode("Complete.\n"));
						controller.close();

						span.setAttribute("stream.status", "complete");
						span.end();
					}, 1000);
				},

				cancel() {
					if (timer !== undefined) clearTimeout(timer);

					span.setAttribute("stream.status", "cancelled");
					span.end();
				},
			});

			return new Response(body, {
				headers: { "content-type": "text/plain" },
			});
		});
	},
};

For more details, refer to the custom spans documentation.

Run integration tests against your Worker's production build

Wrangler now provides createTestHarness(), an API for running integration tests against Workers built with Wrangler or the Cloudflare Vite plugin from any Node.js test runner.

The test harness starts a local Worker server with helpers for dispatching requests, resetting storage, and inspecting runtime logs.

This is useful for tests that need to:

For example, this test starts two Workers and mocks an upstream API:

tests/vitest.test.jsjs
import { afterAll, afterEach, beforeAll, test } from "vitest";
import { http, HttpResponse } from "msw";
import { setupServer } from "msw/node";
import { createTestHarness } from "wrangler";

const network = setupServer();
const server = createTestHarness({
	workers: [
		/** Includes `"routes": ["example.com/*"]` */
		{ configPath: "./workers/web/wrangler.jsonc" },
		/** Includes `"routes": ["api.example.com/v1/*"]` */
		{ configPath: "./workers/api/wrangler.jsonc" },
	],
});

beforeAll(async () => {
	network.listen({ onUnhandledRequest: "error" });
	await server.listen();
});

afterEach(async () => {
	network.resetHandlers();
	await server.reset();
});

afterAll(async () => {
	network.close();
	await server.close();
});

test("routes requests to each Worker", async ({ expect }) => {
	// Mock the outbound fetch used to load user profiles.
	network.use(
		http.get("http://identity.example.com/profile/123", ({ params }) => {
			return HttpResponse.json({ id: 123, name: "Ada" });
		}),
	);

	const apiWorkerResponse = await server.fetch(
		"http://api.example.com/v1/users/123",
	);
	expect(await apiWorkerResponse.json()).toEqual({
		id: 123,
		name: "Ada",
	});

	const webWorkerResponse = await server.fetch("http://example.com/users/123");
	expect(await webWorkerResponse.text()).toBe("Profile: Ada");
});
tests/vitest.test.tsts
import { afterAll, afterEach, beforeAll, test } from "vitest";
import { http, HttpResponse } from "msw";
import { setupServer } from "msw/node";
import { createTestHarness } from "wrangler";

const network = setupServer();
const server = createTestHarness({
	workers: [
		/** Includes `"routes": ["example.com/*"]` */
		{ configPath: "./workers/web/wrangler.jsonc" },
		/** Includes `"routes": ["api.example.com/v1/*"]` */
		{ configPath: "./workers/api/wrangler.jsonc" },
	],
});

beforeAll(async () => {
	network.listen({ onUnhandledRequest: "error" });
	await server.listen();
});

afterEach(async () => {
	network.resetHandlers();
	await server.reset();
});

afterAll(async () => {
	network.close();
	await server.close();
});

test("routes requests to each Worker", async ({ expect }) => {
	// Mock the outbound fetch used to load user profiles.
	network.use(
		http.get("http://identity.example.com/profile/123", ({ params }) => {
			return HttpResponse.json({ id: 123, name: "Ada" });
		}),
	);

	const apiWorkerResponse = await server.fetch(
		"http://api.example.com/v1/users/123",
	);
	expect(await apiWorkerResponse.json()).toEqual({
		id: 123,
		name: "Ada",
	});

	const webWorkerResponse = await server.fetch("http://example.com/users/123");
	expect(await webWorkerResponse.text()).toBe("Profile: Ada");
});

Cloudflare now recommends createTestHarness() for integration tests instead of unstable_startWorker() or unstable_dev(). To start a development server programmatically, use the Vite createServer() ↗︎ API with the Cloudflare Vite plugin.

For more information about createTestHarness(), refer to the Integration test harness guide.

Filter Durable Object logs and traces by instance ID

Workers Logs and OpenTelemetry spans for Durable Object requests include the Durable Object instance ID.

Use $workers.durableObjectId to filter logs for a specific instance. Root and child spans include the same ID in cloudflare.durable_object.id.

Query Builder filtering traces by Durable Object instance ID

Use these fields to isolate a specific instance and correlate its logs and traces.

For more information, refer to Durable Objects metrics and analytics and Workers tracing spans and attributes.

Budget alerts now on by default for Pay-as-you-go accounts

We are turning on budget alerts by default for eligible Pay-as-you-go accounts. If your account does not already have a budget alert, Cloudflare will create one for you with a $10 account-level threshold. Your default alert will enable at the turn of your next billing cycle, so it will not fire based on usage you have already incurred.

We are rolling this out in cohorts over the coming weeks, so eligible accounts may see their default alert appear at different times.

The default alert behaves exactly like an alert you would create yourself. When your cumulative usage-based spend this cycle reaches the threshold, you receive an email notification. The alert is informational only. It does not cap your usage or impact your account in any way.

Usage is processed once per day for the prior day's activity, so budget alerts fire the day after the threshold is reached rather than in real time.

Budget alerts only consider spend on usage-based products. Recurring subscription fees, such as the Workers Paid plan fee or other monthly plan charges, are not included in the threshold calculation.

You can change the threshold, add additional alerts, or remove the default alert entirely from Manage Account > Billing > Billable Usage, or from your Notifications settings. If you already configured your own budget alert, nothing changes.

Enterprise contract accounts are not in scope.

For more information, refer to the Budget alerts documentation.

Platforms can now create Temporary Accounts via the Cloudflare API

Platforms can now create temporary preview accounts through the Cloudflare REST API. This lets your platform deploy a live Worker before the user signs in to Cloudflare.

With the Temporary Accounts API, coding agents, AI app builders, and other platforms can build a similar flow for generated Workers and supported resources.

Your platform can keep users in its onboarding flow while they generate, deploy, and test an application. Users do not need an existing Cloudflare account, and your platform does not need write access to one.

Diagram showing an AI agent deploying, verifying, and redeploying a Worker in a temporary account, then a user authenticating and claiming the account to keep its resources

The API returns a claim URL that lets the user make the temporary account and its resources permanent.

Cloudflare Drop ↗︎ demonstrates this preview-and-claim pattern for static sites. Someone can upload a site, test and share it for one hour, then sign in or create an account only when they want to keep it.

This API expands the flow first introduced with wrangler deploy --temporary. Your backend now controls the provisioning and deployment experience directly:

  1. Show Cloudflare's Terms of Service and Privacy Policy in your product, and require the user to accept them.
  2. Request and solve a proof-of-work challenge.
  3. Create a temporary preview account.
  4. Deploy with the returned temporary account ID and API token.
  5. Show the deployed Worker URL and claim URL to the user.
curl "https://api.cloudflare.com/client/v4/provisioning/previews/challenge" \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{}'

curl "https://api.cloudflare.com/client/v4/provisioning/previews" \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{
    "termsOfService": "https://www.cloudflare.com/terms/",
    "privacyPolicy": "https://www.cloudflare.com/privacypolicy/",
    "acceptTermsOfService": "yes",
    "challengeToken": "<CHALLENGE_TOKEN>",
    "solution": {
      "checkpoints": "<BASE64_CHECKPOINTS>"
    }
  }'

For the complete API flow, proof-of-work requirements, supported products, and limits, refer to Claim deployments (temporary accounts). For the background and design goals behind this flow, refer to Temporary Cloudflare Accounts for AI agents ↗︎.

Send npm package dependency metadata with Worker uploads

Wrangler now collects npm package dependency information from your project's package.json during wrangler deploy and wrangler versions upload, and includes it in the upload metadata sent to the Cloudflare API. This data, each dependency's name, declared version range, and exact installed version, enables dependency analytics and future supply chain security features such as vulnerability alerting.

To opt out, set dependencies_instrumentation.enabled to false in your Wrangler configuration file:

{
	"dependencies_instrumentation": {
		"enabled": false
	}
}
[dependencies_instrumentation]
enabled = false

For more details, refer to Wrangler configuration.

Cloudflare Drop

Cloudflare Drop ↗︎ lets you deploy a static site to Cloudflare without requiring a Cloudflare account to get started.

Cloudflare Drag and Drop upload screen for browsing folders or ZIP files

Upload a folder or zip file of static assets (static HTML, CSS, JavaScript, images, and fonts) and get a temporary live preview that stays live for 1 hour. During that window, you can test the site, share the preview URL, or claim the deployment to keep it.

Cloudflare Drag and Drop temporary live preview screen with claim and copy claim link actions

When you are ready to make the deployment permanent, click Claim to sign in or create a Cloudflare account. You can claim the site into an existing Cloudflare account or create a new account for the deployment.

Cloudflare Drag and Drop claim account screen with a countdown before the claim link expires

After claiming the site, you can:

  • Add a domain: Connect an existing domain or purchase a new one for your site.
  • Enable observability: Monitor your site's performance and usage.
  • Enable Markdown for Agents: Allow AI agents to access your site's content in Markdown.
  • Control access: Make your site private and choose who can view it.
Claimed Cloudflare Drag and Drop site setup screen showing options to add a domain, control access, enable observability, and enable Markdown for agents

Simpler runtime types with @cloudflare/workers-types v5

We have released version 5 of @cloudflare/workers-types ↗︎. This release simplifies the package to expose only the latest runtime types.

We still recommend that you generate types for your Worker using wrangler types, but if you want to use the package directly, you can install it with your package manager of choice:

npm i -D @cloudflare/workers-types@latest

The package now exposes two entrypoints:

  • @cloudflare/workers-types reflects the latest compatibility date, using the latest stable compatibility flags.
  • @cloudflare/workers-types/experimental reflects APIs behind experimental compatibility flags.

The dated entrypoints, such as @cloudflare/workers-types/2022-11-30 and @cloudflare/workers-types/2023-03-01, are removed. With runtime type generation in Wrangler v4, you can generate these with the wrangler types command to create types locked to your Worker's compatibility date.

For more information, refer to TypeScript language support.

Work across multiple accounts with Wrangler auth profiles

Wrangler CLI now supports auth profiles: named logins that you scope to specific Cloudflare accounts and switch between automatically, based on the directory you are working in.

A profile is a named OAuth login bound to a directory. Commands run in that directory, and its subdirectories, use the matching account — so you can move between accounts without re-running wrangler login.

Use profiles to keep a separate login for each client when working at an agency, or to separate staging and production into different accounts. Pair a profile with an account_id in your Wrangler configuration file so a command cannot reach the wrong account.

# Create a profile for each account, choosing which accounts it can reach
wrangler auth create client-a
wrangler auth activate client-a ~/clients/client-a

wrangler auth create client-b
wrangler auth activate client-b ~/clients/client-b

Use the --profile flag to run a single command with a specific profile:

wrangler deploy --profile personal

In CI and other automated environments, CLOUDFLARE_API_TOKEN still takes precedence over all profiles.

For setup, the resolution order, and the full command reference, refer to Authentication profiles.

Track memory usage for Workers and Durable Objects in the dashboard

You can now monitor how much memory your Workers and Durable Objects consume across invocations with the new Memory Usage chart in the Workers Metrics tab, broken down by P50, P90, P99, and P999 percentiles.

Memory usage chart showing P50, P90, P99, and P999 percentiles with deployment markers

Memory usage measures the V8 isolate memory at the time of each invocation, subject to the 128 MB per-isolate limit — a single isolate can handle many concurrent requests and shares memory across them.

Use the Memory Usage chart to:

  • Track memory trends — Spot gradual increases that may indicate a memory leak before they cause Exceeded Memory errors.
  • Correlate with deployments — Deployment markers on the chart help you identify whether a new version introduced a memory regression.
  • Right-size your Worker — Understand your baseline memory footprint and how much headroom you have before hitting the 128 MB limit.

For Durable Objects, memory usage reflects the in-memory state an object holds (class properties, caches, active WebSocket connections), which persists across invocations until the object is hibernated or evicted. This state is not preserved across eviction, hibernation, or a crash, so persist anything important to storage.

To view memory usage, open the Metrics tab for your Worker ↗︎ or Durable Object namespace ↗︎. For Durable Objects, you can filter by DO ID or name to drill down into memory usage for a specific object. You can also query memory usage programmatically via the GraphQL Analytics API using the workersInvocationsAdaptive dataset — the quantiles.memoryUsageBytesP50 through quantiles.memoryUsageBytesP999 fields return percentile values in bytes.

For local memory debugging, you can also profile memory with DevTools to take heap snapshots and identify specific objects causing high memory usage.

Workers fetch requests now support cf.vary

Workers fetch() requests now support the cf.vary request option. Use cf.vary to control how Cloudflare caches origin responses with a Vary header for a single subrequest.

src/index.jsjs
export default {
	async fetch(request) {
		return fetch(request, {
			cf: {
				vary: {
					default: { action: "bypass" },
					headers: {
						accept: {
							action: "normalize",
							media_types: ["text/html", "application/json"],
						},
						"accept-language": {
							action: "normalize",
							languages: ["en", "fr", "de"],
						},
					},
				},
			},
		});
	},
};
src/index.tsts
export default {
	async fetch(request): Promise<Response> {
		return fetch(request, {
			cf: {
				vary: {
					default: { action: "bypass" },
					headers: {
						accept: {
							action: "normalize",
							media_types: ["text/html", "application/json"],
						},
						"accept-language": {
							action: "normalize",
							languages: ["en", "fr", "de"],
						},
					},
				},
			},
		});
	},
} satisfies ExportedHandler;

For more information, refer to cf.vary.

Test Durable Object eviction with new cloudflare:test helpers

The @cloudflare/vitest-pool-workers package now includes evictDurableObject and evictAllDurableObjects test helpers, exported from cloudflare:test.

These helpers let you test how a Durable Object behaves across evictions, simulating the production lifecycle where an idle Durable Object can be evicted from memory.

For more context, refer to Lifecycle of a Durable Object.

import { evictDurableObject, evictAllDurableObjects } from "cloudflare:test";
import { env } from "cloudflare:workers";

const id = env.COUNTER.idFromName("my-counter");
const stub = env.COUNTER.get(id);

// Evict the Durable Object instance pointed to by a specific stub
await evictDurableObject(stub);

// Close WebSockets instead of hibernating them
await evictDurableObject(stub, { webSockets: "close" });

// Evict all currently-running Durable Objects in evictable namespaces
await evictAllDurableObjects();

These helpers are available in @cloudflare/vitest-pool-workers@0.16.20 and later.

Learn more in the Test APIs reference and the Testing Durable Objects guide.

Temporary accounts for AI agent deployments

AI agents can now deploy Workers to Cloudflare without first requiring a user to sign up, open a browser-based OAuth flow, click through the dashboard, or create an API token. When an agent tries to deploy without Cloudflare credentials, Wrangler can tell it to rerun with --temporary, then deploy the Worker to a temporary preview account.

To try this with your agent, update to Wrangler 4.102.0 or later, make sure you are logged out (wrangler logout), and then ask your agent to build something and deploy it to Cloudflare. The agent should follow Wrangler's output and deploy using the --temporary flag.

Diagram showing an AI agent deploying, verifying, and redeploying a Worker to a temporary account, then claiming it after authentication and moving it to a permanent account
wrangler deploy --temporary

The temporary deployment stays live for 60 minutes. During that window, the agent can verify the Worker, redeploy changes, and return both the live Worker URL and claim URL. Opening the claim URL lets you sign in to or create a Cloudflare account and make the temporary account permanent.

Temporary preview accounts currently support a limited set of products, including Workers, Workers Static Assets, Workers KV, D1, Durable Objects, Hyperdrive, Queues, and SSL/TLS certificates. For supported products, limits, and claim behavior, refer to Claim deployments (temporary accounts).

For more context, refer to Temporary Cloudflare Accounts for Agents ↗︎.

Workers tracing now supports custom spans

You can now create custom trace spans in your Workers code using tracing.enterSpan(). Custom spans appear alongside the automatic platform instrumentation (fetch calls, KV reads, D1 queries, and other platform operations) in your traces and OpenTelemetry exports, with correct parent-child nesting.

The API is available via import { tracing } from "cloudflare:workers" or through the handler context as ctx.tracing:

import { tracing } from "cloudflare:workers";

export default {
  async fetch(request, env, ctx) {
    return tracing.enterSpan("handleRequest", async (span) => {
      span.setAttribute("url.path", new URL(request.url).pathname);
      const data = await env.MY_KV.get("key");
      return new Response(data);
    });
  },
};

Spans nest automatically based on the JavaScript async context, and are auto-ended when the callback returns or its returned promise settles. The Span object provides setAttribute(key, value) for attaching metadata and an isTraced property to check whether the current request is being sampled.

Trace waterfall showing custom spans nested alongside automatic KV and fetch instrumentation

Tracing must be enabled in your Wrangler configuration for spans to be recorded.

For full API details and examples, refer to Custom spans.

Track Dynamic Workers usage from the dashboard and GraphQL API

Dynamic Workers usage on the Workers overview page

Customers can now view the number of Dynamic Workers invoked during their billing period from the Workers overview page in the Cloudflare dashboard.

This count reflects the number of Dynamic Workers that Cloudflare would bill for during the selected billing period. Dynamic Workers usage data only goes back to June 1, 2026.

You can also query this count through the GraphQL Analytics API by using workersInvocationsByOwnerAndScriptGroups and selecting distinctDynamicWorkerCount:

query getDynamicWorkersCount(
	$accountTag: string!
	$filter: AccountWorkersInvocationsByOwnerAndScriptGroupsFilter_InputObject
) {
	viewer {
		accounts(filter: { accountTag: $accountTag }) {
			workersInvocationsByOwnerAndScriptGroups(limit: 10000, filter: $filter) {
				uniq {
					distinctDynamicWorkerCount
				}
			}
		}
	}
}

Use variables to set the account and billing-period date range:

{
	"accountTag": "<ACCOUNT_ID>",
	"filter": {
		"date_geq": "2026-06-01",
		"date_leq": "2026-06-30"
	}
}

For more information, refer to Dynamic Workers pricing.

Billable usage and budget alerts now in product sidebars

Pay-as-you-go customers can now view billable usage and create budget alerts directly from the product overview pages for Workers & Pages, D1, R2, Workers KV, Queues, Vectorize, Durable Objects, and Containers. A new sidebar widget shows current-period spend and the billing cycle date range, alongside a button to create a budget alert.

The widget pulls from the same data as the Billable Usage dashboard and aligns to your billing cycle (or the current day on Free plans), so the numbers match your invoice. Enterprise contract accounts are not yet supported.

Billable usage widget in the Durable Objects product sidebar showing current-period spend and a breakdown by service

Selecting Create budget alert opens the budget alert flow inline so you can set a dollar threshold in the same place you are reviewing usage. Budget alerts apply to your total account-level spend across all products, not just the product page you create them from.

For more information, refer to the Usage-based billing documentation.

New Workers bulk secrets API endpoint

You can now create, update, or delete multiple secrets for your Worker in a single request using the bulk secrets endpoint.

  • Include a secret with a value to create or update.
  • Set a secret to null to delete.
  • Secrets not included in the request are left unchanged.

The following example creates API_KEY, updates the already existing DB_PASSWORD, and deletes OLD_SECRET:

{
  "secrets": {
    "API_KEY": { "type": "secret_text", "name": "API_KEY", "text": "my-api-key" },
    "DB_PASSWORD": { "type": "secret_text", "name": "DB_PASSWORD", "text": "my-db-password" },
    "OLD_SECRET": null
  }
}

You can do the same from the command line using wrangler secret bulk:

npx wrangler secret bulk < secrets.json

To delete a key, set its value to null in the JSON file. Deletion is not supported with .env files.

Each request supports up to 100 total operations (creates, updates, and deletes combined).

Store Wrangler's OAuth credentials in your OS keychain

Wrangler can now store the OAuth credentials returned by wrangler login in an AES-256-GCM ↗︎-encrypted file, with the encryption key held in your operating system keychain. The default behavior is unchanged — credentials still live in a plaintext TOML file unless you opt in.

To opt in, run:

npx wrangler login --use-keyring

The choice is persisted across Wrangler invocations. Opt back out with npx wrangler login --no-use-keyring, or override the preference for a single command with the CLOUDFLARE_AUTH_USE_KEYRING environment variable.

wrangler whoami now reports where credentials are stored:

🔐 Credentials are stored in: Encrypted file (~/.config/.wrangler/config/default.enc) with key in macOS Keychain (service=wrangler, account=default)

Per-platform backends:

  • macOS uses the built-in Keychain via /usr/bin/security.
  • Linux uses libsecret ↗︎ via the secret-tool CLI from the libsecret-tools package.
  • Windows uses Credential Manager via @napi-rs/keyring ↗︎, installed on-demand the first time you opt in.

Refer to Storing OAuth credentials in the OS keychain for the full details, including the migration behavior on opt-in/opt-out and the CLOUDFLARE_AUTH_USE_KEYRING environment variable.

Share local dev servers through Cloudflare Tunnel in Wrangler and Vite

You can now share local dev sessions through Cloudflare Tunnel and get a public URL when using either Wrangler or the Cloudflare Vite plugin. This is useful when you need to share a preview, test a webhook, or access your app from another device.

Vite local dev tunnel demo

This lets you either:

To start a tunnel, press t in Wrangler or t + Enter in Vite while your dev server is running. For details on setting up a named tunnel, refer to Share a local dev server.

New Domains tab in the Workers dashboard

In your Worker's dashboard, there is now a dedicated Domains tab where you can purchase a new domain through Cloudflare Registrar and have it automatically connected, add an existing domain, and manage all of your Worker's routing in one place.

The new Domains tab in the Workers dashboard

You can also enable or disable your workers.dev subdomain and Preview URLs, put them behind Cloudflare Access to require sign-in, and jump directly to analytics or domain overview for any connected domain.

To get started, go to Workers & Pages, select a Worker, and open the Domains tab.

Go to Workers & Pages ↗

WAF and framework adapter mitigations for React and Next.js vulnerabilities

Multiple security vulnerabilities were disclosed by the React team and Vercel affecting React Server Components and Next.js. These include denial of service, middleware and proxy bypass, server-side request forgery, cross-site scripting, and cache poisoning issues across a range of severity levels.

We strongly recommend updating your application and its dependencies immediately. Patched versions are available for React (react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack 19.0.6, 19.1.7, and 19.2.6) and Next.js (15.5.16 and 16.2.5).

WAF protections

Cloudflare WAF rules deployed in response to prior React Server Component CVEs (CVE-2025-55184 ↗︎ and CVE-2026-23864 ↗︎) already provide coverage for the newly disclosed denial-of-service vulnerabilities. These rules are enabled by default with a Block action for all customers using the Cloudflare Managed Ruleset, including Free plan customers using the Free Managed Ruleset.

Ruleset Rule description Rule ID Default action
Cloudflare Managed Ruleset React - DoS - CVE-2025-55184 ↗︎ 2694f1610c0b471393b21aef102ec699 Block
Cloudflare Managed Ruleset React - DoS - CVE-2026-23864 ↗︎ aaede80b4d414dc89c443cea61680354 Block

The existing rules detect the underlying attack patterns generically. As a result, they apply to the new CVE-2026-23870 ↗︎ denial-of-service vulnerability in Server Components and the corresponding Next.js advisory GHSA-8h8q-6873-q5fj ↗︎.

Cloudflare is investigating whether WAF rules can be safely and effectively deployed for three of the high-severity advisories: CVE-2026-23870 ↗︎ / GHSA-8h8q-6873-q5fj ↗︎, GHSA-267c-6grr-h53f ↗︎, and GHSA-mg66-mrh9-m8jx ↗︎. If it is possible to create a managed WAF rule that mitigates these CVEs and does not potentially break application behavior, Cloudflare will add additional managed WAF rules. These rules will be announced through the WAF changelog. Because these vulnerabilities were shared with Cloudflare with minimal advance notice, we are still investigating what WAF mitigations are possible.

Several of the disclosed vulnerabilities are not possible to block in WAF. We strongly recommend updating your applications so they are not purely reliant on WAF mitigations.

Customers on Pro, Business, or Enterprise plans should ensure that Managed Rules are enabled.

Next.js adapters

Vinext: Vinext ↗︎ is a Vite plugin that reimplements the Next.js API surface. Vinext's latest release is not vulnerable to any of the disclosed CVEs. Vinext's architecture differs from stock Next.js in ways that sidestep the affected code paths. For example, it does not implement the PPR resume protocol, does not expose Pages Router data-route endpoints, and strips internal headers such as x-nextjs-data at request boundaries. As an extra layer of defense, we added a React 19.2.6 or later requirement when running vinext init (PR #1118 ↗︎, PR #1112 ↗︎) to prevent accidentally running a vulnerable version of React with Vinext.

OpenNext on Cloudflare: OpenNext is an adapter that lets you deploy Next.js apps to the Cloudflare Workers platform. OpenNext itself is not directly vulnerable to the React denial-of-service CVE, but users must update the Next.js version in their application. The OpenNext team has updated the adapter to further harden against these vectors and released a new version of the Cloudflare adapter. Test fixtures and examples have been updated to use patched versions (PR #1255 ↗︎).

Summary of disclosed vulnerabilities

Advisory Severity Issue WAF status
CVE-2026-23870 ↗︎ / GHSA-8h8q-6873-q5fj ↗︎ High Denial of service in Server Components WAF rules in place: 2694f1610c0b471393b21aef102ec699, aaede80b4d414dc89c443cea61680354
Cloudflare is investigating additional managed WAF coverage
GHSA-267c-6grr-h53f ↗︎ High Middleware bypass via segment-prefetch routes Cloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule
GHSA-mg66-mrh9-m8jx ↗︎ High Denial of service via connection exhaustion in Cache Components Cloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule
GHSA-492v-c6pp-mqqv ↗︎ High Middleware bypass via dynamic route parameter injection Not possible to safely enable a managed WAF rule without potentially breaking application behavior
GHSA-c4j6-fc7j-m34r ↗︎ High SSRF via WebSocket upgrades Not possible to safely enable a managed WAF rule without potentially breaking application behavior
GHSA-36qx-fr4f-26g5 ↗︎ High Middleware bypass in Pages Router i18n Custom WAF rule possible; global managed rule could potentially break application behavior
GHSA-ffhc-5mcf-pf4q ↗︎ Moderate XSS via CSP nonces Custom WAF rule possible; global managed rule could potentially break application behavior
GHSA-gx5p-jg67-6x7h ↗︎ Moderate XSS in beforeInteractive scripts Not possible to safely enable a managed WAF rule without potentially breaking application behavior
GHSA-h64f-5h5j-jqjh ↗︎ Moderate Denial of service in Image Optimization API Custom WAF rule possible; global managed rule could potentially break application behavior
GHSA-wfc6-r584-vfw7 ↗︎ Moderate Cache poisoning in RSC responses Custom WAF rule possible; global managed rule could potentially break application behavior
GHSA-vfv6-92ff-j949 ↗︎ Low Cache poisoning via RSC cache-busting collisions Not possible to safely enable a managed WAF rule without potentially breaking application behavior
GHSA-3g8h-86w9-wvmq ↗︎ Low Middleware redirect cache poisoning Custom WAF rule possible; global managed rule could potentially break application behavior

Automatic tracing across Durable Object and Worker subrequests

You can now get a single unified trace across Worker-to-Worker subrequests, with trace context propagating automatically. Previously, automatic tracing produced disconnected traces when a Worker called another Worker through a service binding or Durable Object.

Unified trace showing nested spans across a Durable Object subrequest and a service binding call

This means you can:

  • Follow a request through your entire Worker architecture in one trace view
  • See service binding and Durable Object calls as nested child spans instead of separate traces
  • Debug cross-Worker request flows in the Cloudflare dashboard or in an external observability platform via OpenTelemetry

Tracing must be enabled in your Wrangler configuration for traces to be recorded. Checkout Workers tracing to get started.

Up next, we are working on external trace context propagation using W3C Trace Context standards ↗︎, which will allow traces from your Workers to link with traces from services outside of Cloudflare.

Introducing Billable Usage dashboard and Budget alerts

Pay-as-you-go customers can now monitor usage-based costs and configure spend alerts through two new features: the Billable Usage dashboard and Budget alerts.

Billable Usage dashboard

The Billable Usage dashboard provides daily visibility into usage-based costs across your Cloudflare account. The data comes from the same system that generates your monthly invoice, so the figures match your bill.

The dashboard displays:

  • A bar chart showing daily usage charges for your billing period
  • A sortable table breaking down usage by product, including total usage, billable usage, and cumulative costs
  • Ability to view previous billing periods

Usage data aligns to your billing cycle, not the calendar month. The total usage cost shown at the end of a completed billing period matches the usage overage charges on your corresponding invoice.

To access the dashboard, go to Manage Account > Billing > Billable Usage.

Screenshot of the Billable Usage dashboard in the Cloudflare dashboard

Budget alerts

Budget alerts allow you to set dollar-based thresholds for your account-level usage spend. You receive an email notification when your projected monthly spend reaches your configured threshold, giving you proactive visibility into your bill before month-end.

To configure a budget alert:

  1. Go to Manage Account > Billing > Billable Usage.
  2. Select Set Budget Alert.
  3. Enter a budget threshold amount greater than $0.
  4. Select Create.

Alternatively, configure alerts via Notifications > Add > Budget Alert.

Create Budget Alert modal in the Cloudflare dashboard

You can create multiple budget alerts at different dollar amounts. The notifications system automatically deduplicates alerts if multiple thresholds trigger at the same time. Budget alerts are calculated daily based on your usage trends and fire once per billing cycle when your projected spend first crosses your threshold.

Both features are available to Pay-as-you-go accounts with usage-based products (Workers, R2, Images, etc.). Enterprise contract accounts are not supported.

For more information, refer to the Usage based billing documentation.

WebSocket binary messages now delivered as Blob by default

Binary frames received on a WebSocket are now delivered to the message event as Blob ↗︎ objects by default. This matches the WebSocket specification ↗︎ and standard browser behavior. Previously, binary frames were always delivered as ArrayBuffer ↗︎. The binaryType property on WebSocket controls the delivery type on a per-WebSocket basis.

This change has been active for Workers with compatibility dates on or after 2026-03-17, via the websocket_standard_binary_type compatibility flag. We should have documented this change when it shipped but didn't. We're sorry for the trouble that caused. If your Worker handles binary WebSocket messages and assumes event.data is an ArrayBuffer, the frames will arrive as Blob instead, and a naive instanceof ArrayBuffer check will silently drop every frame.

To opt back into ArrayBuffer delivery, assign binaryType before calling accept(). This works regardless of the compatibility flag:

const resp = await fetch("https://example.com", {
	headers: { Upgrade: "websocket" },
});
const ws = resp.webSocket;

// Opt back into ArrayBuffer delivery for this WebSocket.
ws.binaryType = "arraybuffer";
ws.accept();

ws.addEventListener("message", (event) => {
	if (typeof event.data === "string") {
		// Text frame.
	} else {
		// event.data is an ArrayBuffer because we set binaryType above.
	}
});

If you are not ready to migrate and want to keep ArrayBuffer as the default for all WebSockets in your Worker, add the no_websocket_standard_binary_type flag to your Wrangler configuration file.

This change has no effect on the Durable Object hibernatable WebSocket webSocketMessage handler, which continues to receive binary data as ArrayBuffer.

For more information, refer to WebSockets binary messages.