Version Packages

[workers-devprod]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

miniflare@4.20260520.0

Patch Changes

• #13978 fa1f61f Thanks @sassyconsultingllc! - Bump ws from 8.18.0 to 8.20.1 to address GHSA-58qx-3vcg-4xpx

  GHSA-58qx-3vcg-4xpx / CVE-2026-45736 reports an uninitialized-memory disclosure in ws@<8.20.1 when a TypedArray is passed as the reason argument to WebSocket.close(). The fix shipped in ws@8.20.1 on 2026-05-12. This change bumps the workspace catalog entry so that miniflare, wrangler, and @cloudflare/vite-plugin all pick up the patched release.

• #13977 2679e05 Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260518.1	1.20260519.1

• #13984 7e40d98 Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260519.1	1.20260520.1

• #13912 d803737 Thanks @petebacondarwin! - Fix /cdn-cgi/* host validation incorrectly accepting subdomains of exact configured routes

  Miniflare's /cdn-cgi/* host/origin validator was treating exact configured routes the same as wildcard configured routes, so a request whose Host or Origin hostname was a subdomain of an exact route (e.g. sub.my-custom-site.com for a my-custom-site.com/* route) was incorrectly accepted. Exact configured routes and the configured upstream hostname are now required to match the request hostname exactly. Subdomain matching is only applied to wildcard routes such as *.example.com/*. Localhost hostnames continue to be allowed as before.

  This affects wrangler dev and local development through @cloudflare/vite-plugin, both of which use Miniflare under the hood.

• #13971 59cd880 Thanks @petebacondarwin! - Improve error diagnostics in the Browser Run binding worker

  When the local Browser Run binding failed to reach an upstream — for example when Chrome failed to launch and miniflare's loopback /browser/launch endpoint returned a 500 with a stack-trace text body — the binding worker would call response.json() on the non-JSON body and throw an opaque SyntaxError: Unexpected token X, "..." is not valid JSON. The actual upstream error message (e.g. Chrome readiness probe at ... timed out after 5000ms) was discarded.

  The binding worker now reads the response body as text first, surfaces the HTTP status and body content in the thrown error, and chains the original SyntaxError via cause when the body was a 2xx response that didn't parse as JSON. This makes both local-dev failures and CI test flakes self-diagnosing.

• #13980 e8c2031 Thanks @petebacondarwin! - Recover from corrupted @puppeteer/browsers cache when launching a Browser Run session

  When Miniflare's local Browser Run binding launches Chrome, it calls @puppeteer/browsers' install() to ensure the binary is present. If a previous install() was interrupted mid-extraction (test timeout, process kill, antivirus quarantine), the cache directory can be left partially populated — the folder exists but the executable inside it is missing. install() then throws The browser folder (...) exists but the executable (...) is missing on every subsequent call within the same process and the entire test session, breaking every later Browser Run operation until the cache is manually cleared.

  launchBrowser now catches that specific error, removes the corrupted cache directory, and retries install() once. If the corruption persists after cleanup, the original error is rethrown with a clearer message.

  This complements #13971, which surfaced the original error from inside the binding worker. With that diagnostic in place and this self-healing layer, the previously-intermittent "browser folder exists but executable missing" failure mode should no longer fail an entire CI run.

@cloudflare/pages-shared@0.13.138

Patch Changes

• Updated dependencies [fa1f61f, 2679e05, 7e40d98, d803737, 59cd880, e8c2031]:
  • miniflare@4.20260520.0

@cloudflare/vite-plugin@1.37.3

Patch Changes

• #13978 fa1f61f Thanks @sassyconsultingllc! - Bump ws from 8.18.0 to 8.20.1 to address GHSA-58qx-3vcg-4xpx

  GHSA-58qx-3vcg-4xpx / CVE-2026-45736 reports an uninitialized-memory disclosure in ws@<8.20.1 when a TypedArray is passed as the reason argument to WebSocket.close(). The fix shipped in ws@8.20.1 on 2026-05-12. This change bumps the workspace catalog entry so that miniflare, wrangler, and @cloudflare/vite-plugin all pick up the patched release.

• #13912 d803737 Thanks @petebacondarwin! - Fix /cdn-cgi/* host validation incorrectly accepting subdomains of exact configured routes

  Miniflare's /cdn-cgi/* host/origin validator was treating exact configured routes the same as wildcard configured routes, so a request whose Host or Origin hostname was a subdomain of an exact route (e.g. sub.my-custom-site.com for a my-custom-site.com/* route) was incorrectly accepted. Exact configured routes and the configured upstream hostname are now required to match the request hostname exactly. Subdomain matching is only applied to wildcard routes such as *.example.com/*. Localhost hostnames continue to be allowed as before.

  This affects wrangler dev and local development through @cloudflare/vite-plugin, both of which use Miniflare under the hood.

• #13919 c7eab7f Thanks @petebacondarwin! - Fix the outbound CF-Worker header reflecting the route pattern hostname instead of the parent zone, and falling back to <worker-name>.example.com under vite dev, vitest-pool-workers, and getPlatformProxy

  Two related issues affected the CF-Worker header on outbound subrequests in local development:

  1. Under @cloudflare/vite-plugin, @cloudflare/vitest-pool-workers, and getPlatformProxy, the header fell back to <worker-name>.example.com even when routes were configured, because unstable_getMiniflareWorkerOptions and the equivalent getPlatformProxy worker-options path did not propagate a zone value to Miniflare. This broke local development against services that reject unknown CF-Worker hosts (for example, Apple WeatherKit returns 403 Forbidden).
  2. Across the above paths and wrangler dev --local, when a route used the zone_name field (for example { pattern: "foo.example.com/*", zone_name: "example.com" }), the header was set to the pattern's hostname (foo.example.com) rather than the zone name (example.com). Production sets CF-Worker to the zone name that owns the Worker, so this was inconsistent with deployed behaviour.

  Both bugs are fixed: the new unstable_getMiniflareWorkerOptions / getPlatformProxy path now propagates a zone derived from the first configured route, and all four local-dev paths now prefer a route's explicit zone_name over the pattern hostname when computing that zone. When zone_name isn't set, the existing best-effort behaviour is preserved — for wrangler dev this means dev.host is still honoured as a local override and the pattern hostname is used as a final fallback. Resolving the parent zone for zone_id-only, custom_domain, or plain-string routes would require an API lookup, so locally we still approximate it with the pattern hostname.

  Note: dev.host is intentionally not consulted by the unstable_getMiniflareWorkerOptions / getPlatformProxy paths — the dev config block is specific to wrangler dev.

• Updated dependencies [fa1f61f, 2679e05, 7e40d98, adc9221, 735852d, d803737, c7eab7f, 59cd880, 62abf97, e8c2031, e349fe0, da0fa8c, a5c9365]:

  • miniflare@4.20260520.0
  • wrangler@4.93.1

@cloudflare/vitest-pool-workers@0.16.8

Patch Changes

• #13919 c7eab7f Thanks @petebacondarwin! - Fix the outbound CF-Worker header reflecting the route pattern hostname instead of the parent zone, and falling back to <worker-name>.example.com under vite dev, vitest-pool-workers, and getPlatformProxy

  Two related issues affected the CF-Worker header on outbound subrequests in local development:

  1. Under @cloudflare/vite-plugin, @cloudflare/vitest-pool-workers, and getPlatformProxy, the header fell back to <worker-name>.example.com even when routes were configured, because unstable_getMiniflareWorkerOptions and the equivalent getPlatformProxy worker-options path did not propagate a zone value to Miniflare. This broke local development against services that reject unknown CF-Worker hosts (for example, Apple WeatherKit returns 403 Forbidden).
  2. Across the above paths and wrangler dev --local, when a route used the zone_name field (for example { pattern: "foo.example.com/*", zone_name: "example.com" }), the header was set to the pattern's hostname (foo.example.com) rather than the zone name (example.com). Production sets CF-Worker to the zone name that owns the Worker, so this was inconsistent with deployed behaviour.

  Both bugs are fixed: the new unstable_getMiniflareWorkerOptions / getPlatformProxy path now propagates a zone derived from the first configured route, and all four local-dev paths now prefer a route's explicit zone_name over the pattern hostname when computing that zone. When zone_name isn't set, the existing best-effort behaviour is preserved — for wrangler dev this means dev.host is still honoured as a local override and the pattern hostname is used as a final fallback. Resolving the parent zone for zone_id-only, custom_domain, or plain-string routes would require an API lookup, so locally we still approximate it with the pattern hostname.

  Note: dev.host is intentionally not consulted by the unstable_getMiniflareWorkerOptions / getPlatformProxy paths — the dev config block is specific to wrangler dev.

• Updated dependencies [fa1f61f, 2679e05, 7e40d98, adc9221, 735852d, d803737, c7eab7f, 59cd880, 62abf97, e8c2031, e349fe0, da0fa8c, a5c9365]:

  • miniflare@4.20260520.0
  • wrangler@4.93.1

wrangler@4.93.1

Patch Changes

• #13978 fa1f61f Thanks @sassyconsultingllc! - Bump ws from 8.18.0 to 8.20.1 to address GHSA-58qx-3vcg-4xpx

  GHSA-58qx-3vcg-4xpx / CVE-2026-45736 reports an uninitialized-memory disclosure in ws@<8.20.1 when a TypedArray is passed as the reason argument to WebSocket.close(). The fix shipped in ws@8.20.1 on 2026-05-12. This change bumps the workspace catalog entry so that miniflare, wrangler, and @cloudflare/vite-plugin all pick up the patched release.

• #13977 2679e05 Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260518.1	1.20260519.1

• #13984 7e40d98 Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  workerd	1.20260519.1	1.20260520.1

• #13963 adc9221 Thanks @gabivlj! - Preserve sibling container image tags during local dev cleanup

  Wrangler now keeps other cloudflare-dev image tags from the same dev session when multiple containers share a Dockerfile. Previously, duplicate-image cleanup could remove earlier container tags if Docker BuildKit produced the same image ID for each build.

• #13839 735852d Thanks @matingathani! - fix: show actionable hint when /memberships returns a bad-credentials error (code 9106)

  Previously, wrangler threw a raw Cloudflare API error ("Missing X-Auth-Key, X-Auth-Email or Authorization headers") with no guidance. Now it emits a UserError explaining that an environment variable such as CLOUDFLARE_API_TOKEN, CLOUDFLARE_API_KEY, or CLOUDFLARE_EMAIL may be set to an invalid value, and suggests running wrangler logout / wrangler login to re-authenticate.

• #13912 d803737 Thanks @petebacondarwin! - Fix /cdn-cgi/* host validation incorrectly accepting subdomains of exact configured routes

  Miniflare's /cdn-cgi/* host/origin validator was treating exact configured routes the same as wildcard configured routes, so a request whose Host or Origin hostname was a subdomain of an exact route (e.g. sub.my-custom-site.com for a my-custom-site.com/* route) was incorrectly accepted. Exact configured routes and the configured upstream hostname are now required to match the request hostname exactly. Subdomain matching is only applied to wildcard routes such as *.example.com/*. Localhost hostnames continue to be allowed as before.

  This affects wrangler dev and local development through @cloudflare/vite-plugin, both of which use Miniflare under the hood.

• #13919 c7eab7f Thanks @petebacondarwin! - Fix the outbound CF-Worker header reflecting the route pattern hostname instead of the parent zone, and falling back to <worker-name>.example.com under vite dev, vitest-pool-workers, and getPlatformProxy

  Two related issues affected the CF-Worker header on outbound subrequests in local development:

  1. Under @cloudflare/vite-plugin, @cloudflare/vitest-pool-workers, and getPlatformProxy, the header fell back to <worker-name>.example.com even when routes were configured, because unstable_getMiniflareWorkerOptions and the equivalent getPlatformProxy worker-options path did not propagate a zone value to Miniflare. This broke local development against services that reject unknown CF-Worker hosts (for example, Apple WeatherKit returns 403 Forbidden).
  2. Across the above paths and wrangler dev --local, when a route used the zone_name field (for example { pattern: "foo.example.com/*", zone_name: "example.com" }), the header was set to the pattern's hostname (foo.example.com) rather than the zone name (example.com). Production sets CF-Worker to the zone name that owns the Worker, so this was inconsistent with deployed behaviour.

  Both bugs are fixed: the new unstable_getMiniflareWorkerOptions / getPlatformProxy path now propagates a zone derived from the first configured route, and all four local-dev paths now prefer a route's explicit zone_name over the pattern hostname when computing that zone. When zone_name isn't set, the existing best-effort behaviour is preserved — for wrangler dev this means dev.host is still honoured as a local override and the pattern hostname is used as a final fallback. Resolving the parent zone for zone_id-only, custom_domain, or plain-string routes would require an API lookup, so locally we still approximate it with the pattern hostname.

  Note: dev.host is intentionally not consulted by the unstable_getMiniflareWorkerOptions / getPlatformProxy paths — the dev config block is specific to wrangler dev.

• #13954 62abf97 Thanks @petebacondarwin! - Read the on-disk OAuth state lazily so CLOUDFLARE_API_TOKEN from .env takes priority correctly

  Wrangler previously read its OAuth state from the user auth config file (for example ~/.config/.wrangler/config/default.toml) eagerly at module-import time. That happens before .env files are loaded, so the in-memory state would always hold the OAuth tokens even when the user only wanted to authenticate via CLOUDFLARE_API_TOKEN. If that stored OAuth token happened to be expired, Wrangler would try to refresh it (and fail), aborting the command with Failed to fetch auth token: 400 Bad Request and Not logged in. — even though a valid API token was in scope.

  Wrangler now reads the auth config file on demand, after .env has been loaded. When CLOUDFLARE_API_TOKEN (or CLOUDFLARE_API_KEY + CLOUDFLARE_EMAIL) is present, the OAuth state on disk is no longer consulted, the OAuth refresh endpoint is no longer called, and the env-based token is used directly. Sibling-process refresh-token rotation is also handled naturally because every check reads the current file contents.

  Internally, the exported reinitialiseAuthTokens() function is removed — there is no module-level OAuth cache left to invalidate.

  Fixes #13744.

• #13951 e349fe0 Thanks @sejoker! - Enforce minimum 60 second interval for R2 Data Catalog sinks

  R2 Data Catalog sinks now require a minimum --roll-interval of 60 seconds to prevent compaction issues in the R2 Data Catalog. This validation is applied when creating sinks via wrangler pipelines sinks create with type r2-data-catalog, and during the interactive wrangler pipelines setup flow.

  Regular R2 sinks are not affected and can still use intervals as low as 10 seconds.

• #13959 da0fa8c Thanks @dmmulroy! - Recognize Artifacts repositories that are still being created

  Wrangler's Artifacts repo status type now accepts the creating lifecycle state alongside existing in-progress statuses.

• #13964 a5c9365 Thanks @danielrs! - Use dedicated API endpoint for wrangler secret bulk

  wrangler secret bulk now uses a more efficient, dedicated API endpoint. This reduces the operation from 2 API calls to 1 and eliminates the risk of accidentally affecting non-secret bindings.

• Updated dependencies [fa1f61f, 2679e05, 7e40d98, d803737, 59cd880, e8c2031]:

  • miniflare@4.20260520.0

@cloudflare/containers-shared@0.15.1

Patch Changes

• #13963 adc9221 Thanks @gabivlj! - Preserve sibling container image tags during local dev cleanup

  Wrangler now keeps other cloudflare-dev image tags from the same dev session when multiple containers share a Dockerfile. Previously, duplicate-image cleanup could remove earlier container tags if Docker BuildKit produced the same image ID for each build.

[github-actions]

✅ All changesets look good

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[pkg-pr-new]

create-cloudflare

npm i https://pkg.pr.new/create-cloudflare@13969

@cloudflare/kv-asset-handler

npm i https://pkg.pr.new/@cloudflare/kv-asset-handler@13969

miniflare

npm i https://pkg.pr.new/miniflare@13969

@cloudflare/pages-shared

npm i https://pkg.pr.new/@cloudflare/pages-shared@13969

@cloudflare/unenv-preset

npm i https://pkg.pr.new/@cloudflare/unenv-preset@13969

@cloudflare/vite-plugin

npm i https://pkg.pr.new/@cloudflare/vite-plugin@13969

@cloudflare/vitest-pool-workers

npm i https://pkg.pr.new/@cloudflare/vitest-pool-workers@13969

@cloudflare/workers-editor-shared

npm i https://pkg.pr.new/@cloudflare/workers-editor-shared@13969

@cloudflare/workers-utils

npm i https://pkg.pr.new/@cloudflare/workers-utils@13969

wrangler

npm i https://pkg.pr.new/wrangler@13969

commit: 2a6fde1