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

At a glance

What this is: This is an analysis of six malicious npm packages that hid payloads behind Rollup plugin imports and then expanded into second-stage downloads, secret collection, and remote host control.

Why it matters: It matters because IAM and security teams must treat developer workstations, CI runners, and build configs as identity-bearing trust zones where exposed cloud, SSH, browser, and AI-assistant credentials can be abused.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and they are 13% more likely to be categorised as critical than code-based leaks.

👉 Read Corgea's analysis of Rollup plugin malware and import-time execution

Context

Malicious dependency abuse is no longer limited to install-time scripts. In this case, the real trigger was a CommonJS plugin import inside Rollup-compatible build flows, which let attacker-controlled code execute inside a trusted developer or CI process. That matters because build tooling often has broad reach into secrets, source metadata, cloud credentials, and local AI-assistant configuration directories.

The identity angle is real even though the incident sits in supply chain security. Once a build runner or developer workstation executes untrusted code, that host becomes a proxy identity with access to browser sessions, SSH keys, API tokens, and cloud access paths. The starting position here is increasingly typical for modern development environments, which are rich in standing credentials and poorly scoped process trust.

Key questions

Q: What breaks when malicious npm packages execute on import instead of install?

A: Install-time controls often miss import-time payloads because the malicious code lives in the published bundle and runs when the module loads. That means unit tests, bundlers, dev servers, and CI jobs can all trigger execution before a postinstall safeguard ever matters. Teams need artifact validation and runtime detection, not only script blocking.

Q: What breaks when supply-chain poisoning reaches developer workstations and CI runners?

A: The main failure is assuming a compromised package only affects one project. In practice, developer hosts and CI runners often hold cloud tokens, source access, and signing credentials, so a poisoned dependency can become a broader trust-breach across repositories and deployment paths. Once that happens, traditional package scanning is no longer enough on its own.

Q: How do security teams know whether a dependency compromise reached production?

A: They need to combine SBOM review, lockfile inspection, CI build logs, endpoint telemetry, and outbound network monitoring. A package may appear only briefly in a repository but still run on a laptop or ephemeral runner. If a malicious artefact executed, assume credential exposure and verify hosts before returning them to service.

Q: Who is accountable when a build process loads malicious code and exposes credentials?

A: Accountability usually spans engineering, platform, and security teams because the failure sits at the intersection of dependency governance, secret placement, and host hardening. NIST-style access and audit controls apply to the systems that allowed the process to run with excessive trust.

Technical breakdown

CommonJS import execution in Rollup plugin paths

The key technical shift is that the malicious code does not depend on package-manager lifecycle hooks. Instead, it waits until Node loads the CommonJS entrypoint, which many build tools reach through require() or equivalent plugin wiring. That means a package can look benign at rest, pass a casual repository scan, and still execute when imported during build bootstrap. In practice, the package boundary is less important than the execution boundary created by the host runtime and the build configuration.

Practical implication: inspect build-time import paths with the same suspicion as install scripts, especially in shared Rollup and Vite configs.

Second-stage loading through remote JSON and eval

The staging packages in this chain use a lightweight loader pattern. They fetch JSON from a remote service, parse a model field, and eval() the returned content inside the Node process. That gives the attacker mutable payload control after publish, so the npm tarball is only a delivery wrapper. This design also suppresses some obvious indicators because the real logic lives off-package and can change without a new registry release.

Practical implication: block or monitor remote code retrieval from build processes, not just suspicious package names.

Developer and CI hosts as credential-rich targets

The final payload is aimed at developer and runner environments that contain browser profiles, wallet extensions, clipboard data, cloud credentials, SSH keys, Git metadata, and AI-assistant directories. That broad collection scope turns a build host into a multi-identity compromise point, because the attacker can steal session material and then pivot into cloud, source control, and SaaS access. The most important detail is not malware sophistication alone, but the concentration of reusable secrets on machines that are assumed to be transient and trusted.

Practical implication: treat developer endpoints and runners as high-value identity assets and scope their secrets exposure accordingly.

Threat narrative

Attacker objective: The attacker aims to turn build-time trust into durable access to developer and cloud credentials, then use that access for follow-on intrusion and data theft.

1. Entry occurs when a developer or CI job resolves and imports a malicious Rollup-themed package through a CommonJS plugin path.
2. Credential access expands as the staged payload searches browser profiles, SSH material, cloud keys, and AI-assistant configuration directories on the host.
3. Impact follows when the attacker installs a remote access payload, exfiltrates secrets, and preserves a reusable foothold on the workstation or runner.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build-tool imports are becoming a new credential execution boundary: This incident shows that package-install hardening is necessary but incomplete. The meaningful risk now sits in runtime dependency resolution, where trusted config files can execute attacker code long after the install step has passed. Practitioners should treat plugin loading as an identity event, not just a software event.

Developer workstations and CI runners are proxy identities with oversized blast radius: These hosts often hold browser sessions, cloud tokens, SSH material, and source history in one place. When an attacker reaches the process boundary, they are not just stealing files, they are inheriting the host’s delegated access. That is a classic governance gap in machine identity and secrets management, and it calls for stronger scoping of what these systems may access at runtime.

Remote payload staging makes registry review insufficient on its own: The package tarball, JSON remote loader, and encrypted follow-on stage each carry different parts of the attack. That means package reputation, lockfile review, and signature checks do not fully answer whether code execution is safe. Practitioners need visibility into runtime outbound calls and staged execution chains, because the attack surface now spans registry, network, and local process layers.

Secrets governance must extend beyond repositories into the tools developers actually use: The targeted files include cloud credentials, browser storage, AI-assistant configs, and shell history, which are increasingly outside traditional secret-scanning assumptions. Credential surface sprawl: the real problem is not only how many secrets exist, but how many places can feed them into a compromised process. NHI governance should therefore include developer environment controls, not just repository hygiene.

The response model should shift from package trust to execution containment: This campaign is a reminder that the trust question is not whether a package exists in a lockfile, but whether a build process can execute arbitrary networked code with access to sensitive identity material. The practical conclusion is to restrict what build hosts can reach, what secrets they can mount, and what import paths are permitted in bootstrap flows.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, so discovery without revocation leaves a live attack surface.
• From our research: Review Guide to the Secret Sprawl Challenge for the operational controls that reduce hidden credential exposure across developer and CI environments.

What this signals

The immediate signal for practitioners is that secret exposure is increasingly a runtime problem, not just a repository problem. Build systems, local config, and CI runners now deserve the same governance attention as production workloads because they often hold the credentials that attackers want first.

Credential surface sprawl: the more identity material is distributed across developer tools, browser storage, and AI assistants, the more likely a single imported package can turn into multi-system compromise. That argues for stricter process containment, narrower secret scope, and faster revocation paths across the full development estate.

If your programme still assumes npm package risk begins and ends at install time, this incident should change the control conversation. The next layer is execution-aware dependency governance, where outbound calls, import paths, and secret locality are all part of the review model.

For practitioners

• Restrict build-time import paths Inventory Rollup, Vite, and shared config files for plugin imports that execute during bootstrap, then block unknown or newly added packages from loading in trusted build paths.
• Scope secrets out of runner workspaces Remove cloud keys, SSH material, browser profiles, and AI-assistant directories from developer and CI environments unless the job explicitly needs them, and mount them only for the shortest possible runtime.
• Monitor outbound network calls from build processes Alert on package installs, JSON fetches, and unexpected process spawning from Node-based build jobs, especially requests to unfamiliar domains or direct IP addresses.
• Treat import-time code execution as a compromise indicator If a confirmed host imported one of the malicious packages, rebuild the runner or workstation from a known-good base, then rotate credentials exposed to that host before reuse.

Key takeaways

• Build-tool imports can be as dangerous as install-time scripts when malicious packages execute inside trusted Node processes.
• The exposed asset is not just source code, but the host’s delegated identity material, including cloud, SSH, browser, and AI-assistant secrets.
• The practical defence is execution-aware dependency governance plus tighter secret scoping on developer and CI systems.

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.
• Identity Surface Sprawl: Identity surface sprawl happens when authentication, provisioning, authorization, and audit are split across multiple tools that do not share one governance model. The result is duplicated policy, inconsistent evidence, and more places for access drift to hide.
• Staged Payload Delivery: A delivery pattern where an initial lure or loader fetches later stages from external infrastructure instead of delivering the full malware at once. This reduces visibility for perimeter tools and allows the attacker to swap components, evade detection, and tailor the final payload to the target environment.
• Build-Path Trust Boundary: The line between ordinary dependency loading and privileged execution during builds, tests, or local configuration startup. When teams treat this boundary as safe by default, malicious packages can inherit the same access as legitimate tooling and abuse it for secret theft or persistence.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• Package-level indicators and registry-state clues that help separate benign history from malicious release activity
• The full import-path and payload chain, including the remote JSON loader and encrypted follow-on stage
• Host-level hunting guidance for browser profiles, shell history, cloud keys, and AI-assistant directories
• Detection examples for identifying whether a developer or runner actually executed the malicious plugin

👉 The full Corgea post covers the package chain, loader behavior, and response guidance in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security and identity practitioners a common framework for reducing delegated access risk across developer and runtime environments.