PhantomSub follows channels, not groups, and a public record of it predates OX's report by 125 days

A public record of the behaviour is 125 days older than the report

OX Security published its PhantomSub report on 28 September 2026. On 26 May, the npm registry shows saturn-bail 1.1.12 arriving at 13:58 UTC, and two minutes and sixteen seconds later the OSV malicious-package database published a record for it, from an Amazon Inspector analysis. The record describes a fork of the Baileys WhatsApp library that force-subscribes the installer's account to a channel its author controls. saturn-bail is one of OX's 101 names. From that record to OX's report is 124 days 22 hours, or 125 days by the calendar. It is the earliest dated public record of the behaviour that I found for any of the 101.

What that date does not establish: how many people ran that version, whether any account was followed by it, or who published it. It is a scanner's reading of code, made minutes after upload. The date people will reach for is older and weaker. The oldest of the 101 names, alipclutch-baileys, was registered on 20 October 2025, 343 days before OX published. A registration date says when a name appeared, not when the code inside it began to misbehave: the oldest version of that name that any public record flags was published on 5 August 2026.

The headline that travelled says these packages add developers to WhatsApp groups. OX's own analysis describes something narrower: a follow of a WhatsApp channel, then a mute. I did not run or download any package, so what the code does is the researchers' account, labelled as theirs. OX edited its post on 29 September and I read that version. The registry figures are my own queries at about 15:50 UTC on 29 September.

The dates on the record. Registry timestamps are from the npm registry API; the rest are from the reports.

Date (UTC)	What it is	What it does not establish
20 Oct 2025	`alipclutch-baileys` registered, the oldest of the 101	That its first version was malicious
26 May 2026	`saturn-bail` 1.1.12 published; OSV record MAL-2026-4818 at 14:01	Any install, any followed account, or who published it
10 Aug 2026	SafeDep reports Baileys forks that follow channels	That anyone acted: 72 of the 101 names first appear on or after this date (derived)
24 Aug 2026	npm replaces `saturn-bail` with a security holding package; OX's table lists this as its publish date	That npm acted on the other 100
28 Sep 2026	OX publishes: 101 names, 16 removed	That the other 85 were gone: OX lists them live

The headline says groups. The code follows channels

OX's overview says the packages "add the victims to groups without their consent". OX's title says spam channels, and everything in its analysis is a channel: identifiers ending in @newsletter, a module called newsletter.js, a follow and a mute. OX reviewed 94 of the 101 packages (19, 60 and 14 in its three variants, plus one that resolves an invite code); seven were removed before review, so their behaviour is unknown. In the 94, the action is a follow. SafeDep, on a different set of forks, describes the same act and says it is "not credential theft".

A channel and a group expose different things. WhatsApp's Help Center says a channel follower is not visible to other followers, who cannot see the follower's name, phone number or profile picture. Admins can see the profile name and, depending on profile settings, the photo. An admin who is also a contact can see the full number. So the exposure most readers assume, their number shown to a room of strangers, is not what WhatsApp describes for a channel follower. The group privacy setting applies, per WhatsApp, "when someone tries to add you directly to a group"; a follow from your own linked session is not that, so I doubt the setting would stop it. That is inference; neither source tests it.

What the account becomes is inventory. OX reads the muted followers as social proof for channels that are mostly small, largely Indonesian seller channels: bot scripts, premium APKs, boosting, and game and social accounts. The channels OX could preview range from 4 to about 19,000 followers; those are channel totals, not counts of forced follows. OX shows one funnel, a sales post that ends in a group invitation, and one channel whose description holds a group invite link, a "possible next hop" in its words. A group sits at the end of that path, for someone who chooses to follow it. That any developer did is not established.

What the code needs from the developer, and why it did not need to steal it

Baileys is an unofficial implementation of the WhatsApp Web protocol. Its README says it authenticates as a second, linked client: the developer scans a QR code or enters a pairing code in the WhatsApp app, and the library then holds the session's credentials and keys, which the developer is told to save between runs. The README's own example writes them to a folder on disk. Anything running in the bot process can act as that linked device. A malicious fork does not have to steal the credential, because it already holds it. SafeDep's wording is that these forks "act through the installer's authenticated session".

What a fork does with that access is its author's choice. In OX's packages it is a follow. SafeDep found other forks that add an advertising link to every image and video the bot sends, forge a channel attribution on outgoing messages, or send a message from the account and then disable the bot. The forks it analyses for those are not in OX's list, but one of OX's names, alipclutch-baileys, has an OSV record citing the same advertising host, in the same file and lines, that SafeDep decoded in one of them. OSV's automated reading calls that a relay of message traffic; SafeDep's reading of the same code is an advertising link. OX does not mention it, so "follow only" may understate part of the 101. The Amazon Inspector record for saturn-bail adds that any downstream end user paired through a bot built on the library is enrolled, so followed accounts may belong to a bot's users as well as its developer. The same upstream has produced worse: in December 2025 Koi Security reported lotusbail, which, per The Hacker News and The Register (Koi's own post now redirects elsewhere), copied tokens and messages and linked the operator's device to the victim's account.

"Open source WhatsApp library" is a licence, not a publisher

The upstream is real, popular and MIT licensed. WhiskeySockets/Baileys has about 11,200 stars, and npm's API shows @whiskeysockets/baileys at 1,816,599 downloads in the 30 days to 27 September. The licence lets anyone copy the code, change it and republish it under any name. That is the design and also the mechanism: a fork named like the original inherits its trust for the price of a publish. Of the 101 names, 52 are scoped, which reads like an organisation, and the registry lists one maintainer account for each of the 85 still installable. OX reads a shared channel as a shared beneficiary, not a shared author; SafeDep found different accounts and emails and concluded independent operators reusing one technique. Neither names an actor.

OX advises: do not use any package that asks you to connect your private accounts. Read literally, that rules out the genuine library too, because connecting an account is what it is for. The useful rule is narrower: which fork, from whom, and whether a personal WhatsApp account should be paired to software at all. Baileys' README says its maintainers "do not in any way condone" use that breaks WhatsApp's terms. WhatsApp says linking an account to unofficial versions of WhatsApp violates its terms and may bring a ban, "now or in the past"; its pages name apps such as GB WhatsApp, not Baileys. For business messaging, Meta documents the WhatsApp Business Platform.

How big it is, and what the numbers do not say

The per-package column in OX's table sums to 490,189, matching its "about 490,000". One package, ourin-baileys, carries 130,589 of that (26.6 per cent) and the top five carry 67.5 per cent. Fifty-eight names are under 1,000 downloads and twenty show none. Downloads are registry requests, including mirrors, CI reinstalls and scanners; an account is followed only if a paired session runs the code. I could not reproduce OX's figures: npm's API today returns 578,108 lifetime for the 92 names it reports and 156,564 for the last month across 96, against OX's 116,000. Treat all of it as an order of magnitude.

The campaign is also larger than 101. SafeDep's page lists 82 Baileys-based names across 375 versions, plus 15 impersonators of the libsignal-node dependency. Only 10 of its 82 names are in OX's list, so the two vendors name 173 distinct Baileys packages between them (derived: 82 plus 101 minus 10). Xygeni's @dappaoffc/baileys-mod is in SafeDep's set.

OX says the campaign lacks the classic signatures, token theft and heavy obfuscation, so it can stay online longer than most malware. On 28 September it counted 85 names live and 16 removed. A day later the count of installable names had not moved, but the members had: one name went and one came back.

Status of OX's 101 names on the npm registry API, checked at 15:49 UTC on 29 September 2026.

State on the registry	Names	Note
Installable, latest version not deprecated	84	Includes `kasabaileys`, which OX listed as taken down; it was re-created on 29 September at 06:32 UTC with one version I did not analyse
Installable, latest version deprecated	1	`oktz-baileys`: "Package no longer supported"; the registry does not say who set it
Replaced by npm's security holding package	4	`@web2apk/baileys`, `dilxztech`, `kiki-baileys`, `saturn-bail`
Unpublished, name still on record	8	No installable version
Not found	4	Three OX lists as removed, and `@lendkzn/xntaabail`, which it listed as live

The eleven remote list files in OX's indicators, ten of them raw GitHub files, all still returned HTTP 200 at 16:00 UTC, and three hold a different number of entries from OX's counts of 24 September. That is the design working: the operator retargets the 19 packages that fetch a list without publishing to npm, so a blocklist of package names lags. It echoes malicious Terraform providers still live two days after disclosure, and disabled is not removed made the same point for GitHub Actions.

Detection coverage is thin where the downloads are. OSV holds malicious-package records for 18 of the 101 names. Of the five most downloaded, four have no OSV record and no GitHub malware advisory that I could find: ourin-baileys, @badzz88/baileys, @ostyado/baileys and levvleys, together 268,711 of OX's 490,189 downloads (54.8 per cent). OX says its own database holds every name; I cannot see it, so this describes two public feeds.

What nobody has stated

Stated and not stated across OX, SafeDep, Xygeni, WhatsApp, npm and GitHub, as read on 29 September 2026.

Question	Stated	Not stated
How many accounts were followed	Downloads per package (OX); follower totals for a sample of channels	Any count of forced follows or affected accounts
Who is behind it	Shared channels and lists (OX); different accounts and emails (SafeDep)	An actor. Indonesian sales content marks a beneficiary, not an attribution
Whether it paid	Channels advertise accounts, scripts and APKs	Any sale traced to a forced follower
Whether WhatsApp acted	Unofficial linking may bring bans in general	Any ban tied to these packages, or any statement from WhatsApp, npm, GitHub or the Baileys maintainers that I could find

How to check a project, lock installs, and what to do if a WhatsApp account was involved

In the order worth doing. The first two are searches you can run today; the third matters if they find something.

npm ls --all 2>/dev/null | grep -i -E "baileys|libsignal"
grep -n -i -E "baileys|libsignal" package-lock.json

The question that exposes the gap

A fork that follows a channel proves that any fork can act as the account it is paired to. The 101 names show a follow, and a public record of the behaviour sat there for 125 days before a report gave it a count. So the question for a security lead is not whether your projects hold one of the 101. It is who in your organisation can say which WhatsApp accounts are paired to which software, and, if a fork in that process had done more than follow a channel, what would have told you?