No. Cloudflare regularly updates the Workers runtime, but your Worker is bundled before upload, so the npm packages inside it stay at the versions you built. A runtime update does not change a vulnerable library in your bundle. You fix that by rebuilding and redeploying.
Two layers, two owners
A Worker has a platform layer and an application layer.
| Layer | What it contains | Who updates it |
|---|---|---|
| Runtime | The Workers runtime that executes your code | Cloudflare |
| Bundle | Your code plus every npm package Wrangler bundled in | You |
Cloudflare documents that Wrangler bundles your Worker code with esbuild by default, importing modules from npm that are defined in your package.json. After bundling, the packages are part of one uploaded artifact. Nothing on the platform side rewrites them.
What a runtime update looks like
Cloudflare's limits page describes routine runtime updates. Processes running the previous runtime version give existing requests and connections up to 20 minutes to finish, and the updated version handles new incoming HTTP requests. The page tells you to design long-running applications to handle disconnections and retry interrupted work.
That is a platform concern about request draining. It says nothing about your dependency tree.
What this means for patching
If an advisory lands for a package you bundle, the fix path has five steps:
- Confirm the package and version in your lockfile.
- Update to the patched release and regenerate the lockfile.
- Build and deploy again so a new bundle is uploaded.
- Check that the deployed bundle contains the new version (see how to inspect what your Worker deploys).
- Confirm the old version is no longer serving traffic.
Until step 3 runs, the old code keeps serving, however many times the platform updates underneath it.
One more thing that does change under you
Cloudflare also notes it periodically updates the esbuild version included with Wrangler, and that because esbuild is pre-1.0.0 this can sometimes mean breaking changes to how bundling works, possibly in a Wrangler minor version. That affects your build tool, not the platform. Pin the Wrangler version in your repo and update it on purpose, with a test deploy, rather than letting a fresh install pick a new one.
A quick audit you can run today
- List every Worker in your account and its repo.
- For each repo, check the date of the last lockfile change.
- Flag any Worker whose lockfile has not changed in six months and ask whether that is a choice or an oversight. Six months is a rule of thumb, not a standard.
- Record the Wrangler version used to build it.
Try it yourself
Continuous monitoring is what catches an advisory after a clean deploy. Open the demo and watch a finding appear on a project that passed a scan earlier.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans your repo's dependencies and keeps watching them, so a new advisory against a package in a deployed Worker's lockfile surfaces without a fresh build. Autonomous remediation can propose a fix pull request, off by default with every category on Manual. Free scan: gold.safeguard.sh/scan.
Quick check
Does a Workers runtime update fix a vulnerable npm package in my Worker?
No. The package is inside the bundle you uploaded. You must update it, rebuild and redeploy.
Will a runtime update drop my in-flight requests?
Cloudflare documents a grace period of up to 20 minutes for existing requests and connections, but says crashes, resource pressure and shutdowns can interrupt work earlier, so design for retries.
Sources
Last reviewed: 19 October 2026.
