The AUTH_API_KEY Loader in 649 GitHub Repositories

In 649 public repositories, an ordinary-looking server or build file decodes an environment variable named AUTH_API_KEY and evaluates code with it. The variable sits in the repository's .env file. It is not an API key: it is the base64 form of a web address.

• The 649 repositories belong to 379 accounts. None is a fork.
• 193 of those 379 accounts also own a proven PolinRider repository. The two loaders often hit the same victims.
• In 571 of the 609 repositories whose .env I read, the variable pointed to one of 30 Vercel apps, most named auth-confirm-<word>, or to a file on the catbox file host.
• The pattern itself was described publicly in 2025, in a recruitment-scam write-up. I found no public count of affected repositories and none of these addresses.

I did not request any of these addresses. The variable was decoded as text inside an isolated virtual machine. The owners are treated as victims and are not named.

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: 649 repositories under 379 accounts; the last three were added on 1 November after being pushed on 31 October, so the loader is still being planted.
• Overlap: 193 of the owners also hold a proven PolinRider repository.

Because the address lives in .env, a reviewer who reads only the source sees a call that looks like authentication. The proof rule checks the decode-and-evaluate pattern; I did not confirm the fetch step file by file, and I never requested the addresses.

The first proof pass found 231 repositories. They came from a single code search on 27 October that I did not page through. On 30 October the daily spread tracker ran the same search with full paging and found 447 more repository files that match the proof rule. I reviewed them with rules fixed before counting:

One repository in the first 231 matched only through a security audit note, not code. I removed the loader label from it; its separate PolinRider proof stays. That gives 231 − 1 + 384 = 614.

On 31 October 33 were added and one removed. Nine were found by the daily tracker and also carry PolinRider. 24 are among the 42 not added above: their current .env gives no decodable address, but an .env committed earlier in their history decodes to an address already in the proven set. One repository in the 614 matched only in a coding-assistant notes file, with no loader in any code file, so I removed it. That gives 614 + 33 − 1 = 646.

On 1 November I added three more, found by the daily tracker on the evening of 31 October. Each loader file was pushed on 31 October and was read again at a pinned commit on 1 November. Two of the three owners are new to the set. That gives 649.

The table covers the 539 repositories listed under their loader file. The other 110 also carry PolinRider and are listed under that proof. 531 of the 539 files are TypeScript. Build configurations matter most here: vite.config.ts or next.config.ts runs on every npm run dev, before any application code.

Repository creation years (609 read): 302 in 2025 and 226 in 2026. The other 81 were created between 2014 and 2024. Last pushes cluster in October 2026 (195), August (162) and September (86).

Each repository points to one address. Catbox and Vercel are public hosting services and are abused here; neither is attacker-owned.

• PolinRider. 193 of the 379 owners overlap. Both loaders appear in the same developer accounts, and both evaluate code fetched at run time. The data shows shared victims. It does not show whether one operator runs both, or whether a machine infected by one later received the other.
• Contagious Interview. Its errorHandler loader also evaluates a remote response, and the public 2025 description of this pattern came from a fake-recruitment project. I count the two separately, because the code and the hosting differ.

No attribution is made here.

1. Search your code for atob(process.env next to eval(, new Function( or Function(.
2. Never commit .env, and treat a base64 value that decodes to a URL as hostile.
3. Read build configurations (vite.config.*, next.config.*, nuxt.config.*) before running a project you did not write. They execute on npm run dev.
4. If you find it, also check for PolinRider. Look for .vscode/tasks.json with folderOpen, and for build configs with long whitespace runs.

• The payloads were not downloaded, so what they do is not known from this work.
• Five repositories were not read for .env and are missing from the address and year tables.
• The proof rule requires atob on an environment variable plus eval or Function. A file that loads the code some other way would be missed.
• 42 repositories with the same pattern but no decodable address are not counted.
• Code search covers default branches only, so this is a floor.

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.