CVE-2026-27606

What it actually does

This vulnerability is an arbitrary file write caused by insufficient path sanitization in Rollup output filename handling. An attacker who can influence Rollup build inputs, named CLI inputs, manual chunk aliases, output names, or plugin-generated file names can include path traversal sequences such as ../ to make Rollup write outside the intended build output directory. The write occurs with the privileges of the build process, so impact depends on where Rollup is executed and what that process can modify. In CI/CD, developer workstations, or build servers, this can overwrite source files, package metadata, shell startup files, scheduled task definitions, service files, deployment artifacts, or other configuration files. If a written file is later executed or loaded, the issue can become persistent remote code execution through the build pipeline or affected host.

Why it matters to the business

Successful exploitation can compromise software build integrity and turn a normal JavaScript build process into a mechanism for overwriting sensitive files. This can lead to poisoned application releases, theft or manipulation of build outputs, persistent compromise of developer or CI systems, and downstream distribution of malicious code. The CVSS score is critical and public exploit capability is reported, but the issue is not currently listed in CISA KEV and EPSS is relatively low, so prioritization should focus first on internet-connected, automated, multi-tenant, or untrusted-code build environments. Because Rollup is widely used in JavaScript supply chains, affected dependencies may be present indirectly through frameworks, plugins, templates, and build tooling even when Rollup is not intentionally installed as a top-level package.

How an attack unfolds

An attacker first needs a path to influence a Rollup build. Common opportunities include submitting a malicious project, dependency, plugin, build configuration, pull request, package update, or command-line input that is processed by an automated build job or developer. The attacker sets a Rollup-controlled filename field to include traversal components such as ../ so that the resolved output path escapes the configured output directory. During the build, vulnerable Rollup versions fail to properly constrain the final write path and create or overwrite the attacker-selected file wherever the build process has permission. The attacker then targets files that will be read or executed later, such as application source files, package lifecycle scripts, shell configuration files, CI configuration, deployment artifacts, or service/task definitions. Persistence or code execution occurs when a developer shell, CI job, deployment step, runtime process, or package manager later loads the overwritten file.

How to fix it

Upgrade Rollup to a fixed release for the branch in use: 2.80.0 or later for 2.x, 3.30.0 or later for 3.x, and 4.59.0 or later for 4.x. If consuming Rollup directly from source, update to a revision that includes commit d17ae15336a45c3c59b2a4aacac2b14186035d28 or later. Regenerate lockfiles after upgrading and verify that transitive dependency resolution does not retain an affected Rollup version. Where immediate upgrade is not possible, restrict who can modify Rollup configuration, plugins, package scripts, and CI build inputs; run builds in isolated containers or sandboxes with least-privilege filesystem permissions; prevent build jobs from writing to user home directories, system paths, and shared deployment locations; and add policy checks that reject output filenames or chunk names containing path traversal sequences, absolute paths, or encoded traversal variants. Treat builds of untrusted pull requests, third-party packages, or external plugins as high risk until the upgrade is complete.

How to confirm the fix worked

Confirm the installed Rollup version with package manager inventory and lockfile review, checking package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, and generated software bills of materials. Validate that all resolved Rollup instances are at 2.80.0+, 3.30.0+, or 4.59.0+ as applicable, or that source builds include commit d17ae15336a45c3c59b2a4aacac2b14186035d28 or later. Run dependency scanners across application and build-tool repositories, including transitive dependencies. Review Rollup configuration and custom plugins for filename, chunk, asset, and output values that can be influenced by untrusted input. In CI/CD, confirm build jobs execute with restricted working directories and cannot write to sensitive filesystem locations. As a safe functional validation, use a non-production sandbox to verify that Rollup no longer emits files outside the configured output directory when given traversal-style names.

Typical attack path

1. Identify a repository, package, plugin, or build workflow that uses a vulnerable Rollup version before 2.80.0, 3.30.0, or 4.59.0.
2. Gain the ability to influence Rollup inputs, output names, manual chunk aliases, plugin-generated asset names, or build configuration.
3. Insert path traversal sequences such as ../ into a filename value that Rollup will use for emitted files or chunks.
4. Trigger the Rollup build locally, in CI/CD, or in another automated packaging environment.
5. Cause Rollup to write outside the intended output directory and overwrite a file accessible to the build process.
6. Choose a target file that is later executed, imported, sourced, deployed, or trusted by another process.
7. Leverage the overwritten file for persistence, build artifact tampering, credential access, or code execution.

How to detect it

Investigate whether Rollup builds wrote files outside their expected output directories. Relevant sources include CI/CD job logs, build runner filesystem audit logs, endpoint detection telemetry, process command-line history, shell history, package manager logs, source-control diffs, artifact manifests, container filesystem layer changes, and file integrity monitoring alerts. Look for Rollup commands or configuration values containing traversal sequences, absolute paths in output-related fields, suspicious manual chunk names, unusual plugin-generated asset names, or build outputs created in parent directories. On build hosts, review recently modified files outside workspace and dist/build directories around Rollup execution times, especially shell startup files, package metadata, CI configuration, deployment scripts, service definitions, cron entries, SSH authorized_keys files, and application files that are later executed. Correlate process execution where node, npm, yarn, pnpm, npx, or rollup is followed by unexpected file writes to sensitive locations. For suspected compromise, compare artifacts against clean rebuilds from patched Rollup, review dependency/plugin changes immediately preceding the event, and rotate any secrets accessible to the build process.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e/
• ..%2f
• ..%5c
• rollup -c
• node_modules/.bin/rollup
• node_modules/rollup
• manualChunks
• chunkFileNames
• assetFileNames
• entryFileNames
• output.file
• output.dir
• this.emitFile
• fileName: '../
• fileName: "../
• name: '../
• name: "../
• created ../
• created ..\\
• dist/../
• build/../
• package.json modified during Rollup build
• package-lock.json modified during Rollup build
• yarn.lock modified during Rollup build
• pnpm-lock.yaml modified during Rollup build
• ~/.bashrc
• ~/.profile
• ~/.zshrc
• ~/.ssh/authorized_keys
• /etc/cron.d/
• /etc/systemd/system/

What your security team should do

• Inventory all repositories, build images, CI jobs, developer tooling baselines, and package templates that include Rollup directly or transitively.
• Prioritize remediation for CI/CD runners, release pipelines, package publishing workflows, automated builds of untrusted pull requests, and environments that build third-party or user-supplied JavaScript.
• Upgrade Rollup to 2.80.0+, 3.30.0+, or 4.59.0+ and refresh lockfiles to remove vulnerable transitive copies.
• Temporarily block or quarantine builds that use untrusted Rollup plugins, externally supplied Rollup configuration, or filename/chunk naming patterns containing ../, ..\\, absolute paths, or encoded traversal sequences.
• Run builds in ephemeral, least-privilege containers with read-only source mounts where feasible and tightly scoped writable output directories.
• Search build logs, repository history, package scripts, and CI artifacts for suspicious traversal patterns in Rollup-related commands and configuration.
• Review recent build outputs and deployment artifacts for unexpected modifications outside normal output directories, especially around the first use of any new plugin or dependency update.
• If suspicious writes are found, rotate credentials available to the affected build job and rebuild release artifacts from a known-clean environment.