Dateline: July 6, 2026
108 Poisoned Packages: Inside the PolinRider Open Source Attack
A North Korea linked hacking group is quietly poisoning the tools developers trust most. Security researchers at Socket found a campaign called PolinRider that hides malware inside popular open source packages. The attack is still going on. New infected packages keep showing up.
What Happened?
Socket’s Threat Research Team traced 162 malicious files across 108 packages and browser extensions. The infections spread across four major ecosystems:
- Npm
- Packagist
- Go modules
- Chrome Web Store
Researchers tied the activity to the Contagious Interview and Famous Chollima clusters, both connected to North Korean state actors.
The hackers do not build fake packages from scratch. They break into real maintainer accounts, often through expired domains or account recovery tricks. Then they push malicious code into legitimate projects. To cover their tracks, they rewrite Git history with force pushes and back-dated commits. That makes the poisoned code look old and harmless.
The malware itself is sneaky. Attackers hide obfuscated JavaScript inside config files like vite.config.js, or bury it inside fake .woff2 font files. A hidden VS Code task then runs the fake font file the moment a developer opens the folder.
Once triggered, the loader phones home to blockchain services like TRON, Aptos, and BNB Smart Chain to pull down its next stage. Known payloads include DEV#POPPER and OmniStealer, which steal passwords, browser data, and crypto wallets.
The Impact?
This is a trust problem, not just a code problem. Developers pull in thousands of dependencies without reading every line. When a trusted package turns hostile, the poison flows straight into build systems and CI/CD pipelines. From there it can move sideways into cloud accounts, source code, and secrets.
The blockchain based delivery makes cleanup harder. There is no single server to take down. And because the hackers rewrote history, the GitHub page for an infected repo can look completely normal. One compromised maintainer account can taint dozens of projects at once, as seen with the Xpos587 account and the sevenspan namespace on Packagist.
How to Avoid This
- Treat any environment that installed an affected package as compromised. Then work from a clean machine, not the infected one.
- Rotate every exposed secret. That means npm, GitHub, cloud, Docker, SSH, and CI/CD credentials. Do not reuse them.
- Rebuild from a known good lockfile instead of trusting the current state of your repo.
- Check GitHub Activity logs, not just commit history. Force pushes hide in the Activity tab.
- Audit VS Code task files for anything set to run on folder open, especially commands that run .woff2 files with Node.
- Watch for outbound traffic to blockchain RPC endpoints from developer machines. That is a strong red flag.
Your Code Is Only As Safe As the Packages You Trust
Supply chain attacks like PolinRider slip past scanners because the malware lives inside code you already approved. Secure.com helps you catch the threat before it reaches production.
- Map real attack paths from a poisoned dependency to your crown jewel systems, so you see what one bad package could actually reach
- Simulate lateral movement to test how far an attacker could spread after a developer machine is hit
- Automate findings into a live risk register instead of chasing alerts by hand
- Orchestrate your existing security tools into one workflow rather than juggling ten dashboards
- Flag risky third-party and open source dependencies before they land in your build
