PolinRider: A Supply-Chain Loader in 40,136 GitHub Repositories

PolinRider is already public. What was missing was its size. The largest public count I found was 1,951 repositories. On 30–31 October 2026, 40,136 public repositories under 3,334 accounts carried the malicious code on their default branch. For each one I recorded the commit, the file and its git object id.

• The count started from 8,219 code-search candidates and grew as I scanned every public repository of each confirmed owner. That round was repeated until it found no new owners.
• Every repository was then proven again at a pinned commit. A random sample of 555 was re-read through a different API, and all 555 matched.
• In 3,281 of the accounts at least one repository was changed in place. In the other 53, the only infected repositories are forks carrying their parent's identical file.
• The code hides in two places. One is a file named like a font that is really JavaScript, started by a hidden VS Code task. The other is a JavaScript payload pushed off-screen by whitespace in a build configuration file.
• Most infections were folded into rewritten, back-dated history and force-pushed in September and October 2026. In 93 of 151 cases I could check, the account that pushed was not the credited author.
• 13 open pull requests carry the payload into other projects.
• The loader fetches its next stage from TRON, Aptos and BNB Smart Chain (BSC). I decrypted 179 of 182 payloads stored on BSC. Most of the addresses involved are already public, some under other campaign names. Two TRON accounts and two command-and-control addresses were not in any public source I checked.

I did not execute anything, contact command-and-control servers, or open victims' data. Public reporting (OpenSourceMalware, Socket) links PolinRider to North Korean operators [1, 2]; I did not make that attribution myself.

The proven set was closed on 1 November 2026 with what had been found up to 31 October 2026, 17:59 UTC; repositories found after that are tracked separately and are not in these figures. The full proof pass at pinned commits ran on 30–31 October. On 1 November 2026, 18:23 UTC a read-only GitHub API recheck covered the 162 repositories, 73 accounts and 12 issues that are tracked one by one (operator repositories, Shai-Hulud accounts, phishing issues), not the whole set.

• Frozen: 40,136 repositories under 3,334 accounts; 3,281 accounts had a repository changed in place.
• Removal, estimated: on 31 October a random sample of 600 proven repositories found 5 cleaned and 2 deleted (about 1%). The full set has not been re-read since 31 October.
• Not counted: 22,870 infected non-default branches; seven fork-collector accounts.

I found PolinRider while investigating a different campaign, the Contagious Interview fake job tests described in Contagious Interview. Seventeen repositories carrying that campaign's errorHandler.js loader also had a VS Code task that ran Node.js on a file named fa-brands-regular.woff2. A real web font is binary. These files were text.

A first search on 28 October found 832 such repositories under 314 owners. 734 of them were not in OpenSourceMalware's public lists, whose last update was dated 10 July 2026. A wider search the same day returned 32,237 raw hits in 8,219 repositories under 3,060 owners. On 29 October I verified every one.

Code search misses most of the campaign, because it indexes only some repositories and no forks. So I then listed every public repository of each confirmed owner and checked them all, and repeated that for each owner the round turned up. The fourth round found nothing new.

On 30 October every candidate from both passes was proven again from scratch:

1. read the repository by numeric id;
2. pin its default-branch commit;
3. read the matched file at that commit;
4. apply a fixed rule.

On 31 October three more repositories passed the same rule. A wider read of lure and tool repositories found them, each with the hidden config payload in an ordinary build config (vite.config.js, postcss.config.js, astro.config.mjs). None is a fork and all three owners are new. They are included in the table, the chart and the account counts below.

Later on 31 October an extended search added 138 more under the same rule, for 40,136 repositories under 3,334 accounts. I listed every public repository of the owners of newly proven repositories in all activities, and ran 36 code searches scoped by file name and extension. Listing owners found 136 of them; the scoped searches added 2. 122 carry the VS Code task and 16 the config payload. 18 are forks, none an identical copy of its parent, and 11 owners are new. Two more matched but sit in a test-fixture or documentation path, so the dataset rule leaves them out. The verdict table and the chart below describe the 39,998; the account table includes the 138.

A task file counts only if:

• it runs on folder open;
• it starts node on a file that is not a script;
• that target exists at the same commit, is not empty and looks like JavaScript.

A config file counts only with the campaign's global marker plus a long whitespace run or a line over 1,500 characters.

The sample check re-read 555 proven repositories, stratified by rule and account type, through the REST contents API at the pinned commit. All 555 matched. An earlier sample had found seven task files whose target was empty, so the rule was tightened before the final count. That removed 806 repositories.

22,870 non-default branches in 6,530 repositories also carried the payload on 29 October. They are not added to the repository count.

• In the tasks I sampled, all used "runOn": "folderOpen". In 156 of 178 the label was a lint- or build-like name, and the task was hidden from the terminal.
• In 138 of 178 the command checks for Node.js on macOS, Linux and Windows and fails silently; 13 call node directly. The target has a font extension: .woff2, .woff, .ttf, .otf, .eot, and in a few cases .orc.
• The "font" sits deep in an unrelated folder, under a public/fonts/ path, so it looks like a bundled asset. Every one of 248 resolved targets in an earlier sample was text.

The task needs the user to open the folder in VS Code and trust the workspace. No dependency install is needed.

Obfuscated JavaScript is appended to a configuration file that build tools load automatically: tailwind.config.js, postcss.config.mjs, and later Next.js and Vite configs. It starts after hundreds of spaces. In one infected repository, a PostCSS configuration that shows 12 normal lines is 5.4 KB on disk. The code sets a global marker (_V, later !) so it runs once per process, then starts the loader.

Statically, the config payload has three layers: a character shuffle, a dictionary decoder and a string table. Decoded, it is the same TRON → BSC dead-drop loader described below, with an Aptos fallback. Two early samples still have one layer left.

Commit dates in this campaign are attacker-controlled. Only push events, pull-request force-push events, repository creation and fork snapshots date anything.

The shape is one account sweeping several repositories of one organization within minutes. One account touched five repositories of three owners in six minutes. Another touched six repositories of one organization in 84 minutes. Two accounts each infected five repositories within the same minute. In one organization, five pull requests credited to one developer were force-pushed within four minutes by a different account with write access.

The 46 operator-side accounts I could identify had no commits or pull requests in anyone else's repositories.

The 12 rewritten pull requests target, among others, a widely used data-privacy SDK (closed unmerged on 9 October), an AI framework's Dart SDK (closed unmerged on 28 October) and open-source hospital software (still open). A broader pass found 296 repositories with merged pull requests touching the abused paths. 125 of them, in 34 organizations, are infected now; for those the route is not proven.

The font form also uses a fourth lookup: it reads the latest transaction from an Ethereum address to learn the current command-and-control IP address, then fetches the next stage from that server on port 443. That address published eight IP addresses through 609 transactions between 25 July and 19 October 2026.

The mechanism, the first TRON accounts, the earliest Aptos fallbacks and the loader keys are already public [1, 2, 4]. I do not reproduce keys here.

One TRON funder, not found in public sources, paid four of these accounts, including TLmj13 with 53 payloads. That account sent 58 transactions; 57 carry reversed BSC hashes, pointing to 53 distinct payloads from 12 June 2025 to 27 January 2026, none of them among the 128 found through the other accounts.

The 86 loaders use the same three-layer obfuscation and point onward to a TRON account; 48 start a detached node -e process and 16 use eval. Their three Aptos fallback accounts are all in public reporting [4, 8, 10]. The 93 final builds are packed with obfuscator.io, and every one is distinct. Their embedded build tags run from 250602 to 260206; the authors wrote these strings, so they are not verified dates.

Capabilities present in the 79 builds whose strings were recovered:

Public reports already describe similar capabilities [2, 4, 5], so none of this is presented as new. It is read from code, not observed in operation.

Fifty of the 79 builds whose strings I recovered name no IP address.

Evoxt (AS149440) is a self-service VPS provider based in Kuala Lumpur. It sells plans from about $2.99, accepts cryptocurrency, and asks for identification only from clients it considers suspicious. Its acceptable-use policy bans malware and botnet control. It is not on Spamhaus's ASN drop list. Public reports also tie it to unrelated state-linked actors [6, 7].

My assessment, with moderate-to-high confidence: an abused budget host, not a "bulletproof" one. Four Ethereum-published addresses were public from 17 September 2026 [3], and SafeDep named Evoxt on 30 September [4]. I found no sign that the provider acted; the actor kept rotating between Evoxt addresses.

Exact platform and on-chain dates:

Periods that cannot be pinned to a day: config-payload variants appear from June to October 2025; fake fa-brands-regular.woff2 files appear in October–November 2025; infected repositories received 897 pushes in September 2026 and 4,137 in October 2026.

1. Open unfamiliar projects in restricted mode. VS Code's workspace trust stops folder-open tasks. Before trusting a folder, read .vscode/tasks.json for "runOn": "folderOpen".
2. Check that fonts are fonts. A .woff2, .woff, .ttf, .otf or .eot file that opens as text is a strong signal.
3. Look past the right edge of build configs. Search tailwind, postcss, next and vite configurations for long whitespace runs, over-long lines and global['_V'] or global['!'].
4. Do not trust commit dates. Use push events, pull-request force-push events and fork snapshots.
5. Re-review pull requests whose head branch was force-pushed after review.
6. Treat an infected repository as an infected machine or token of the account that pushed, not only of the credited author.
7. Scan all branches. Code search sees only default branches.
8. Network: developer machines and CI rarely need to query TRON, Aptos, BSC or Ethereum RPC from node. Alert on that, and on the addresses below.

Written from the inclusion rules above, for source files rather than binaries.

• Remove the task, the fake font and any config payload; check every branch and open pull request.
• Assume the machine of the account that pushed the change is compromised. Rebuild it, then rotate GitHub, npm and cloud tokens, SSH keys and passwords saved in browsers, from a clean device.
• Rewritten history means the bad commit may look old. Compare against a fork or a backup.

• Static analysis only. Capabilities are read from recovered strings, not observed.
• The first pass used code search, which sees only default branches and no forks. The owner-wide expansion closed most of that gap, but seven very large fork-collector accounts were not scanned. The counts are a floor.
• pushedAt is the last push, not the infection date.
• The pusher analysis covers 151 of 478 repositories; the rest fell outside GitHub's event window.
• About 165 BSC payload transactions were not enumerated. Three payloads and two early config variants were not fully decoded. The known-plaintext decryption leaves about 0.1% token errors.
• Ports of the final command-and-control servers are not confirmed.
• Hosting ownership was not checked prefix by prefix.
• Attribution to North Korea comes from public reporting, not from this work.

This article is part of the GitHub threat investigation. Counts are a snapshot, not evidence that the code ran on a victim's machine. The shared methodology and proof rules explain inclusion, exclusions and the independent re-check.