Security researchers at Socket and Rescana have tied 108 unique malicious packages and browser extensions to a North Korean supply chain campaign named PolinRider, part of the broader Contagious Interview and Famous Chollima activity cluster. The count breaks down to 19 npm libraries, 10 Composer packages published to Packagist, 61 Go modules, and one Google Chrome extension, spread across 162 individual release artifacts. The campaign has been running since at least December 2025 and, according to the researchers, remains active, with new malicious versions appearing as the group compromises fresh maintainer accounts.
How the packages stay hidden
PolinRider does not rely on typosquatting or lookalike package names, the tactic most teams have trained themselves to spot. Instead, the operators compromise legitimate maintainer accounts and tamper with packages developers already trust and have used for months or years. The malicious code itself is typically a single line, padded with enough whitespace to push it beyond the default screen width of a code editor or a pull request diff view, so a reviewer scrolling through a changed file simply never sees it. On top of that, the group uses Git history rewriting, including force pushes and back-dated commits, to make the tampering look like it happened long ago rather than in the last release.
What actually lands on a developer’s machine
Packages compromised through PolinRider deliver two payloads: the DEV#POPPER remote access trojan and an information stealer called OmniStealer. Both are built to run quietly on a developer workstation or inside a CI runner, harvesting credentials, tokens, and source code without triggering the kind of alert a ransomware payload would. That is the point. A RAT sitting inside a build pipeline for weeks is worth more to a state-sponsored operator than a smash-and-grab, because it gives sustained access to whatever that pipeline touches, cloud credentials, signing keys, internal repositories, and downstream customers.
What this means for teams shipping software in Europe
If your organisation pulls dependencies from npm, Packagist, or Go modules into a build or CI environment, PolinRider is a direct argument for treating every dependency update as something to verify, not just install. Practical steps that hold up against this specific campaign include reviewing repository activity logs and package release metadata for irregular publishing patterns, checking VS Code task configuration and any auto-run build steps for content that was not part of the last reviewed diff, watching for unusually rewritten Git history on dependencies your pipeline pulls directly from source, and pinning dependency versions with lockfiles rather than trusting floating ranges to pull in whatever a compromised maintainer account pushes next.
If you want a dependency audit against known PolinRider indicators, or a broader review of how your CI/CD pipeline trusts the packages it pulls in, contact Excello Digital. We help European engineering teams close the exact gaps campaigns like this one are built to exploit.