Skip to content
loke.dev
A cyan chain with an amber replacement link and broken pieces floating above it beside an abstract cloud.

Fix npm Audit Flagging undici Through Wrangler and Miniflare

Upgrade the Wrangler dependency chain that pinned undici 7.28.0, verify Miniflare resolves 7.29.0, and keep CI audit gates meaningful.

Published Updated 6 min read

Your CI can fail on an undici advisory even when your application never lists undici. In the reported Wrangler case, the dependency arrived through Miniflare: wrangler@4.118.0 resolved miniflare@4.20260730.0, which pinned undici@7.28.0. npm audit could identify the problem but could not update that transitive version.

The released fix is to update Wrangler, regenerate the lockfile, and verify the resolved dependency path. You do not need to disable the audit gate, run npm audit fix --force, or add a permanent undici override.

The short fix

Start from a clean branch because this operation should change package.json and the lockfile. The commands below were verified with npm in an empty project on August 9, 2026.

npm ls wrangler miniflare undici
npm install --save-dev --save-exact wrangler@4.120.0
npm ls wrangler miniflare undici
npm audit

The verified dependency tree was:

wrangler@4.120.0
└─ miniflare@5.20260801.1-alpha
   └─ undici@7.29.0

The published Wrangler 4.120.0 manifest pins that Miniflare release, and the published Miniflare manifest pins undici 7.29.0. The isolated install reported zero vulnerabilities. Your repository can still have findings from other packages, so inspect the full audit result instead of expecting the same total.

Confirm that this is your dependency path

The original Cloudflare issue showed this exact chain and an npm audit range of undici versions below 7.29.0. A second developer reported that the same warning blocked a production CI pipeline. Run npm ls before changing anything so you can tell whether your result has the same owner.

npm ls undici
npm explain undici

Read the tree from the bottom up. If undici is below 7.29.0 and its parents are Miniflare and Wrangler, update Wrangler. If another package owns a second undici copy, upgrading Wrangler will not remove that separate path. Fix each path through the nearest direct dependency you control.

In a workspace, run the command from the package that declares Wrangler. Running it only at the repository root can hide which app owns the lockfile entry. After the update, review both package.json and the lockfile. A changed manifest with an unchanged frozen lockfile will still fail CI.

Why npm audit fix could not solve it

npm audit reports vulnerable packages from the installed dependency graph. Its fix command applies compatible updates when the graph permits them, as described in the npm audit documentation. It cannot select a different transitive version when the parent package pins one exact version outside the patched range.

That was the important constraint here. Updating undici directly would not change the copy owned by Miniflare unless your package manager forced a resolution. Updating Wrangler changes the parent chain at its supported boundary, which is easier to review and less likely to break Miniflare's assumptions.

Cloudflare merged workers-sdk pull request #15013 to move Miniflare from undici 7.28.0 to 7.29.0. The pull request closed the reported issue, so a transitive override is now unnecessary for this path.

What the advisory means for a Worker

Five undici security advisories published on July 29, 2026 set 7.29.0 as the patched release for the 7.x line. They cover separate behavior in request bodies, cache parsing, retries, and cookies. One high-severity advisory applies to degenerate private cache directives and lists versions from 7.0.0 through versions below 7.29.0 as affected. The undici advisory list contains the other four notices.

Do not turn that severity label into a claim that your deployed Worker is exploitable. In the Cloudflare issue, a maintainer stated that this undici copy is used by Miniflare and other local development or testing tools, not bundled into deployed Workers. That narrows the reported runtime exposure, but it does not make a stale development dependency or a blocked audit gate worth keeping.

Treat two questions separately: where can the affected code execute, and does the repository still resolve an affected version? The first decides urgency and test scope. The second is answered by the lockfile and npm ls. Updating the supported top-level tool resolves the second question without pretending the first is identical for every project.

Upgrade without weakening CI

Make the update as a dependency-only change. That keeps the audit result and any Wrangler behavior change easy to attribute.

  • Pin the reviewed Wrangler version in devDependencies.
  • Regenerate the lockfile with the same npm major version used in CI.
  • Confirm that no Miniflare-owned undici version below 7.29.0 remains.
  • Run the repository's normal tests and a local Worker start.
  • Run npm audit again and save the remaining findings, if any, by dependency path.
npm ci
npm ls wrangler miniflare undici
npx wrangler dev
npm audit

The local start is not a security proof. It checks that the toolchain can load your Worker, bindings, and compatibility settings after the Miniflare change. Exercise the local routes and bindings your project actually uses, then stop the process and run the normal test suite.

What not to do

Do not suppress every audit failure

Turning off npm audit in CI removes the signal for unrelated production dependencies too. If policy permits a temporary exception, scope it to the exact advisory, owner, and expiry date. In this case the upstream fix is released, so suppression should not be the default response.

Do not use npm audit fix --force as a first step

The force option can install changes outside declared dependency ranges. That expands the review from one supported Wrangler update to an unknown set of graph changes. Read the proposed changes first, then update the direct package intentionally.

Do not keep a permanent undici override

An override can be a temporary control when the owning package has not released a fix. Our Next.js sharp audit guide covers a case where an override also required deployment-runtime testing. Wrangler has now moved its dependency, so prefer the supported graph and remove any emergency override after confirming the lockfile.

If Wrangler 4.120.0 is not an option

First find the actual constraint. A plugin, internal preset, Node.js policy, or repository-wide version pin may prevent the update. Record that owner and test a small branch with the new Wrangler version. Do not assume the alpha label on Miniflare makes the release accidental: Wrangler's published manifest pins that exact Miniflare version.

If you must defer the Wrangler update, document the known local-tooling path from the Cloudflare issue, keep the audit visible, and set a short review date. A direct undici override is a last resort because it asks Miniflare to run with a version its installed manifest did not select. If you use one temporarily, test Wrangler dev, local bindings, and the repository's Miniflare-based tests.

Final verification

The change is complete only when the committed lockfile proves the patched path and CI repeats the result. A useful review note includes the old tree, the new tree, the upstream fix link, and the commands run.

Before:
wrangler@4.118.0
└─ miniflare@4.20260730.0
   └─ undici@7.28.0

After:
wrangler@4.120.0
└─ miniflare@5.20260801.1-alpha
   └─ undici@7.29.0

If npm audit still reports undici after this update, do not reopen the same fix blindly. Run npm explain undici again. A second parent package, a stale workspace lockfile, or an install performed from the wrong directory is a different problem with a different owner.