chore(deps): bump undici, @cloudflare/vite-plugin and wrangler in /dashboard

[dependabot]

Bumps undici to 7.29.0 and updates ancestor dependencies undici, @cloudflare/vite-plugin and wrangler. These dependencies need to be updated together.

Updates undici from 7.24.8 to 7.29.0

Release notes

Sourced from undici's releases.

v7.29.0

⚠️ Security fixes

High severity

• GHSA-4cwx-7wf7-3272: malformed qualified private Cache-Control directives could cause cross-user information disclosure in shared caches or a parse-time crash. The cache parser now treats empty qualified directives conservatively and safely handles mixed qualified and unqualified directives. Fixed by 9f10f1e9, with regression coverage in 466e99d1.

Medium severity

• GHSA-m8rv-5g2x-5cg5: a malicious type property on a duck-typed blob-like HTTP/1.1 request body could inject CRLF sequences into the generated content-type header. Undici now coerces and validates the value before adding it to the request. Fixed by 33928bc2.
• GHSA-jr45-8vmc-qm54: optional whitespace around = in qualified no-cache and private directives could bypass shared-cache restrictions and disclose authenticated data across users. Cache-Control parsing now normalizes these forms and applies conservative cache decisions. Fixed by 98011a86.
• GHSA-8xcm-r25x-g524: the retry interceptor could expose a stale Content-Length after resuming a partial response, potentially causing downstream response desynchronization, hangs, or corruption. Undici now rejects partial responses whose Content-Length is inconsistent with Content-Range. Fixed by 1b5a5312, with corrected fixtures in 4a9dafb1.
• GHSA-v3r7-h72x-cjcm: unsanitized domain and unparsed values passed to setCookie() could inject cookie attributes. Undici now validates cookie domains, paths, and unparsed attributes more strictly. Fixed by 3bf91ddb.

Full Changelog: nodejs/undici@v7.28.0...v7.29.0

v7.28.0

⚠️ Security Release

This release line addresses 7 security advisories, all shipped in v7.28.0.

Action required: Upgrade to undici 7.28.0 or later.

npm install undici@^7.28.0

The v7 line is not affected by GHSA-38rv-x7px-6hhq (CVE-2026-9675), which is an 8.x-only regression.

Note on GHSA-hm92-r4w5-c3mj: this fix shipped in v7.28.0, not the earlier 7.2x line — the vulnerable single-pool code was still present through v7.27.2. The per-origin pool fix is 3805b8f8 (#5041).

Summary

Advisory	CVE	Severity (CVSS)	Fixed in	Fix commit
GHSA-vxpw-j846-p89q	CVE-2026-12151	High (7.5)	7.28.0	8cb10f98
GHSA-vmh5-mc38-953g	CVE-2026-9697	High (7.4)	7.28.0	04201f89
GHSA-hm92-r4w5-c3mj	CVE-2026-6734	High (7.5)	7.28.0	3805b8f8
GHSA-pr7r-676h-xcf6	CVE-2026-9678	Moderate (5.9)	7.28.0	85a24055
GHSA-p88m-4jfj-68fv	CVE-2026-9679	Moderate (5.9)	7.28.0	d0574cc4
GHSA-g8m3-5g58-fq7m	CVE-2026-11525	Low (3.7)	7.28.0	d0574cc4
GHSA-35p6-xmwp-9g52	CVE-2026-6733	Low (3.7)	7.28.0	ea8930cf

---

... (truncated)

Commits

• 9e38fc1 Bumped v7.29.0 (#5590)
• d887e34 fix: validate coerced header values for CRLF (#5579)
• 33928bc fix: validate blob body content type
• 98011a8 fix(cache): harden cache directive parsing
• 4a9dafb test(retry): correct broken content-range fixtures in retry-handler.js
• 1b5a531 fix(retry): reject partial content length mismatch
• 466e99d test: cover crash on mixed unqualified and qualified private cache directives
• 9f10f1e fix: handle empty qualified private cache directive
• 3bf91dd fix: harden cookie domain, path, and unparsed attribute validation
• f9eba0a Bumped v7.28.0 (#5430)
• Additional commits viewable in compare view

Updates @cloudflare/vite-plugin from 1.37.1 to 1.53.1

Release notes

Sourced from @​cloudflare/vite-plugin's releases.

@​cloudflare/vite-plugin@​1.53.1

Patch Changes

• Updated dependencies [59872c4, c68f9cb, 99a1f49, 5ae9d5b, 4b52975, ce9b151, ef73a28, 649f667, 39dcea6, 99a1f49, 99a1f49, 99a1f49, f2437e6, 30c2d47]:
  • wrangler@4.125.0
  • miniflare@5.20260820.0-alpha

@​cloudflare/vite-plugin@​1.53.0

Minor Changes

• #15026 6529f0c Thanks @​petebacondarwin! - Allow containers to be attached to a Durable Object from its exports entry

  A container can now be linked to its Durable Object from the export side, using a new container field that names an entry in the containers array. As a result containers[].class_name is now optional — a container that is referenced this way only needs a name:

  {
    "name": "my-worker",
    "main": "worker.js",
    "compatibility_date": "2026-07-01",
    "containers": [
      { "name": "my-container", "image": "./Dockerfile", "max_instances": 1 }
    ],
    "exports": {
      "MyContainerDO": {
        "type": "durable-object",
        "storage": "sqlite",
        "container": "my-container"
      }
    }
  }

  The existing containers[].class_name direction keeps working and either direction may be used, but the two must agree: a container that names its Durable Object cannot also be claimed by a different one.

  container is only valid on live durable-object exports (created and expecting-transfer) and requires storage: "sqlite". Wrangler now also reports an error when:

  • a container reference names a container that does not exist
  • two Durable Object exports claim the same container
  • a container and a Durable Object export disagree about which one they are linked to
  • a container ends up linked to no Durable Object at all
  • two containers share a name
  • a container's class_name names a Durable Object whose storage is legacy-kv
  • two containers are attached to the same Durable Object

  That last case was previously accepted but could never work: workerd attaches a single container per Durable Object namespace, and in local development every container for a class builds into the same image tag, so one silently overwrote the other. If you have two containers on one class_name, give each its own Durable Object class.

Patch Changes

• #15238 3a4fc6b Thanks @​jamesopstad! - Honor access.dev when running Workers with @cloudflare/vite-plugin, so ctx.access.getIdentity() returns the configured identity.

... (truncated)

Changelog

Sourced from @​cloudflare/vite-plugin's changelog.

1.53.1

Patch Changes

• Updated dependencies [59872c4, c68f9cb, 99a1f49, 5ae9d5b, 4b52975, ce9b151, ef73a28, 649f667, 39dcea6, 99a1f49, 99a1f49, 99a1f49, f2437e6, 30c2d47]:
  • wrangler@4.125.0
  • miniflare@5.20260820.0-alpha

1.53.0

Minor Changes

• #15026 6529f0c Thanks @​petebacondarwin! - Allow containers to be attached to a Durable Object from its exports entry

  A container can now be linked to its Durable Object from the export side, using a new container field that names an entry in the containers array. As a result containers[].class_name is now optional — a container that is referenced this way only needs a name:

  {
    "name": "my-worker",
    "main": "worker.js",
    "compatibility_date": "2026-07-01",
    "containers": [
      { "name": "my-container", "image": "./Dockerfile", "max_instances": 1 }
    ],
    "exports": {
      "MyContainerDO": {
        "type": "durable-object",
        "storage": "sqlite",
        "container": "my-container"
      }
    }
  }

  The existing containers[].class_name direction keeps working and either direction may be used, but the two must agree: a container that names its Durable Object cannot also be claimed by a different one.

  container is only valid on live durable-object exports (created and expecting-transfer) and requires storage: "sqlite". Wrangler now also reports an error when:

  • a container reference names a container that does not exist
  • two Durable Object exports claim the same container
  • a container and a Durable Object export disagree about which one they are linked to
  • a container ends up linked to no Durable Object at all
  • two containers share a name
  • a container's class_name names a Durable Object whose storage is legacy-kv
  • two containers are attached to the same Durable Object

  That last case was previously accepted but could never work: workerd attaches a single container per Durable Object namespace, and in local development every container for a class builds into the same image tag, so one silently overwrote the other. If you have two containers on one class_name, give each its own Durable Object class.

Patch Changes

... (truncated)

Commits

• 38b4623 Version Packages (#15250)
• 8ee43f6 Version Packages (#15175)
• 1552bce [wrangler] Quieten warnings and stray output in tests (#15209)
• 3a4fc6b Pass access configuration to Router Worker (#15238)
• 8fb2b87 [wrangler] Use FedRAMP container registries (#15196)
• d4f441f [vite-plugin-cloudflare] Handle cancelled request bodies (#15028)
• 1f79ace Use a fixed default compatibility date derived from the pinned workerd (#15185)
• 6529f0c [wrangler] Allow containers to be attached to Durable Objects via exports (...
• c576a82 Version Packages (#15154)
• e5d56e9 Version Packages (#15145)
• Additional commits viewable in compare view

Updates wrangler from 4.92.0 to 4.125.0

Release notes

Sourced from wrangler's releases.

wrangler@4.125.0

Minor Changes

• #14995 59872c4 Thanks @​ThomasRubini! - Add connect trigger for raw sockets

  You can now configure a Worker to receive raw socket connections during wrangler dev, delivered directly to the Worker's connect(socket, env, ctx) handler:

  {
    "connect": [{ "protocol": "tcp", "port": 5432 }]
  }

  Each entry opens a listening socket on 127.0.0.1 (or the given address) that forwards incoming connections straight to the Worker, bypassing the local dev HTTP entry point. This requires the experimental compatibility flag. Only "tcp" is supported at the moment.

  @cloudflare/config also supports declaring this trigger via triggers.connect(...), which lowers to the connect field above:

  import { defineWorker, triggers } from "@cloudflare/config";
  export default defineWorker({
  triggers: [
  triggers.connect({ protocol: "tcp", port: 5432, address: "127.0.0.1" }),
  ],
  });

• #15172 c68f9cb Thanks @​WillTaylorDev! - Add container support to worker previews

  Worker previews now support containers through a new previews.containers configuration block. Container configuration doesn't inherit, so declare containers explicitly in the previews block to enable them for previews. This mirrors how previews.durable_objects works today. Wrangler names each preview container application {worker_name}_{preview_slug}_{class_name}, normalising and shortening the result to what the API accepts. Either change appends a short digest of the composed name, so two names that would otherwise land on one stay distinct. An entry cannot set its own name, because application names are unique to an account and a fixed name would collide between two previews of the same Worker. A Durable Object class is backed by at most one container application, so the validator rejects two entries that share a class_name. Wrangler skips container applications bound to Durable Object classes that another Worker implements through script_name, because the implementing Worker owns its own container application. A binding is not required: a Durable Object declared through migrations or exports and reached only over ctx.exports can still back a container. Every entry must set class_name. A previews.containers entry whose class_name matches no Durable Object class at all is rejected before the preview deployment is created, so a typo fails loudly instead of producing a preview with no container.

  Wrangler creates the container applications on wrangler preview. Deleting a preview tears them down server side, so wrangler preview delete doesn't remove them.

  Container build and deploy progress prints to stdout. wrangler preview --json suppresses wrangler's own output so it doesn't interleave with the payload, and warnings and errors still go to stderr. Docker's build output and the progress spinner write to stdout directly and bypass that suppression, so parse --json from a non interactive shell, where the spinner is skipped, and prefer a prebuilt image over a Dockerfile.

• #15174 649f667 Thanks @​WillTaylorDev! - [private beta]: Create the parent Worker automatically when wrangler preview targets one that doesn't exist yet

  Previews hang off a parent Worker, so running wrangler preview before the Worker had ever been deployed failed with a raw API error naming the Preview endpoint. Wrangler now offers to create an empty parent Worker and then carries on creating the Preview. The parent uses the same workers.dev and Preview URL settings that wrangler deploy would resolve, without applying routes or cron triggers. In non-interactive environments, Wrangler creates the Worker without asking.

• #14735 30c2d47 Thanks @​vaishnav-mk! - Add individual and batch Workflow instance deletion to the runtime and SDK.

  • WorkflowInstance.delete() deletes one instance. Self-deletion stops the current execution.
  • env.MY_WORKFLOW.deleteBatch(instanceIds) deletes up to 100 instances and returns { deleted, errors } per input position.
  • wrangler workflows instances delete <name> [id..] deletes instances remotely or with --local; IDs can also come from a JSON array passed with --filename, with a combined limit of 100.

Patch Changes

• #15260 5ae9d5b Thanks @​dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

... (truncated)

Commits

• 38b4623 Version Packages (#15250)
• 39dcea6 move writeOutput into deploy helpers (#15284)
• 4cdfebd [wrangler] Skip VPC Service remote binding test (#15281)
• f2437e6 [workers-auth] Use again the temporary account from the same command run (#15...
• c68f9cb feat(wrangler): add container support to worker previews (#15172)
• bfcc442 [vitest-plugin] Rename package for v1 (#15074)
• 30c2d47 [workflows] add individual and batch instance deletion (#14735)
• 630048b Move a few more bits of triggers deploy into deploy-helpers (#15253)
• 649f667 WC-5764 Create parent Worker for Previews (#15174)
• 59872c4 [wrangler] add connect wrangler config section (#14995)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.