Most supply-chain incidents are discussed one registry at a time: an npm package, a PyPI wheel, a GitHub Action, a browser extension. PolinRider is a reminder that attackers do not respect those boundaries.
According to Socket’s July 2026 analysis, the PolinRider campaign has expanded across npm, Packagist, Go modules, and Chrome extensions. Socket says its threat research team identified 162 malicious release artifacts across 108 unique packages and extensions, linking the activity to the broader North Korea-associated Contagious Interview / Famous Chollima developer-targeting cluster.
The practical takeaway is simple: when one repository, maintainer account, or developer machine is compromised, your response cannot stop at the first affected package manager.
What happened
Socket describes PolinRider as an active supply-chain campaign that compromises legitimate repositories, plants obfuscated JavaScript loaders, and publishes infected package versions where the attackers have registry access.
The campaign’s tradecraft is built around hiding in places developers do not usually scrutinize:
- one-line JavaScript payloads pushed far beyond the visible screen width with whitespace padding
- fake
.woff2font files that actually contain executable loader code .vscode/tasks.jsonentries that execute on folder open- suspicious changes in
config.js,vite.config.js,eslint.config.js, and static asset directories - Git history rewriting, including force pushes and anti-dated commits, to make malicious changes appear older than they are
Socket highlights one pattern around the Xpos587 GitHub account: multiple repositories were modified in the same narrow time window on June 23 at 10:00 UTC, which Socket says is consistent with account-level compromise rather than normal project maintenance. In another part of the campaign, Socket says recent activity reached Packagist packages under the sevenspan namespace maintained by the 7span organization.
That cross-ecosystem spread matters. A compromised GitHub account may be able to rewrite repository history, while separate registry credentials determine whether the attacker can publish to npm, Packagist, Go modules, PyPI, or another downstream ecosystem. Defenders need to investigate both sides.
Why this matters for software supply chains
PolinRider is not just another malicious package list. It demonstrates three failure modes that many teams still handle separately.
First, visible Git history is not enough. Socket notes that malicious commits can be anti-dated or hidden behind force-pushed history, making the default repository view look calm while the activity log tells a different story.
Second, development tools are execution surfaces. A tasks.json file that runs when a folder opens can turn a cloned repository into code execution before the developer has built or imported anything. That is the same class of risk we keep seeing across AI coding tools, IDE extensions, and package install hooks: trusted developer workflow becomes the trigger.
Third, package provenance has to be correlated across ecosystems. If one maintainer controls JavaScript packages, PHP packages, Go modules, and browser extensions, a single account compromise can create multiple release channels. Looking only at package-lock.json or only at npm audit output will miss the broader blast radius.
How to check whether you are affected
Start from Socket’s live campaign tracker for confirmed artifacts: socket.dev/supply-chain-attacks/polinrider. Then work backwards from your own dependency and repository data.
For application repositories, search for hidden execution paths:
grep -R 'runOn.*folderOpen\|\.woff2\|eval(' .vscode package.json vite.config.js eslint.config.js 2>/dev/nullAlso inspect repository activity, not just file timestamps:
- Review GitHub or Forgejo activity logs for force pushes and rewritten history.
- Compare registry publication timestamps against repository changes.
- Look for unexpected releases after maintainer-account activity.
- Check whether the same maintainer or organization publishes across multiple ecosystems.
For developer machines and CI runners, treat affected installs as potential credential exposure. Socket’s report says observed loaders have reached out to blockchain and public RPC infrastructure, retrieved encrypted second-stage payload material, decrypted it with embedded XOR keys, and executed it with eval(). Socket names DEV#POPPER and OmniStealer as observed follow-on payloads, while warning that the loader design could deliver other malware as the campaign evolves.
What to do next
If a project installed an affected artifact, rebuild from a known-good lockfile and remove the affected version. Preserve forensic artifacts before cleanup when possible, especially on developer workstations where the payload may have accessed local credentials.
Rotate secrets from a clean machine, not from the potentially infected host. Prioritize package registry tokens, GitHub or Forgejo tokens, cloud credentials, Vault, Kubernetes, Docker, SSH keys, Slack, Twilio, CI/CD secrets, and any credentials exposed to developer tools.
Finally, make cross-ecosystem inventory part of your normal incident response. You need to answer questions like:
- Which repositories referenced this package or extension?
- Which lockfiles resolved an affected version?
- Which developer machines or CI runners installed it?
- Which maintainers or organizations publish related packages in other ecosystems?
- Which secrets were available to those environments at install or folder-open time?
A supply-chain incident that starts in one registry can become a Git, IDE, CI, and cloud-credential incident very quickly.
boring.tools helps teams keep dependency inventory, SBOMs, and repository monitoring connected. When a campaign crosses package managers and developer tools, that context is what turns a long package list into a scoped incident response.