North Korea-Linked PolinRider Campaign Hides JavaScript Loaders in Open Source Repositories

Security researchers have uncovered a North Korea-linked supply chain campaign that plants hidden JavaScript loaders inside open source repositories and package releases used by developers.

The campaign, tracked as PolinRider, has spread across npm, Packagist, Go modules, and a Chrome extension, according to a new Socket report. The activity has been linked to the broader Contagious Interview and Famous Chollima developer-targeting clusters.

Socket said it identified 162 malicious release artifacts across 108 unique packages and extensions. The findings include compromise traces in 80 Go modules, 10 Packagist packages, and one Chrome extension.

PolinRider Targets Developers Through Trusted Code

The campaign matters because it targets software developers inside normal development workflows. Instead of relying only on fake job offers or suspicious attachments, the attackers hide malicious code in projects that look legitimate.

That approach can expose source code, registry tokens, cloud credentials, wallet data, SSH keys, CI/CD secrets, and internal systems. A single infected developer machine can become a doorway into a wider organization.

Socket’s live PolinRider tracker lists the campaign as ongoing and tracks affected artifacts as new information becomes available.

Detail	What Socket reported
Campaign name	PolinRider
Attribution	North Korea-linked activity tied to Contagious Interview and Famous Chollima
Malicious artifacts	162 release artifacts across 108 packages and extensions
Affected ecosystems	npm, Packagist, Go modules, and Chrome extensions
Main target	Developer environments and open source supply chains

How the Malicious JavaScript Loaders Stay Hidden

The attackers use several concealment methods to make infected repositories look normal. Earlier versions hid obfuscated JavaScript inside configuration files, often pushed far beyond the visible screen width with whitespace padding.

Newer variants disguise the loader as a fake .woff2 font file. This makes the payload easier to overlook because developers usually treat font assets as static files, not executable code.

The loader can also run through Visual Studio Code task files. Microsoft’s VS Code tasks documentation explains that tasks using the folderOpen option can run when a workspace folder opens, depending on trust and automatic task settings.

Blockchain RPC Services Used to Fetch Payloads

Once the loader runs, it can contact blockchain and public RPC infrastructure, including TRON, Aptos, and BNB Smart Chain services. The loader then retrieves encrypted second-stage payload material.

Socket said the malware decrypts that material with embedded XOR keys and executes the result with eval. That design lets the attackers change the payload behind the loader without relying on one fixed malware file.

Observed payloads include DEV#POPPER and OmniStealer. An eSentire analysis of DEV#POPPER and OmniStealer described malware behavior that includes credential theft, browser-data theft, wallet targeting, and remote access capabilities.

• DEV#POPPER can support remote access and command execution.
• OmniStealer can target browser data, credentials, and cryptocurrency wallets.
• The loader-based design means other payloads could appear later.
• Blockchain infrastructure can make payload staging harder to remove quickly.

Compromised GitHub Accounts and Rewritten History

A major part of the PolinRider activity involves the GitHub account Xpos587. Socket said several repositories connected to that account were modified in the same narrow window on June 23 at 10:00 UTC.

That pattern points to account-level compromise rather than routine project maintenance. Repositories tied to the activity include Xpos587/git2md, Xpos587/markfetch, and Artiffusion-Inc/mirofish.

The markfetch repository used the fake font method, while mirofish carried malicious code inside vite.config.js. Socket also reported Git history rewriting, including force pushes and backdated commits, which can make malicious changes appear older than they really are.

Packagist and Go Module Activity Expands the Risk

PolinRider did not stay inside one package ecosystem. The campaign also reached Packagist through the sevenspan namespace, linked to the 7span organization.

Socket said maintainers removed fake .woff2 files from some affected repositories after discovery. However, some obfuscated JavaScript hidden in configuration files remained, showing why partial cleanup can miss other malicious variants.

The PolinRider findings also show why visible commit history alone may not be enough during incident response. Security teams need to review repository activity logs, package release metadata, and registry publication history.

Indicators Developers Should Review

Security teams should treat any environment that installed affected package versions as potentially compromised until they finish a review. This matters most for machines with access to source control, package registries, cloud consoles, secrets vaults, production systems, or crypto wallets.

Developers should check for suspicious changes in .vscode/tasks.json, config.js, vite.config.js, eslint.config.js, and files under font or static asset directories. Unusual Node.js execution of files with non-code extensions should raise immediate concern.

The campaign also shows why trusted repositories can become risky after a maintainer account takeover. A familiar project name does not guarantee that the latest release is safe.

Indicator type	Indicator	Why it matters
GitHub account	Xpos587	Linked to bulk repository modification activity
Repository	Xpos587/git2md	Connected to malicious Go module release activity
Repository	Xpos587/markfetch	Used the fake .woff2 payload-hiding technique
Repository	Artiffusion-Inc/mirofish	Contained malicious code inside vite.config.js
Namespace	sevenspan	Packagist namespace tied to compromised package activity
File	.vscode/tasks.json	Can trigger hidden execution paths when a workspace opens
File type	Fake .woff2 file	Disguises JavaScript loader as a font asset

What Security Teams Should Do Now

Organizations should preserve forensic artifacts before cleaning affected machines. Removing the package too quickly can destroy evidence needed to understand whether secrets were exposed.

Teams should rebuild from known-good lockfiles, rotate exposed credentials from a clean machine, and review developer workstations for automatic VS Code tasks. They should also inspect repositories for suspicious force pushes, backdated commits, and unexpected package releases.

The Socket campaign page should help teams track newly confirmed packages and extensions. Developers should also review automatic task behavior in Visual Studio Code and disable untrusted workspace automation.

Why PolinRider Is a Serious Supply Chain Threat

PolinRider shows how developer-focused attacks continue to evolve. The attackers are not only sending fake interviews or malicious coding tests. They are also placing loaders into repositories and package ecosystems that developers may already trust.

This strategy gives the campaign a wider reach. If a compromised package enters a project, the malicious code can run inside environments that hold sensitive credentials and internal access.

The connection to DEV#POPPER and OmniStealer adds another risk layer. The DEV#POPPER and OmniStealer report shows how developer systems can become targets for both credential theft and deeper supply chain compromise.

FAQ