The short answer
Socket has attributed 162 malicious release artifacts across 108 unique packages and browser extensions — spanning the npm, Packagist, and Go registries plus a Chrome extension — to a North Korea-aligned actor it calls PolinRider, part of the wider Contagious Interview campaign. Instead of relying only on typosquatted look-alikes, the attackers compromised real maintainer accounts, tampered with legitimate repositories, and rewrote Git history so the malicious changes appeared to be months old. Obfuscated JavaScript loaders — some tucked into config files — pulled down further payloads, including the DEV#POPPER remote-access trojan and an information stealer, from blockchain and public RPC infrastructure.
The practical reading for engineering leaders: this is not a fringe registry problem. It is a direct attack on the trust model every team leans on when it runs npm install, go get, or composer require. Pinning a package name is no longer enough when a trusted dependency's next version can be the malicious one — so the durable defense is to lock versions to hashes, harden your own publishing accounts, and put automated composition analysis between the registry and production.
What actually happened?
On 6 July 2026, supply-chain security firm Socket published research linking a fresh wave of malicious open-source packages to a North Korea-aligned threat actor. Socket counted 162 malicious release artifacts — individual poisoned versions — tied to 108 unique packages and browser extensions, and it expects the number to keep climbing as the campaign is still live. The artifacts were spread across multiple ecosystems: the npm JavaScript registry, the Packagist registry for PHP/Composer, Go modules, and a Google Chrome extension.
Socket tracks this activity as PolinRider and places it inside the broader Contagious Interview campaign — a North Korea-linked operation, also documented under names like DeceptiveDevelopment, that weaponizes fake job interviews and coding assessments to trick developers and cryptocurrency-sector staff into running attacker-supplied code. The registry poisoning is the same crew widening its net from individual targets to the packages thousands of teams pull automatically. Confirming whether any of that code actually executed inside your environment — not just whether a bad version existed — is exactly where a focused security audit and compromise assessment earns its keep.
The technique is what makes this notable. Rather than only uploading brand-new fake libraries, the attackers compromised existing maintainer accounts and tampered with legitimate repositories, publishing infected versions where they held or obtained access. Socket reported that the actor rewrote Git history to make the malicious commits look older, borrowing the credibility of an established project. The malicious logic arrived as obfuscated JavaScript loaders, sometimes hidden inside configuration files, that reached out to blockchain and public RPC endpoints to pull the next stage — including the DEV#POPPER remote-access trojan and an information stealer built to sweep developer secrets, tokens, and wallet data.
Why is this attack so hard to catch?
Most developers picture supply-chain risk as typosquatting — you fat-finger reqeusts for requests and install a look-alike. That mental model is exactly why PolinRider works. Here the poisoned code lives inside packages teams deliberately install by name, pushed through accounts that were legitimately trusted an hour earlier. There is no misspelling to notice and no unfamiliar author to question.
The Git-history rewriting is the sharpest twist. A common human and automated heuristic is that older, steadily-committed code is safer than something that appeared yesterday. By back-dating malicious commits, the attacker defeats that instinct and slips past casual review. Add loaders hidden in config files and staged payloads fetched from blockchain and public RPC infrastructure — channels most egress filters happily allow — and you have malware that is quiet at install time and hard to attribute at runtime.
This is also part of a documented 2026 trend, not a one-off. North Korea-aligned crews have repeatedly used package registries at scale this year, and the through-line is consistent: developer machines and CI runners are high-value, under-monitored targets that sit upstream of production. Compromise one build agent and you inherit its cloud credentials, signing keys, and deploy access — which is why treating the pipeline as production-grade infrastructure is now core cloud and DevOps hygiene rather than an optional nicety.
Are the registries' new defenses enough?
The registries have not been idle. npm rolled out a 2026 security overhaul that pushes trusted publishing via OIDC to remove long-lived CI tokens, sets a seven-day expiry on new granular write tokens, makes two-factor authentication the default on packages with write access, and retires legacy classic tokens. Those are meaningful improvements, and teams should adopt them for their own packages today.
But security researchers have been candid that these controls do not fully close the two techniques behind 2026's biggest incidents: account takeover and malicious lifecycle scripts that run at install time. PolinRider leans on exactly the first of those. Stronger token hygiene raises the bar for stealing a publish credential, yet a phished or malware-harvested maintainer session can still push a poisoned version — and a mandatory-2FA policy does nothing about a script that executes the moment a victim runs install. The registries are hardening the front door; the burden of verifying what actually enters your build still sits with each consuming team.
What it means for US & EU software teams
Strip away the geopolitics and three durable lessons remain. The first is that the dependency tree is production. If a package your app pulls transitively can run code on your build agents, then your CI runners deserve the same isolation, least-privilege credentials, and monitoring you give production servers. Ephemeral, network-restricted build environments with scoped, short-lived secrets turn a poisoned dependency into a contained event rather than a foothold into your cloud.
The second is that provenance beats popularity. Download counts and star history are exactly the signals attackers now forge. The defenses that actually hold are mechanical: committed lockfiles that pin every dependency to a specific version and integrity hash, software composition analysis in CI that flags any new or unexpected version before it merges, and a software bill of materials (SBOM) so you can answer “are we affected?” in minutes rather than days when the next advisory lands.
The third is that compliance follows the supply chain. A stolen developer token or leaked customer data can start breach-notification clocks — 72 hours under the EU's GDPR, plus a widening patchwork of US state deadlines — and for financial entities it feeds directly into the EU's DORA rules on ICT third-party risk. Teams in regulated verticals like FinTech, whose developers and crypto-adjacent staff are squarely in this campaign's crosshairs, should treat dependency provenance as a control they can evidence to an auditor, not a best-effort aspiration.
What to do this week
Here is the shippable version. Treat PolinRider as a prompt to close the obvious gaps and to fix the pattern that makes registry poisoning so costly.
- Check exposure. Review recent dependency changes across npm, Go, and Packagist; treat any environment that installed an affected version as potentially compromised until reviewed.
- Pin and lock. Commit lockfiles that pin every dependency to an exact version and integrity hash, and require review for lockfile changes — not just source diffs.
- Harden publishing accounts. Enforce 2FA and trusted publishing (OIDC) on your own maintainer accounts; retire long-lived classic tokens.
- Contain install scripts. Disable or sandbox install-time lifecycle scripts, and run installs in ephemeral, network-restricted CI environments with scoped, short-lived secrets.
- Add composition analysis. Put software composition analysis and SBOM generation in CI so new or unexpected dependency versions are flagged before they reach production.
- Rotate on suspicion. If a developer machine or build agent may have run a poisoned package, rotate exposed cloud credentials, tokens, and signing keys and hunt for downstream misuse.
None of this is legal advice, and your exact obligations depend on your sector and jurisdiction. But the strategic signal is hard to miss: the open-source registries your team installs from every day are now a first-class attack surface. The advantage goes to teams that pin what they pull, treat their build pipeline as production, and can prove the provenance of every dependency on demand.
Frequently asked questions
What is the PolinRider npm supply-chain attack?
PolinRider is the name supply-chain security firm Socket gave to a wave of malicious open-source packages it attributed to a North Korea-aligned threat actor. Socket identified 162 malicious release artifacts across 108 unique packages and browser extensions, spanning npm (JavaScript), Packagist (PHP/Composer), and Go module registries plus a Google Chrome extension. It is part of the broader Contagious Interview campaign, running since at least December 2025, which targets software developers and cryptocurrency-sector workers.
How did attackers get malicious code into legitimate packages?
Rather than only publishing brand-new fake packages, the attackers compromised existing maintainer accounts and tampered with legitimate repositories, then published infected versions where they retained or obtained access. Socket reported the actor also rewrote Git history to make malicious commits appear older and more trustworthy. Payloads arrived via obfuscated JavaScript loaders — sometimes hidden in config files — that fetched a remote-access trojan and information stealer from blockchain and public RPC infrastructure.
How is this different from a typical typosquatting attack?
Typosquatting relies on a developer mistyping a package name and installing a look-alike. PolinRider is more dangerous because it poisons packages developers already trust and intentionally install by name, using compromised accounts and aged Git history to evade the checks teams normally apply. Pinning to a known-good package name is not enough on its own — a new version of a legitimate dependency can be the malicious one.
What should teams do to protect their build pipeline?
Treat any environment that installed an affected version as potentially compromised until reviewed. Pin dependencies to specific versions and hashes with a committed lockfile, enforce 2FA and trusted publishing (OIDC) on maintainer accounts, and disable or sandbox install-time lifecycle scripts. Add software composition analysis to CI so unexpected versions are flagged, generate an SBOM, and rotate any credentials that may have been exposed on developer machines or build agents.
Sources
Socket — North Korea's Contagious Interview Campaign (PolinRider)
SecurityWeek — North Korean Hackers Target Open Source Developers in Supply Chain Attacks
The Hacker News — North Korean Hackers Publish 108 Malicious Packages and Extensions in PolinRider Campaign
Dark Reading — DPRK Attackers Spawn Malicious Npm Package Factory