chore(deps): update cloudflare wrangler packages

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@cloudflare/vite-plugin (source)	1.37.2 → 1.37.3
wrangler (source)	4.93.0 → 4.93.1

---

Release Notes

cloudflare/workers-sdk (@​cloudflare/vite-plugin)

v1.37.3

Compare Source

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, e04e180, 59cd880, 62abf97, e8c2031, e349fe0, da0fa8c, a5c9365]:

  • miniflare@​4.20260520.0
  • wrangler@​4.93.1

cloudflare/workers-sdk (wrangler)

v4.93.1

Compare Source

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.

• #​13990 e04e180 Thanks @​petebacondarwin! - Improve the log message shown when an asset upload attempt fails and is retried

  The retry message now reports which attempt is being made (e.g. Asset upload failed. Retrying... 1 of 5 attempts.), making it easier to gauge how close Wrangler is to exhausting its retry budget. The raw error object is no longer appended to this user-facing message; it is instead logged at debug level (visible via WRANGLER_LOG=debug).

• #​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

---

Configuration

📅 Schedule: (in timezone Asia/Tokyo)

• Branch creation
  • "before 3am"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.