Installing npm rollup is safe for most projects today, but if you are on an older major line you should know about CVE-2024-47068, a DOM clobbering bug that can turn bundled output into a cross-site scripting vector. Rollup is one of the most widely used JavaScript module bundlers, sitting under Vite and many library build pipelines, so its security posture ripples out to thousands of downstream apps.
This post reviews what you actually pull in when you run npm install rollup, the one vulnerability worth understanding, and how to use the bundler without inheriting avoidable risk.
What you get when you install rollup from npm
Rollup is a build-time tool. It reads your ES module graph, tree-shakes dead code, and emits bundles in formats like ESM, CommonJS, UMD, and IIFE. Because it runs during your build rather than at runtime, its direct attack surface in production is smaller than a framework you ship to the browser. That said, the output rollup generates does run in the browser, and that is exactly where the interesting security question lives.
The package itself has a small dependency footprint. Modern rollup ships native binaries per platform (the @rollup/rollup-* optional dependencies), which is worth noting if you audit your lockfile and see platform-specific packages appear. Those are expected.
The vulnerability worth knowing: CVE-2024-47068
The one advisory that matters for rollup npm users is CVE-2024-47068, a DOM clobbering gadget in rollup's generated code. It affects bundles produced in cjs, umd, or iife formats when your code references properties from import.meta (such as import.meta.url), or when a plugin emits and references asset files.
DOM clobbering is a subtle attack. If an attacker can inject scriptless HTML into a page (for example, an img tag with a crafted name attribute), they can override what document.currentScript resolves to. Rollup's generated shim read properties off that value without confirming it was actually a script element, so a clobbered reference could redirect asset loading toward an attacker-controlled URL and lead to XSS.
The fix landed in rollup 2.79.2, 3.29.5, and 4.22.4. Any version at or above those on your major line is patched. The remediation in rollup's own code was straightforward defensive typing: verify that document.currentScript.tagName.toUpperCase() === 'SCRIPT' before trusting it.
How to check what you are running
Start by asking npm what resolved into your tree:
npm ls rollup
If you see rollup nested under Vite or another tool, that is normal. Compare the resolved version against the patched floors above. To force a safe minimum without waiting on your framework to bump, use an override in package.json:
{
"overrides": {
"rollup": ">=4.22.4"
}
}
Then reinstall and re-run npm audit. An SCA tool such as Safeguard can flag a vulnerable rollup transitively even when it is buried three levels deep under a build dependency, which is the case where a manual npm ls is easy to misread.
Safe usage patterns for rollup npm projects
A few habits keep rollup from becoming a liability:
Pin and commit your lockfile. Rollup is a build dependency, and build dependencies are a prime supply chain target. A committed package-lock.json means every CI run and every teammate resolves the exact same rollup version and native binary, not whatever floats to the top on install day.
Prefer ESM output where you can. The CVE-2024-47068 gadget lived in the cjs/umd/iife code paths. Modern browsers and bundler chains handle native ES modules well, and ESM output sidesteps the specific shim that was affected. This is not a security guarantee, but it reduces the surface.
Audit rollup plugins as first-class dependencies. Most real rollup risk comes not from rollup itself but from the plugin ecosystem. A plugin runs with full access to your source and your build environment. Treat rollup-plugin-* and @rollup/plugin-* packages with the same scrutiny you would give any code that touches your CI secrets. Check the maintainer, the release cadence, and whether the plugin has recent commits.
Wire rollup into your dependency scanning. Build tools change slowly, so it is easy to forget them between audits. Make sure your software composition analysis covers devDependencies, not just runtime packages, because rollup lives there.
Rollup versus the alternatives, security-wise
Teams sometimes ask whether switching bundlers improves security. It usually does not in a meaningful way. esbuild, Vite (which uses rollup), and webpack have all shipped security fixes over the years; no bundler is vulnerability-free. What matters more is whether you keep your bundler current and whether you scan the plugins you bolt onto it. A well-maintained rollup on a patched version is a perfectly reasonable choice.
If you are evaluating tooling broadly, the Safeguard academy has material on how build-time dependencies factor into supply chain risk, which applies regardless of which bundler you land on.
FAQ
Is npm rollup safe to use in production?
Yes, with the caveat that you should be on a patched version: rollup 4.22.4, 3.29.5, or 2.79.2 or later. Older versions carry the CVE-2024-47068 DOM clobbering issue in certain output formats. Rollup runs at build time, so keeping it current and scanning your plugins matters more than the bundler choice itself.
What is CVE-2024-47068 in rollup?
It is a DOM clobbering vulnerability in rollup's generated code for cjs, umd, and iife bundles that reference import.meta properties. An attacker who can inject scriptless HTML into a page could hijack asset loading and achieve XSS. It was fixed in rollup 2.79.2, 3.29.5, and 4.22.4.
How do I update rollup when it is a transitive dependency?
Use an overrides block in package.json to force a minimum version (for example "rollup": ">=4.22.4"), then reinstall. This bumps rollup even when it is pulled in by Vite or another parent package that has not yet updated its own pin.
Does the rollup vulnerability affect my build machine or my users?
Your users. The DOM clobbering gadget lives in the JavaScript rollup emits, which executes in the browser. Your build machine is not directly at risk from this specific CVE, though build tooling is always worth protecting because it has access to your source and CI secrets.