Cloudflare Release Notes

Minor Changes

#14470 3de70df Thanks @DiogoSantoss! - Add a top-level addresses field to Wrangler configuration for Email Routing

You can now declare the inbound email addresses handled by your Worker directly in wrangler.json:

{
"name": "my-worker",
"main": "src/index.ts",
"compatibility_date": "2026-05-21",
"addresses": ["[email protected]", "*@example.com"]
}

#14706 cb6c3f9 Thanks @edmundhung! - Add Durable Object storage access to createTestHarness()

You can now execute SQL against a SQLite-backed Durable Object to seed or assert the storage state.

const server = createTestHarness({
workers: [{ configPath: "./wrangler.json" }],
});
await server.listen();
const worker = server.getWorker();
const storage = await worker.getDurableObjectStorage("COUNTER", {
name: "user-123",
});
await worker.fetch("/counter/user-123");
const rows = await storage.exec(
"SELECT value FROM counters WHERE id = ?",
"user-123"
);
expect(rows).toEqual([{ value: 1 }]);

#14562 9f04a7e Thanks @martijnwalraven! - Emit a typed runtimeError event on the unstable_startWorker DevEnv for uncaught Worker exceptions

Uncaught Worker exceptions were only source-mapped and printed, so programmatic consumers had to scrape terminal output to observe them. The DevEnv now re-emits a RuntimeErrorEvent (like reloadComplete) carrying the exception text and source-mapped stack — fed from Miniflare's pretty-error seam via the new handleUncaughtError option for exceptions the runtime catches, and from the inspector for those it does not.

Patch Changes

#14682 d39ae01 Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

The following dependency versions have been updated:

Dependency
From
To
@cloudflare/workers-types
^5.20260710.1
^5.20260714.1
workerd
1.20260710.1
1.20260714.1

#14725 c79504f Thanks @edmundhung! - Support containers in createTestHarness()

Workers configured with containers can now be tested using createTestHarness(). The harness builds configured images and makes container-backed Durable Objects available during integration tests.

#14696 c7dbe1a Thanks @martijnwalraven! - Type unstable_startWorker, DevEnv.startWorker, and ConfigController.set/patch against WranglerStartDevWorkerInput, so the wrangler-specific dev.structuredLogsHandler field the runtime already honors is expressible through the public API. Previously the public signatures took the base StartDevWorkerInput, and callers passing the handler needed a cast while internal callers (the test harness) routed the wider type around the signature.

#14494 4e1a7a7 Thanks @petebacondarwin! - Register a workers.dev subdomain before uploading a new Worker

Deploying a Worker for the first time on an account that has no workers.dev subdomain failed with an opaque API error raised by the upload request itself (code 10063, "You need a workers.dev subdomain in order to proceed"). Wrangler now checks for a workers.dev subdomain before uploading a brand-new Worker that publishes to workers.dev and prompts you to register one, so you get a clear, actionable message instead of a cryptic API failure. The check is skipped for deploys that don't target workers.dev (routes-only deploys, or workers_dev: false) and for existing Workers, since their account already has a subdomain.

Updated dependencies [34e696d, d39ae01, 9f04a7e, 9f04a7e, cb30df3, cb6c3f9, 3f3afbb, e6fbc4e]:

[email protected]

Original source

Minor Changes

• #14562 9f04a7e Thanks @martijnwalraven! - Add a handleUncaughtError shared option that receives uncaught Worker exceptions

The runtime catches handler exceptions to build the 500 response, so they never reach the inspector — the one place an uncaught exception exists as a structured value in Node is the pretty-error path, where the error report from the Worker is revived into a source-mapped Error. Embedders can now pass handleUncaughtError: (error: Error) => void to observe that revived error programmatically; logging behavior is unchanged.

The hook fires only where the pretty-error path does: requests reaching the Worker through the entry socket (a browser or another HTTP client against the dev server). dispatchFetch() is unaffected — it always sets MF-Disable-Pretty-Error, and the entry worker then propagates the exception by rejecting the returned promise instead, so dispatchFetch() callers already receive the error directly and the hook is not invoked.

• #14706 cb6c3f9 Thanks @edmundhung! - Add Durable Object storage access to createTestHarness()

You can now execute SQL against a SQLite-backed Durable Object to seed or assert the storage state.

const server = createTestHarness({
workers: [{ configPath: "./wrangler.json" }],
});
await server.listen();
const worker = server.getWorker();
const storage = await worker.getDurableObjectStorage("COUNTER", {
name: "user-123",
});
await worker.fetch("/counter/user-123");
const rows = await storage.exec(
"SELECT value FROM counters WHERE id = ?",
"user-123"
);
expect(rows).toEqual([{ value: 1 }]);

Patch Changes

• #14417 34e696d Thanks @matthewdavidrodgers! - Improve asset serving performance by removing an unnecessary internal dispatch hop

Asset requests and RPC calls now avoid an extra internal forwarding layer, reducing latency. The forwarding infrastructure is preserved for future use by cohort-based deployments.

• #14682 d39ae01 Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

The following dependency versions have been updated:

Dependency From To @cloudflare/workers-types ^5.20260710.1 ^5.20260714.1 workerd 1.20260710.1 1.20260714.1

• #14562 9f04a7e Thanks @martijnwalraven! - Keep reporting uncaught Worker errors when a stack frame's file URL has no local path

fileURLToPath throws on file:// URLs that cannot be represented as a local path (a non-local host; on Windows, any drive-less path — which is every file:///... URL reported by a POSIX-built bundle). Both the source-mapping machinery and youch's error-page frame parsing convert stack-frame specifiers this way, so one such frame previously failed the whole pretty-error request: the error page was replaced by a raw Node stack, the error was not logged, and handleUncaughtError did not fire. Source mapping now degrades to the unmapped stack and the pretty page falls back to a plain stack response instead.

• #14418 cb30df3 Thanks @matthewdavidrodgers! - Improve routing performance for Workers with assets

Reduce request handling latency by streamlining the router Worker's request path. The loopback infrastructure remains available for future use.

• #14727 3f3afbb Thanks @ascorbic! - Prevent local Browser Rendering teardown from hanging when Chrome does not exit

Miniflare now bounds graceful Chrome shutdown and forcefully terminates the browser process tree when needed, preventing disposal from waiting indefinitely.

• #14723 e6fbc4e Thanks @ascorbic! - Prevent concurrent Miniflare instances from deleting each other's temporary email sessions

Email session cleanup now removes only the current instance's session directory and leaves the shared parent intact, avoiding startup failures when multiple local runtimes use the same project.

Original source

Patch Changes

#14661 414ce87 Thanks @dependabot! - Update dependencies of "create-cloudflare"

The following dependency versions have been updated:

Dependency

From

To

create-react-router

8.1.0

8.2.0

#14499 8cd805d Thanks @colinhacks! - Detect the nub package manager

C3 resolves the invoking package manager with which-pm-runs, which already returns nub, but detectPackageManager had no nub case in its switch, so it fell through to the npm default and produced npm commands. detectPackageManager now maps nub to its nub/nubx executables, and @cloudflare/cli-shared-helpers's package-install helpers accept nub as a package manager.

Original source

Patch Changes

#14417 34e696d Thanks @matthewdavidrodgers! - Improve asset serving performance by removing an unnecessary internal dispatch hop

Asset requests and RPC calls now avoid an extra internal forwarding layer, reducing latency. The forwarding infrastructure is preserved for future use by cohort-based deployments.

#14705 00f41d6 Thanks @WillTaylorDev! - Retry asset reads from KV when they fail

The asset worker reads static assets from KV, and a read can occasionally fail with a transient error. It previously retried only once before giving up. It now retries a few times with exponential backoff, which reduces the chance of serving an error. A missing asset is not treated as a failure and is not retried.

#14418 cb30df3 Thanks @matthewdavidrodgers! - Improve routing performance for Workers with assets

Reduce request handling latency by streamlining the router Worker's request path. The loopback infrastructure remains available for future use.

Original source

Patch Changes

#14678 4e62bba Thanks @apeacock1991! - Fix test runs hanging after a Durable Object logs and rejects blockConcurrencyWhile()

Console messages emitted from another Durable Object are now buffered until execution returns to the test runner, avoiding I/O that cannot complete after the object's input gate breaks.

Updated dependencies [34e696d, d39ae01, 3de70df, c79504f, 9f04a7e, 9f04a7e, cb30df3, cb6c3f9, c7dbe1a, 3f3afbb, e6fbc4e, 4e1a7a7, 9f04a7e]:

• [email protected]
• [email protected]

Original source

Patch Changes

• #14610 e727842 Thanks @martijnwalraven! - Keep watching config changes after a failed dev server restart

  Previously, when a config change made the dev server restart fail — for example because the updated Worker config was invalid — the plugin stopped watching config changes entirely: the change handler (covering the Worker config files, local dev vars, and the assets configuration) removed itself before restarting, and only a successfully created server would register a fresh one. Since Vite keeps the current server running when a restart fails, every subsequent config change (including the one that fixes the config) was silently ignored for the rest of the session.

  The handler now stays registered and guards against re-entrant restarts instead, so fixing the config restarts the dev server as expected.

• #14418 cb30df3 Thanks @matthewdavidrodgers! - Improve routing performance for Workers with assets

  Reduce request handling latency by streamlining the router Worker's request path. The loopback infrastructure remains available for future use.

Updated dependencies [34e696d, d39ae01, 3de70df, c79504f, 9f04a7e, 9f04a7e, cb30df3, cb6c3f9, c7dbe1a, 3f3afbb, e6fbc4e, 4e1a7a7, 9f04a7e]:

• [email protected]
• [email protected]

Original source

You can now preview the content of sent emails directly from the Email Service Activity log. Expand a sent email and open the new Preview section to inspect the message as it was sent, across tabs for the rendered HTML body, the Text body, the Headers, the Attachments, and the full Raw RFC 5322 source.

Previously, the Activity log surfaced delivery and authentication metadata but not the message content, making rendering and content issues harder to debug. Message preview closes that gap.

To make messages previewable, turn on Email preview in your sending domain's settings. Previews cover messages sent while the setting is turned on and are retained for about seven days. Sending domains onboarded on or after 2026-07-02 have Email preview turned on automatically.

Refer to Email logs for more information.

Original source

This emergency release adds a new managed rule to block active exploitation of a critical remote code execution (RCE) and SQL injection (SQLi) vulnerability found in popular web frameworks.

Key Findings

• Generic Frameworks - Unauthenticated RCE: Attackers can execute arbitrary system commands with web server privileges by sending malicious input containing invalid path sequences during request processing.
• Generic Frameworks - SQLi: Attackers can execute unauthorized database queries due to a failure to sanitize input values within request parameters.

Ruleset

Rule ID

Legacy Rule ID

Description

Previous Action

New Action

Comments

Cloudflare Managed Ruleset

7dfb2df4708d4b88b9911dc0550664b6

N/A

Generic Rules - Unauthenticated RCE

N/A

Block

This is a new detection.

Cloudflare Managed Ruleset

1c060d3a371549219ee290d7ed933fcc

N/A

Generic Rules - SQLi

N/A

Block

This is a new detection.

Cloudflare Free Ruleset

ebd3f2df15c74ddcbf6220c9b5ec246a

N/A

Generic Rules - Unauthenticated RCE

N/A

Block

This is a new detection.

Cloudflare Free Ruleset

db003b39b7774859a8d588ce33697a1a

N/A

Generic Rules - SQLi

N/A

Block

This is a new detection.

Original source

Wrangler now includes wrangler flagship, a command suite for managing Flagship apps and feature flags from your terminal.

Create an app and, if you use it from a Worker, add it to your wrangler.json or wrangler.jsonc file as a binding:

wrangler flagship apps create "My Worker App" \
--binding FLAGS \
--update-config

Then create flags for the behavior you want to control. Flags can be booleans, strings, numbers, or JSON values:

wrangler flagship flags create <APP_ID> new-checkout
wrangler flagship flags create <APP_ID> checkout-flow \
--variation control=old-checkout \
--variation treatment=new-checkout \
--default control \
--type string

After a flag exists, change its default variation or use enable and disable commands as kill switches. Existing targeting rules continue to apply unless you change or clear them explicitly:

wrangler flagship flags update <APP_ID> checkout-flow --default treatment
wrangler flagship flags disable <APP_ID> checkout-flow
wrangler flagship flags enable <APP_ID> checkout-flow

For release workflows, use rollout, split, and rules to change exposure without redeploying your Worker:

wrangler flagship flags rollout <APP_ID> new-checkout \
--to on \
--percentage 25 \
--by user_id
wrangler flagship flags split <APP_ID> checkout-flow \
--weight control=80 \
--weight treatment=20 \
--by user_id
wrangler flagship flags rules update <APP_ID> checkout-flow \
--priority 1 \
--when "country equals US"

These commands can also be used from CI/CD pipelines, scripts, and AI agents to inspect Flagship state, update flag behavior, or roll back changes through Wrangler.

Refer to the wrangler flagship command reference for the full command guide.

Original source

Internal DNS is now generally available. Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane you already use for public DNS, Zero Trust, and application services.

Why it matters

Consolidate DNS operations. Public and private DNS run on one platform, with one API, one audit trail, and one place to set policy.

Simplify split-horizon DNS. Internal and external resolution are defined as separate views over shared zones, managed from a single control plane — so there is no drift to chase down.

Extend Zero Trust to DNS. Resolver policies decide which users and devices resolve against which view, enforced by the same Gateway that already governs the rest of your traffic.

Setting up Internal DNS takes three steps: create a zone, create a view, and define a resolver policy.

POST /zones
{
  "account": {
    "id": "<ACCOUNT_ID>"
  },
  "name": "corp.internal",
  "type": "internal"
}

Internal DNS is included with Cloudflare Gateway for Enterprise customers. To get started, refer to the Internal DNS documentation.

Original source