Security researchers at OX Security have identified 101 npm packages that silently enroll developers into spam WhatsApp groups the moment the package is installed — no prompt, no consent. Together the packages have been downloaded roughly 490,000 times, with 116,000 of those downloads in the last month alone. The campaign, dubbed PhantomSub, abuses Baileys, a popular open-source library developers use to automate WhatsApp from their own code.
The packages present themselves as ordinary Baileys forks or related utilities, but run code during installation that adds the victim's WhatsApp account to promotional groups — researchers traced several back to Indonesia-based operators advertising game accounts and bot-building services. Three technical variants were found: some fetch the list of groups to join from a GitHub repository at runtime, some hardcode the group IDs directly in the source, and others hide them with encoding. Sixteen of the packages have already been removed from npm; the rest remained live as of OX Security's 29 September report. Smaller, earlier sightings of the same technique were logged by SafeDep and Xygeni Security back in August, before this research tied the full scope of the campaign together.
What this means for your business
If your development team — in-house or a contractor — builds with Node.js and npm, this is a same-week check, not a someday one. Have whoever manages your codebase search every project, including ones not actively maintained, for any dependency with "baileys" in its name, and cross-check against the package list in OX Security's report. A compromised package doesn't need to look suspicious; several of these mimicked legitimate forks closely enough to pass a casual glance. If you find one, remove it, rotate the WhatsApp account's session, and review its group list for anything you didn't join yourself.
The wider lesson applies to any business that builds or commissions software: open-source package registries like npm have no vetting gate — anyone can publish anything under almost any name. A brief dependency review before each release, and favouring packages with an established maintainer history over brand-new forks, costs far less than cleaning up after a malicious one slips through.