Indicator review, 2026-10-21

Outcome	2 indicators added
Pull request	the ioc/2026-10-21 pull request
Indicator set	ioc/bad-packages.txt, ioc/weak.txt

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

Source	Reached	What it said
OpenSourceMalware dossier	yes, cloned and read	Unchanged for the eighth week running. Latest commit still 0a8c9ea, 2026-07-09: fifteen weeks. No CSV newer than the two July 10 files
opensourcemalware.com blog	yes. /blog served the full index	One post since the last review: “Glassworm Hacks OVH Clouds CLI tool”, 2026-10-19 (22:18 UTC, after that review ran). Read in full. Not PolinRider; see upstream state
Web search, last 7 days	yes	Searched the campaign name, MicrosoftSystem64 and ForceMemo. Nothing new published inside the window under any of the three. The MicrosoftSystem64 search surfaced two June package names this set never carried; see below
socket.dev tracker	no, 403	Seventh week in a row
OpenSSF malicious-packages	yes, git clone --depth 1 at commit ce5ff6a672 (2026-10-21)	64 records match the campaign key. No new package name. One record updated inside the window: html-to-gutenberg; see below
registry.npmjs.org	yes	Used to check every name below
Other hosts	safedep.io, blog.deception.pro, thehackernews.com, checkmarx.com, mallory.ai, stepsecurity.io, pypi.org, rustsec.org, cdn.syndication.twimg.com: reachable. medium.com: 403

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

Indicator	File	Why there	Source
utils-terminal	bad-packages.txt	Attacker-owned MicrosoftSystem64 dropper, toskypi cluster; npm placeholder; not an ordinary phrase	Microsoft Threat Intelligence, 2026-06-03
logger-active	weak.txt	Same post and family, but an ordinary UI state or class name a project could use as a whole word, where bad-packages.txt would call it a confirmed hit	Microsoft Threat Intelligence, 2026-06-03

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.