PolinRider: North Korean actors seed 108 malicious packages across four ecosystems

The Hacker News reported on July 4 that the DPRK-linked cluster behind the long-running Contagious Interview campaign has pushed 108 unique malicious packages and browser extensions across four ecosystems — npm, Packagist, Go, and the Google Chrome Web Store — under an ongoing operation researchers are tracking as PolinRider. The campaign is still live. New packages are still appearing. THN’s summary notes that some of them arrive by way of compromised legitimate maintainer accounts, not just typosquats under throwaway namespaces — which changes the shape of the defensive work.

If your instinct is “we don’t install random packages, we’re fine,” you are not the target here. Your developers are.

What’s actually being reported

From THN’s writeup, the confirmed shape of the campaign is:

• 108 unique malicious packages and Chrome extensions identified so far. Not a single dropper family — a portfolio, spread deliberately across ecosystems that share the same audience.
• Four ecosystems in scope: npm (JavaScript/Node), Packagist (PHP, Composer), Go modules, and the Chrome Web Store. That mix is developer-facing across the board. This is not a browser-extension play aimed at general users.
• Attribution: the same DPRK-linked cluster behind Contagious Interview, the fake-recruiter campaign that’s been active for at least two years now, targeting developers with malware disguised as coding assessments or interview take-homes.
• Still active: per the THN summary quoting the researchers, “the campaign remains active, and new malicious packages are likely to continue appearing as threat actors compromise maintainer accounts.” That last clause is doing the work. Some of these are landing under real maintainer namespaces, not spoofs.

For the full package list, indicators of compromise, and per-package detail — go to The Hacker News’s writeup, and follow through to the researchers’ own publication as it lands. We are not reproducing the package names here; the actionable move for a defender is not to grep for 108 strings, it is to look at how they got in and shut that path.

Why this shape matters more than the count

108 is the headline number and it is not the interesting one. The interesting numbers are four (ecosystems) and some (maintainer accounts already compromised).

Four ecosystems in one campaign means the operators are not opportunistically dropping a bad npm package and moving on. They are running an ecosystem-level supply-chain program, spreading across the registries a modern polyglot dev shop actually pulls from. If you write Node on the frontend, PHP for a legacy service, Go for a control plane, and let developers install Chrome extensions on their work laptops — which is most shops, honestly — you have exposure in four places, not one.

Compromised maintainer accounts is the other one to sit with. A typosquat is a search-result problem: a developer types the wrong name and lands on a fake package. A compromised maintainer account is a trust problem: the package is being served from the same account that shipped the last five legitimate releases, with the same signing key or the same npm token, into the same install flow. Your lockfile looks unchanged. Your dependency graph looks unchanged. The name is the one you already pinned. The version bumped from 2.3.7 to 2.3.8 and your CI installed it on schedule.

Metadata review and namespace verification — which is what the industry has been telling developers to do for years — does not catch the second case. That is why “some” is doing more work in that sentence than “108” is.

What to do this week — in priority order

1. Freeze automatic minor/patch upgrades on production dependency graphs for the next seven days.

Dependabot and Renovate default to auto-merging minor and patch bumps after CI passes. That is a fine default when the ecosystem is quiet. It is the wrong default while a campaign is actively pushing compromised versions under legitimate maintainer namespaces. Pause the auto-merge rule this week. Manual review only. You will annoy the team and you will not miss anything.

2. Audit Chrome extension installs across managed browsers.

The Chrome Web Store leg of PolinRider is the one people will underweight because “extensions” sounds low-stakes. Extensions with activeTab and broad host permissions can read source code out of GitHub, read tokens out of cloud consoles, and pass session cookies to a listener the developer never sees. Pull an inventory of every extension installed across your managed Chrome fleet — Google Workspace Admin Console under Devices → Chrome → Apps & extensions does this centrally — and go through anything that was installed in the last sixty days by someone in engineering, DevOps, or platform. Anything unaccounted for, kill and reauth.

If you don’t manage extensions centrally, that is the finding of the week. Fix that first.

3. Look for Contagious Interview lures reaching your developers directly.

Some of these packages land through recruiter-flavored social engineering, not through unlucky npm install. A “coding assessment” arrives as a repository the candidate is asked to clone, run, and extend. The malicious package is either pinned in that repo’s lockfile or arrives via a script the candidate is asked to run. This is a message-your-team problem, not an EDR problem. Tell your engineers this week: if a recruiter you did not solicit sends you a take-home that requires running unfamiliar code on your work machine, run it in a throwaway VM or don’t run it at all. This is not paranoia, it is the ongoing campaign the report is about.

4. Check maintainer-account hygiene on your own published packages.

If you or your org publishes to npm, Packagist, or Go, this campaign is a reminder that the account is the perimeter. Turn on hardware-key 2FA for every publisher account. Rotate publish tokens that were issued for CI more than a year ago. Restrict which repos and workflows can use those tokens — GitHub OIDC to the registry is better than a static token in a repo secret, everywhere it is available. If your account is next, this is the difference between “someone published a bad version under our name” and “someone tried and got denied.”

5. Add the package names to your artifact-scan and EDR block lists as the researchers publish them.

This one is last because it is only useful in reaction, not prevention. Once the full list is out, block-list every one of the 108 in the artifact-scan step of your CI, and where possible in the package-registry proxy your dev shop pulls through. If you don’t already run a caching registry proxy (Verdaccio, JFrog, Nexus, Artifactory) in front of npm and Packagist for internal builds — that is a different conversation and a heavier lift, but it is the durable answer to this class of campaign. Registry-side blocking scales; per- developer awareness does not.

Priority call

Do #1 this afternoon. Auto-merge on minor bumps is the easy exposure and the one you can shut down in a Slack message. Do #2 tomorrow — the extension inventory is the leg of the campaign your team is least set up to see. #3 goes to the whole engineering org as a memo, this week, plain language, no infosec jargon.

The rest is durable work that pays down the general problem this campaign is a specific instance of. If you were already doing #4 and #5 you were already ahead. If you weren’t, this is the reminder.

Watching for

• The researchers’ full package list, per-registry breakdown, and named IoCs. THN’s summary is a pointer to the underlying research; wait for the primary source before feeding your SIEM.
• Registry-side response times. npm, Packagist, and the Chrome Web Store all have takedown workflows for these — the interesting number is not “how many did they remove” but “how quickly after first publish.” That is the metric that decides whether the ecosystem is getting better at this or not.
• Follow-on publishes. Contagious Interview has re-uploaded under adjacent namespaces after every prior takedown. Assume the same here. A block list of 108 today is not a block list of 108 next week.

Sources

• The Hacker News: North Korean Hackers Publish 108 Malicious Packages and Extensions in PolinRider Campaign (July 4, 2026)
• Background on the broader operation: our DPRK Rollup polyfill impersonation write-up from July 3, which covered a two-package impersonation attributed to the same cluster and the maintainer-namespace angle that PolinRider now scales up. See also our ChocoPoc fake-PoC repos coverage for a related “malicious content targeting developers directly” pattern from earlier this week.