A fresh npm supply chain attack traced to North Korea’s Lazarus group has been unpicked by researchers at JFrog. Six malicious packages sat in the open registry for days, disguised as ordinary build tools. Anyone who pulled them into a project handed over browser passwords, cloud keys and crypto wallet data without realising it.
Table of Contents
Why this npm supply chain attack worked
The two lead packages, “rollup-packages-polyfill-core” and “rollup-runtime-polyfill-core”, copied the name and description of a real, widely used project called rollup-plugin-polyfill-node. That project pulls around 295,000 downloads a week, so the copy looked entirely plausible. Same naming pattern. Same stated purpose. A developer scanning a dependency list quickly would have no reason to stop and look twice.
Once installed, the packages quietly pulled in four more: swift-parse-stream, quirky-token, react-icon-svgs and rollup-plugin-polyfill-connect. JFrog found the install commands hidden in base64-encoded text. They triggered automatically the moment the package loaded, before anyone had run a line of their own code.
The chain didn’t stop there. The secondary packages, dressed up as SVG utilities, fetched a JSON file from a public paste-style hosting service and ran the code inside it. That code then downloaded an encrypted loader from a remote server and decrypted it locally. The resulting payload checked first whether it was running inside a sandbox, a cloud IDE or a CI runner. If the coast looked clear, it deployed in full.
What the malware went after
The final payload was thorough. Saved credentials from Chrome, Edge, Brave and Opera were an early target. MetaMask and other crypto wallet extensions were hunted down by their exact browser extension IDs. Developer machines were searched for SSH keys, AWS and Azure credentials, npm tokens and Git logins. Editor history was read straight out of VS Code, Cursor and Windsurf, and anything sitting in a project’s .env file was fair game too.
A clipboard monitor ran in the background, capturing anything a developer copied: tokens, wallet addresses, seed phrases. On compromised Windows machines, the malware could also open an interactive remote terminal and take control of the mouse and keyboard. JFrog says that capability closely resembles the earlier North Korean OtterCookie malware family.
Why researchers point to Lazarus
JFrog stops short of claiming certainty. But the layered package structure, the lookalike naming and the hidden install-time execution all line up with past Lazarus-linked npm campaigns, the firm says. So does the credential-theft payload. A separate operation uncovered in April involved 108 malicious packages across 261 versions. Researchers believe it came from the same broader group. This is not an isolated stunt. It is one entry in an ongoing pattern that has also included a self-replicating npm worm compromising well over a hundred packages in a single wave.
All six packages have since been pulled from the registry. That only closes the door after the fact, though. Anyone who installed them between publication and takedown was exposed for that entire window. Removal from npm does nothing to undo a theft that already happened.
This npm supply chain attack did not arrive in isolation either. Around the same period, researchers separately disclosed trojanised forks of a popular Python messaging library and a wave of fake DeFi trading packages. A scoped npm campaign built around cloud credential harvesting turned up too. Different targets, same underlying playbook: earn a place in someone’s dependency tree, then abuse the access that comes with it.
What this means for your business
Most UK businesses do not write every line of the software they run. Modern applications lean on hundreds of open source packages, and each one is effectively a supplier you have never vetted. This npm supply chain attack shows how little it takes for that trust to be misplaced. A convincing name, a copied description and a download count that looks healthy were enough.
If your developers or contractors work with Node.js tooling, ask a few direct questions. Does dependency scanning run automatically on every build? Are install scripts restricted where possible? Are the credentials used in CI pipelines short-lived, rather than sitting in a config file indefinitely? None of that requires ripping out your build process. It requires treating third-party code the way you would treat a new supplier. Check it before you trust it, and limit what it can reach in case that trust turns out to be misplaced.
Few businesses will ever hear the name of the specific package involved in their own close call. What matters is having a process that would catch one regardless of what it is called. That is the real defence against the next npm supply chain attack, not just this one.
Subscribe to our newsletter for a weekly round up of what's happening in the cyber security world
