108 Poisoned Packages: North Korea's PolinRider Campaign Targets Developer Supply Chains

North Korea's Contagious Interview threat group has published 108 malicious software packages and browser extensions across four major developer ecosystems, researchers disclosed this week in a campaign now tracked as PolinRider.

The repositories hit — npm, Packagist, Go, and the Google Chrome Web Store — are the equivalent of hardware stores for programmers. Developers visit them constantly, pulling in pre-built components to save time. One poisoned brick in that wall, and the malware travels silently into whatever product the developer is building, and onto the laptop they use to access company systems.

Who Is Actually in the Crosshairs?

Developers are the proximate target. The ultimate targets are the organizations those developers work for: cryptocurrency exchanges, banks, and technology companies.

Contagious Interview has run since at least 2023. The playbook starts on LinkedIn, where fake recruiters posing as talent scouts approach software engineers with attractive job offers. Candidates who bite are asked to complete a "coding test" that quietly installs an information-stealing payload. PolinRider is the industrial-scale version of that same con. Rather than deceiving one engineer per approach, the attackers poison the shared wells that tens of thousands of engineers drink from every day.

The economics make this campaign relentlessly persistent. A single stolen cryptocurrency wallet can net hundreds of thousands of dollars. North Korea's developer-hunting teams have been generating revenue this way for years, and nothing about the incentive structure has changed.

Two Delivery Routes, One Painful Outcome

Researchers identified two primary methods the attackers use to get malicious code into trusted repositories.

The first is typosquatting: publishing a package with a name that mimics a popular one closely enough to fool a developer typing in a hurry. One transposed letter. One extra hyphen. Easy to miss at 4 p.m. on a Friday.

The second method is more damaging at scale. The attackers compromise the accounts of legitimate package maintainers — real, trusted authors whose update notifications developers already follow and click without thinking. Once inside a maintainer account, they push a poisoned release from an identity that carries a history of trustworthy contributions. This account-takeover pattern is specifically why researchers warn that new malicious packages will keep appearing even after PolinRider was publicly named.

Once a developer installs a compromised package, the malicious code typically reaches out to attacker-controlled infrastructure and pulls down a second-stage payload. That payload hunts for three things: cryptocurrency wallet files, browser-saved passwords, and session cookies.

Session cookies deserve particular attention. A valid session cookie lets an attacker authenticate to a service as if they were already logged in — no password required, no MFA prompt triggered. The Verizon 2024 Data Breach Investigations Report found credential abuse present in 31 percent of all breaches; session-cookie theft extends that threat surface further because it sidesteps the credential entirely. Revoking active sessions and rotating API keys on any machine that touched a suspect package is one of the few reliable post-compromise controls.

Which Controls Failed — and Why It Matters

PolinRider exposes a gap that technical controls alone cannot close: developer trust in the supply chain.

The account-takeover vector is the sharper edge here. When an attacker publishes from a legitimate maintainer's account, automated scanners that look for unknown publishers or suspicious new accounts produce no alert. The package passes provenance checks. The human instinct to trust familiar names does the rest. This is social engineering operating one layer removed from the developer — it targets their ecosystem rather than their inbox.

The typosquatting vector is a human-error problem dressed in a technical costume. Developers who understand the risk of dependency confusion and typosquatting pause before they install. Those who have never heard the terms do not. Security-awareness training that covers supply-chain risks specifically equips development teams to apply that pause at the right moment — before the install command runs, not after the incident report is filed.

Missing or insufficient identity hygiene on maintainer accounts compounds both vectors. Strong, unique credentials and hardware-backed MFA on npm, Packagist, Go, and Chrome developer accounts would prevent most account-takeover scenarios. The packages never get published if the attacker cannot log in. This is a solved problem in principle; it is an adoption problem in practice.

What Defenders Should Do Right Now

Organizations with development teams need to act on several fronts simultaneously.

For development leads and platform engineers:

• Pin exact dependency versions in package manifests rather than pulling the latest release automatically. If the package version does not change, a poisoned update has no path in.
• Vet any package that has changed maintainers recently. A new face on a long-standing project is a yellow flag worth investigating.
• Run package installations inside ephemeral containers or sandboxed environments, never directly on developer laptops that hold production credentials or access tokens.
• Immediately revoke and rotate session tokens, API keys, and any secrets stored in browser profiles on machines that installed a suspect package.

For security teams:

• Add software supply-chain scenarios to tabletop exercises. The threat model in which a developer's laptop is the initial access point for a breach of a financial application is not hypothetical — it is the documented Contagious Interview pattern.
• Review identity and access controls for developer toolchains against NIST SP 800-218 (the Secure Software Development Framework), which specifically addresses supply-chain risk management.

For everyday users of consumer products:

You have no direct control here. But understanding that major service breaches often start with a developer's compromised laptop — not with the service itself — explains why the attack surface for any company is much wider than its own perimeter.

PolinRider is still active. New packages are expected as compromised maintainer accounts are used. The campaign will not stop because it was named. Naming it is a starting condition for defense, not an ending condition for the threat.