oktz-baileys npm malware makes WhatsApp accounts follow a hardcoded channel

What happened

GitHub published advisory GHSA-wmf5-rghr-gxcf on 2026-11-06. It classifies the npm package oktz-baileys as malware. The package is a fork of the Baileys WhatsApp Web library. According to the advisory, it quietly makes the installer's own authenticated WhatsApp account follow a WhatsApp Channel picked by the package author.

The finding comes from a static review of the published 9.1.6 tarball on 2026-10-16. The tarball was not executed. The review found a hardcoded channel JID, 120363400911374213@newsletter. It also found a channel-follow request set to fire on its own once the socket connects. Errors from that request are swallowed, so nothing surfaces to the developer.

The OpenSSF record, MAL-2026-18712, attributes the package to the campaign OX Security documented as "PhantomSub". It also describes the package as the same family as MAL-2026-4519, a record covering chromestaff-baileys 1.1.3 that has since been withdrawn. The evidence does not say why it was withdrawn.

As of 2026-10-16 the package was still live on npm and had no OSV record. The structured advisory marks all versions above 0 as affected and lists no patched version. It rates the record critical, with a CVSS score of 0.

Why it matters

Baileys runs with a live, authenticated WhatsApp session. A fork therefore inherits whatever that session is allowed to do. Here the reported payload is small: one follow call to a fixed channel. The more important point is that the library already holds the session, so it needs no exploit, privilege escalation or install script to act as the account.

The teams affected are those building WhatsApp bots, customer-messaging integrations or notification services on Baileys. If one of them picked this fork, the business number linked to that service may now follow a channel nobody chose. For organisations in regulated sectors, such as healthcare or government messaging, an unauthorised account action is a governance issue in its own right, whatever the immediate harm.

The critical label overstates what has actually been observed. The evidence describes no credential theft, no data exfiltration and no behaviour beyond the follow call. It also does not rule those out.

Engineering assessment

Our assessment: this is a real supply-chain compromise with limited observed impact, and the label exaggerates that impact. Treat it as high priority, not as an emergency.

The observed behaviour is account abuse, not system compromise. A hardcoded follow call that runs on connect and hides its own errors is built to grow a channel's audience quietly. Nothing in the evidence suggests it reads environment variables, touches the filesystem or sends session material anywhere. On the evidence available, hosts running this package are not shown to be compromised; what has been misused is the linked WhatsApp identity.

Two cautions limit that conclusion. First, the review was static and covered only version 9.1.6. Other versions are flagged but not described, and runtime behaviour was not observed. Second, code that can send a follow request through an authenticated session can, in principle, send other requests too. The trust problem is not the follow call itself; it is that a fork of unknown origin had full use of the session.

The structural lesson is direct. At least two Baileys-named forks are linked in this record: oktz-baileys, attributed to PhantomSub, and chromestaff-baileys, described as the same family in a record that was later withdrawn. Pin Baileys to a source whose publisher and code you have reviewed, and treat any library that holds a messaging session as privileged code that needs review before it is added or swapped.

The advisory leaves cleanup open. Uninstalling the package stops future follow calls, but nothing in the evidence suggests it reverses a follow that has already happened. That has to be checked on the WhatsApp account itself.

Is this you?

• Your Node.js project, or any dependency, resolves oktz-baileys at any version.
• You run a WhatsApp bot or messaging integration built on a Baileys fork rather than a source you have checked.
• A WhatsApp account linked to one of your services follows a channel nobody on your team chose.
• As a precaution only: your lockfile contains chromestaff-baileys (the withdrawn record named version 1.1.3). It is not confirmed malware on current evidence, but it is worth a review.

To check a project:

npm ls oktz-baileys chromestaff-baileys
grep -E "oktz-baileys|chromestaff-baileys" package-lock.json yarn.lock pnpm-lock.yaml
grep -rl "120363400911374213" node_modules

What to do

1. Remove it now. There is no fixed version, so upgrading is not an option. Uninstall oktz-baileys from every project and image, then rebuild from a clean lockfile.
2. Replace it with a reviewed source. Move to a Baileys source whose publisher and code you have checked. Test connection, reconnection and message flows before deploying.
3. Check the linked account. On every WhatsApp account that ran the package, look for a followed channel nobody chose and unfollow it manually. Not vendor guidance; no official remediation steps are published.
4. Consider re-linking the session. As a precaution, log out the linked device and pair it again with the clean build. Not vendor guidance; the review covered one version statically and cannot rule out other behaviour.
5. Block it in CI. Add oktz-baileys to a dependency denylist or audit gate. For chromestaff-baileys, whose record was withdrawn for reasons the evidence does not give, a denylist entry or manual review is a cautious precaution. Not vendor guidance for chromestaff-baileys.
6. For technical leads: list every service that holds an authenticated messaging session and record where its client library comes from. Require review before any new fork is introduced. Teams building messaging into web platforms should treat these libraries as privileged code. Not vendor guidance.

What we don't know yet

• Whether the package can still be downloaded from npm today. The evidence only confirms it was live on 2026-10-16.
• How many installs or dependents it has.
• Whether versions other than 9.1.6 behave the same way, or whether any version does more than follow the channel.
• How to detect and reverse the subscription, beyond checking the account manually.
• Why the MAL-2026-4519 record for chromestaff-baileys was withdrawn.
• Why the GitHub advisory appeared on 2026-11-06, three weeks after the OpenSSF analysis, and whether the package was taken down in between.
• Whether other Baileys forks belong to the PhantomSub campaign.

The desk will follow the npm listing and the OpenSSF record and update this piece if any of these questions are answered.

Sources

• github.com
• github.com