Four more Rollup polyfill typosquats surface in JFrog's fuller DPRK writeup

The Hacker News writeup of JFrog’s research on this cluster now names six malicious npm packages, not the two that led the initial summary. The additions — rollup-plugin-polyfill-connect, quirky-token, react-icon-svgs, and swift-parse-stream — sit alongside the previously reported rollup-packages-polyfill-core and rollup-runtime-polyfill-core, all attributed by JFrog to the DPRK-linked cluster tracked in prior campaigns under names including Lazarus, BeaverTail, and OtterCookie. The attribution is JFrog’s; we’re relaying it, not asserting it independently.

For our earlier coverage of the two-package version of this story, see Kilobaud’s July 3 piece. For the broader ecosystem picture — 108 packages across npm, Packagist, Go, and Chrome — see Fuse on PolinRider.

What’s actually different in this update

The infrastructure of the attack didn’t change. The IOC list did.

Two things are worth pulling out of JFrog’s fuller writeup, both mechanical:

The metadata mimicry is not a coincidence. Per THN’s summary of JFrog, all six packages copy the description, repository metadata, and package structure of the legitimate rollup-plugin-polyfill-node project closely enough to pass a casual read of an npm search result. The registry does not verify that the repository a package’s package.json points at is actually the code that got published. It never has. Whatever the search result shows is whatever the publisher typed into the manifest. That’s not a bug in npm; it’s the design.

The capability set is a workstation-takeover kit, not a stealer. JFrog describes credential collection (AWS/Azure keys, SSH keys, npm tokens), developer-tool exfiltration (VS Code, Cursor, Windsurf config), browser data, crypto wallet vaults, and clipboard capture — plus remote input control via a public npm package (@nut-tree-fork/nut-js) and command- and-control over an external server and a JSONKeeper-style channel. Cloud-workload and sandbox checks gate the payload before it runs. This is the machinery of a hands-on-keyboard operation, not a drive-by wallet drainer. For the exact C2 addresses and the per-package install-time behavior, go to JFrog’s writeup directly.

Why the substrate matters more than the count

npm has ~3 million packages. A red team could publish a seventh package tonight and nothing about the registry would notice. The physical layer of a supply-chain attack against JavaScript developers is not the individual malicious package — it’s the registry’s willingness to accept uploaded metadata as descriptive text and hand it to a search ranker without verification. That layer hasn’t changed since the last DPRK package cluster was disclosed, or the one before, or the one before that.

The reason the same shape of story keeps landing is that the substrate underneath it is the same substrate. Six packages this week, two of them covered Friday, 108 across four ecosystems in Fuse’s PolinRider coverage. Same registry behavior, different names on top.

One thing to actually do this week

Turn off install scripts by default in CI. npm ci --ignore-scripts is one flag; yarn install --ignore-scripts is one flag; pnpm has an equivalent. Every one of the campaigns in this cluster — the six disclosed this week, the 108 aggregated as PolinRider, and every prior DPRK-linked drop — leans on install-time execution to get first-stage code onto the developer’s machine before any human reviews anything. Blocking install scripts in CI does not fix the registry. It removes the one hook these operations reliably use.

Provenance attestations catch a different class of problem and are worth adopting on top of that, not as a substitute. But if you only have budget for one change this quarter: --ignore-scripts in CI. Then get back to reviewing the packages your build actually pulls.