CVE-2026-27606 is a critical path traversal (CVSS 9.8) in the Rollup JavaScript bundler. Crafted output file names can write files anywhere the build user can write. Upgrade to Rollup 4.59.0, 3.30.0 or 2.80.0, or later, and check which tools in your build pull Rollup in.
What's affected
The record says Rollup versions before 2.80.0, 3.30.0 and 4.59.0 are vulnerable, with the fixes released in those three versions. By line:
- 4.x before 4.59.0
- 3.x before 3.30.0
- 2.x before 2.80.0
The record says an attacker needs to control output file names. It names three routes: CLI named inputs, manual chunk aliases and malicious plugins. That makes the risk highest where a build takes untrusted configuration, untrusted input names or third party plugins, such as shared CI runners and tools that build user supplied projects.
Rollup is also an indirect dependency of many frontend tools, including some dev servers and bundlers, so your direct dependency list may not mention it. The KEV flag is false.
How to check if you're exposed
Look for every copy of Rollup in your dependency tree, not just the one in package.json.
npm ls rollup --all
npm why rollup
# pnpm
pnpm why rollup
# yarn
yarn why rollup
Check both application repositories and CI images. A global install on a build machine counts too.
npm ls -g rollup
rollup --version
Match each version against the three fixed lines. You can also paste your lockfile or manifest into the free in-browser dependency scan for a quick answer.
What to do now
- Upgrade Rollup to 4.59.0, 3.30.0 or 2.80.0, or later, matching your major line.
- For indirect copies, update the parent tool first. If that does not pick up a fixed Rollup, use your package manager override feature.
- Rebuild lockfiles and confirm with
npm ls rollup --all. - Run builds that handle untrusted input or third party plugins with a low privilege user, in a container, with a read only file system outside the output directory.
- Review plugin lists and remove plugins you cannot vouch for.
- Check build machines for unexpected changes to shell startup files and tool configuration.
Why it matters
This is CWE-22, path traversal. The core engine sanitises output file names, but the record says the sanitisation is insecure, so a name containing parent directory segments leaves the intended output folder. Whatever the build process is allowed to write, an attacker influenced name can overwrite.
The record spells out the consequence. Overwriting shell profiles, tool configuration or similar files can turn an arbitrary file write into persistent code execution. Build tooling is a juicy target because it often runs with access to deploy keys and tokens.
The 4.59.0 release notes describe the new behaviour plainly: the build throws when the generated bundle contains paths that would leave the output directory. Failing loudly beats rewriting silently.
The broader point is that your supply chain includes the tools that make your software, not only the libraries you ship. A reachability style view of which packages sit in the build path and which in the runtime path helps you rank this one correctly.
What the record says about the entry points
The description names three ways to control output file names. Command line named inputs are the simplest: a build script that passes names from outside the repository. Manual chunk aliases are names produced by configuration. Malicious plugins can set names directly. Each one needs some influence over the build, so the usual question is who can change your build inputs. On a developer laptop building your own code, the answer is mostly you. On a shared CI service building pull requests from forks, the answer can be anyone.
Build isolation worth having anyway
A bundler writes files, so give it a place to do that safely.
- Run builds in a throwaway container or virtual machine per job, with no persistent home directory.
- Do not mount deploy keys, cloud credentials or package registry tokens into steps that run untrusted code. Give them only to the later publish step.
- Make the checkout writable only where the build must write, and the rest read only.
- Pin plugin versions and review plugin updates like any other code change.
- Keep a record of build tool versions per project so you can answer which repositories use an affected Rollup within minutes.
That last point is where an inventory pays off. Rollup is frequently pulled in by other tools, so the version that matters is often the one three levels down. Generating a software bill of materials for each project, and searching it by package name, turns a half day investigation into a query.
After you upgrade
Rebuild your lockfiles, run a clean install in CI, and confirm with npm ls rollup --all that no older copy remains. Watch for build failures from the new check that throws when generated paths would leave the output directory. Such a failure is the new protection working, and it tells you something in your configuration produces suspicious output names.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect the code I ship to users?
Not directly. The flaw is in the build tool, so the risk is to the machine that runs the build and to anything that machine can reach.
Sources
Last reviewed: 19 October 2026.
