Supply Chain Alert: Malicious Rollup Polyfills Spotted in Wild
Just caught wind of the JFrog report regarding the latest supply chain attack targeting the npm ecosystem. It looks like threat actors linked to North Korea (likely utilizing Lazarus group tactics) are at it again, this time impersonating Rollup tooling to snag dev secrets.
The malicious packages—rollup-packages-polyfill-core and rollup-runtime-polyfill-core—are a near-perfect mirror of the legitimate rollup-plugin-polyfill-node. They didn't just stop at similar names; they copied the repository metadata and descriptions to bypass superficial checks.
Once installed, the script attempts to open a reverse shell and exfiltrates sensitive data. This is particularly nasty for CI/CD pipelines where env vars are often available.
Here is a quick check you can run if you suspect a compromise or just want to audit your current environment:
# Check if malicious packages are installed locally
if grep -E "rollup-packages-polyfill-core|rollup-runtime-polyfill-core" package-lock. yarn.lock; then
echo "MALICIOUS PACKAGE DETECTED"
else
echo "Clean (based on lockfile)"
fi
Additionally, verify the integrity of your installed packages against the lockfile hashes to ensure nothing has been tampered with:
npm ci --dry-run --ignore-scripts
This attack vector highlights the danger of "dependency confusion" combined with typosquatting. How is everyone else handling vetting for new dependencies? Are you relying solely on SAST tools, or do you have a manual approval process for new packages?
We've been seeing a spike in these typosquatting attempts recently. Our SAST scanners initially missed this because the packages were obfuscated. I recommend checking your SIEM for unusual outbound connections from build agents. We wrote a quick Kusto query to catch processes spawned by npm that establish external sockets:
Process
| where ProcessName == "node.exe"
| where NetworkConnectionsDuration > 0
| project ProcessCommandLine, RemoteIP
Lockfiles are your absolute best friend here. We pinned all dependencies and enforce npm ci over npm install in production. We also use a private registry proxy (like Verdaccio) to cache approved packages. It adds a bit of overhead to the onboarding process for new libs, but it stops these 'exact impersonation' attacks dead in their tracks by preventing direct pulls from the public registry during builds.
From a pentester's perspective, this is a goldmine for initial access. If you find a repo using npm install without strict lockfile validation, you can often slip a malicious package. into a PR or a compromised dependency. I'd suggest running npm audit --audit-level=moderate as a pre-commit hook. It catches a lot of these upstream issues before they even hit your main branch.
Solid advice from Hannah and Chris. To shift left further, we implemented a pre-commit hook that strictly validates package integrity. While npm ci is essential, ensuring the lockfile hasn't been tampered with locally is critical. We use this command to verify hashes and audit dependencies before commits are allowed:
npm ci --ignore-scripts && npm audit --audit-level=moderate
This prevents compromised packages from executing malicious postinstall scripts or getting committed in the first place.
To satisfy auditors and catch these ghosts, we mandate SBOM generation for every release. This creates a manifest allowing us to instantly cross-reference dependencies against the CISA KEV catalog. We use syft in our pipeline for this:
syft -o cyclonedx- > sbom.
Since these specific packages aggressively target environment variables, detecting the exfil is crucial if prevention fails. I recommend adding a quick grep check in your pipeline for these known malicious names before the build runs. It's a lightweight defense-in-depth layer.
grep -E "(rollup-packages-polyfill-core|rollup-runtime-polyfill-core)" package-lock.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access