Rollup plugin imports can trigger npm malware beyond install-time checks

At a glance

What this is: Malicious npm packages posing as Rollup polyfill tooling moved execution to CommonJS import time, letting build-tool imports trigger remote payload delivery and host compromise.

Why it matters: IAM, NHI, and platform teams need to treat build-time imports as an execution boundary because CI runners and developer workstations can expose cloud credentials, SSH keys, and other secrets when a plugin loads.

Context

Rollup plugins are not just build helpers when they execute inside Node-based toolchains. In this case, the security gap is that many controls focus on install-time script blocking, while trusted config imports can still execute package code later in the build path.

The identity angle is real because the impacted hosts exposed cloud credentials, SSH keys, browser data, and AI-assistant configuration directories to Node.js processes. That makes this a supply-chain and NHI governance issue, not only a package hygiene problem.

The starting position is increasingly typical for modern JavaScript build environments: shared config, transitive plugin imports, and permissive developer workspaces create a wide execution surface for malicious dependencies.

Key questions

Q: What breaks when trusted build imports can execute npm malware?

A: Lifecycle-script blocking is no longer enough because the malicious code runs when a plugin is imported, not only when a package is installed. That means dependency resolution, config loading, and build startup can all become execution points. Teams need to treat imported build plugins as code that can reach the network and the local secret store.

Q: Why do malicious build-tool plugins create credential theft risk?

A: They run inside developer and CI contexts that already have access to cloud credentials, SSH keys, browser sessions, and other authenticators. Once the package executes, it can collect those secrets without needing to break the host boundary first. The risk is highest where shared configs and trusted imports are allowed to execute automatically.

Q: What are the signs that a dependency is staging remote payloads?

A: Look for packages that fetch JavaScript from remote services, use eval, spawn secondary installs, or hide the real payload outside the tarball. Mutable remote content and silent error handling are strong indicators that the package is acting as a loader rather than a normal library. That pattern deserves immediate triage.

Q: How should organisations respond when malicious code has already run in a build or developer environment?

A: Contain the endpoint, revoke the exposed secrets, and check for follow-on compromise in repositories and cloud accounts. Uninstalling the package is not sufficient if persistence, exfiltration, or secondary payloads were already established. Response has to cover the host, the identities it touched, and any downstream systems those identities can reach.

Technical breakdown

CommonJS plugin import as the execution boundary

The key technical shift is that the malicious code does not need a postinstall hook to run. In Node.js, a package can execute when a build tool imports its CommonJS entrypoint through require(), which means plugin resolution itself becomes the trigger. That matters because many security teams only monitor package installation and lifecycle scripts. If a package presents a legitimate ESM path but hides a backdoor in dist/index.js, the code can still execute inside the same trust boundary as Rollup or Vite configuration.

Practical implication: Treat build-tool import paths as executable surfaces and review plugin loading the same way you review script execution.

Second-stage staging through remote content and eval

The reported chain uses a small npm package as a loader, then pulls additional JavaScript from a remote content store and executes it with eval(). This design decouples the published package from the real payload, so the attacker can change behavior after publication without republishing the tarball. It also suppresses the visibility that defenders often rely on, because the malicious logic lives outside the initial package and can be fetched conditionally. That is a supply-chain staging pattern, not a simple dependency typo.

Practical implication: Inspect packages for outbound fetches, remote script execution, and mutable content sources before allowing them in build pipelines.

Developer secrets exposure after code execution

Once the payload runs, the threat shifts from package abuse to host compromise. The published analysis describes collection from browser profiles, wallet storage, SSH material, cloud credential locations, shell history, and AI-assistant configuration directories. That is a broad developer-environment target set, which explains why the incident matters to identity teams as well as application security teams. The malware is not just stealing files; it is harvesting the secrets that authenticate humans, workloads, and developer tooling across later workflows.

Practical implication: Assume exposed developer workstations and CI runners can leak both human and non-human credentials when build-time code execution occurs.

Threat narrative

Attacker objective: The attacker aims to turn trusted build-tool execution into persistent access to developer and CI environments while collecting credentials and enabling remote control.

1. Entry occurred when a malicious Rollup-themed npm package was imported through a CommonJS plugin path during normal build or config resolution.
2. Credential and payload staging followed when the loader invoked a second-stage package install and fetched additional JavaScript from a remote content store for eval().
3. Escalation continued when the decrypted payload launched interactive tooling, process control, and data collection routines on the host.
4. Impact was developer workstation and CI runner compromise with broad exposure of secrets, browser data, cloud credentials, and remote access capability.

Breaches seen in the wild

• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Import-time execution is the governance blind spot: organisations that only harden npm lifecycle scripts are protecting the wrong boundary. When a plugin executes on require(), the build system itself becomes the execution surface, and that changes how dependency risk should be classified. Practitioner conclusion: review trusted import paths as privileged code paths, not just package metadata.

Build tooling now behaves like an identity-bearing runtime: Rollup, Vite, and adjacent Node-based flows can load code that immediately reaches secrets, cloud APIs, and developer state. That makes build configurations part of the identity attack surface because they can expose both human and non-human credentials. Practitioner conclusion: include build runners and developer config imports in identity threat modelling.

Secret harvesters are targeting developer context, not just source code: the published collection scope reaches browsers, SSH, cloud credentials, wallet stores, and AI-assistant directories. That is a clearer sign of operational compromise than routine supply-chain noise. Practitioner conclusion: secrets governance must extend to workstations and CI hosts, not stop at the repository.

Rollup polyfill impersonation is a trust-proxy attack: the malware succeeds by borrowing the look and metadata of a legitimate ecosystem package while shifting payload delivery elsewhere. That is a named concept worth tracking because it combines brand mimicry, delayed execution, and remote staging into one pattern. Practitioner conclusion: validate dependency identity and execution behavior separately.

NHI controls need to cover build-originated credential exposure: the incident shows that machine and developer credentials can be compromised through ordinary package resolution, not only through direct vault attacks. The right control question is where credentials are usable, not just where they are stored. Practitioner conclusion: connect package governance with NHI inventory and secret-scanning workflows.

What this signals

Import-path control is now part of supply-chain security: teams that still scope dependency risk to install-time checks are missing a real execution boundary. The practical shift is to govern what a build tool imports with the same care used for what it installs.

Secret exposure follows the execution context, not the package label: if a malicious plugin loads in a CI runner or a developer workstation, the valuable target is the environment state already on that host. That means browser sessions, SSH material, and cloud authenticators belong in the same incident scope as the source tree.

For practitioners

• Audit build-time import paths Map every Rollup, Vite, and Node config import that resolves third-party plugins, then verify whether those imports execute code before the build starts.
• Quarantine suspicious dependency clusters Search lockfiles and package caches for the six package names in the reported chain, then isolate any runner or workstation that loaded them during the exposure window.
• Review host secrets exposure Check browser profiles, SSH material, cloud credential paths, wallet storage, and AI-assistant directories on any host that loaded the plugin entrypoint.
• Treat confirmed execution as compromise Rebuild CI runners and developer images from known-good bases, preserve telemetry and temporary files, and rotate any credential that may have been present on the host.
• Add outbound-code execution detections Alert on packages that fetch remote JavaScript, invoke eval, or spawn secondary installs during dependency resolution or plugin import.

Key takeaways

• The incident shows that malicious npm packages can weaponise build-tool imports, not just lifecycle scripts, which expands the execution surface inside trusted development workflows.
• The reported chain reaches far beyond a single package tarball because remote content, secondary installs, and eval-based loaders let the attacker change payloads after publication.
• The limiting control is host and import-path governance, plus rapid credential rotation and runner rebuilds when a plugin import is confirmed.

Key terms

• Import-time execution: Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
• First-stage loader: A first-stage loader is the initial malware component that checks the environment, establishes a foothold, and decides whether to retrieve a more capable payload. It often keeps its behaviour light and selective so it can delay detection until the operator decides to escalate.
• Build-Path Supply Chain Attack: A build-path supply chain attack targets the software construction process rather than the final application release. The attacker abuses plugins, config imports, or package resolution steps so that malicious code executes in developer or CI environments with access to secrets, source, and trusted credentials.
• Developer Secrets Exposure: The risk that workstations and CI hosts used for building software contain reusable credentials such as SSH keys, cloud tokens, registry secrets, or signing material. In supply-chain attacks, these secrets often become the primary target because they unlock later access beyond the initial host.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the build, runtime, and credential paths that real attacks abuse.