Building This Into How You Install Dependencies Going Forward<\/a><\/li>\n<\/ul>\n<\/nav>\n<\/div>\nWhat makes this campaign worth understanding in detail rather than just noting as “another bad npm package” story: the malicious behavior activated during a routine install, with no further action required from the developer. Once a project authenticated its own WhatsApp bot session through one of these packages, that session got silently used to add the developer’s WhatsApp account to attacker-controlled groups and channels, mostly advertising bot-building services, in-game currency, and mobile game accounts, concentrated on Indonesian markets based on the channels researchers identified.<\/p>\n
A Campaign That Ran for a While Before Anyone Noticed<\/h2>\n
The download numbers tell their own story about detection speed. If 116,000 of the roughly 490,000 total downloads happened in just the most recent 30 days, the remaining 374,000, over three-quarters of the total, accumulated before that final month, meaning this collection of packages was quietly installing itself into projects for a sustained period before the campaign was identified and reported. That’s consistent with how supply-chain attacks on package registries tend to play out: there’s no equivalent of a antivirus definition update that catches a brand-new malicious package on day one, so a campaign built around plausible-looking fork names can accumulate a real install base before anyone specifically goes looking for it.<\/p>\n
Three Baileys Variants, Three Different Levels of Effort to Detect<\/h2>\n
The researchers broke 93 of the 101 packages into three technical approaches, and the differences matter for anyone thinking about how a scanner would or wouldn’t have caught this. Nineteen packages fetched their target channel IDs from GitHub at runtime, meaning the malicious destination wasn’t even fixed in the package code itself, just a pointer to wherever the attacker’s GitHub repo said to go that day. Sixty packages, the majority, embedded the channel IDs directly in plaintext source, the easiest variant for a static scanner or a manual code read to catch, since the actual malicious string is sitting in the open.<\/p>\n
Fourteen used encoded and obfuscated embedded IDs, splitting the difference: no runtime fetch to flag as suspicious network activity, but also not a plaintext string a simple grep would catch.<\/p>\n
That spread is a useful reminder that “I scanned the package and didn’t see anything obviously wrong” isn’t a uniform guarantee across all three approaches. A plaintext scan catches the 60-package majority easily, but the runtime-fetch and obfuscated variants need a closer look at what the package actually does at install or run time, not just what strings are visible in its source.<\/p>\n
Why ‘It’s a Popular Library’s Fork’ Isn’t a Safety Signal<\/h2>\n
The core lesson generic to any package that presents itself as an alternative or fork of something legitimate: the fact that a project is a fork of a well-known, trusted library tells you nothing about whether the fork itself is trustworthy. A fork can be a completely independent codebase with a new maintainer and no actual code-level relationship to the original beyond the name and README positioning.<\/p>\n
Before installing anything presenting itself this way, a few concrete checks take less time than dealing with the aftermath: run npm view <package-name><\/code> and check who actually published it and when, compare that against the real upstream project’s own GitHub repository activity (does the claimed fork actually show up as a fork or contributor there, or does it only claim the relationship in its own README), and check whether the package has any npm provenance attestation (packages published with provenance show a verified build-and-publish pipeline tied to a specific public source repository, which a hastily-published malicious fork typically doesn’t bother setting up).<\/p>\nWhat to Check If You’ve Already Installed Something From This List<\/h2>\n
If a project on your own server has installed any package built around Baileys or presenting itself as a WhatsApp bot library, it’s worth specifically checking the WhatsApp account or number that bot session is tied to for group or channel memberships that weren’t deliberately joined, since that’s the actual, visible symptom of this specific campaign. Removing the package and rotating the bot’s session credentials afterward is the direct fix; simply leaving unwanted group memberships in place doesn’t undo whatever access the attacker’s package already had during the time it was installed.<\/p>\n
Why This Specifically Targeted a Messaging Library, Not a Generic Utility<\/h2>\n
It’s worth noting why WhatsApp-automation libraries make an attractive target for this kind of campaign specifically, rather than it being an arbitrary category to typosquat. A package that legitimately needs to authenticate a real messaging session is already asking a developer to trust it with exactly the kind of access, session tokens tied to a real personal or business account, that has direct value to an attacker, and that a developer installing it has already mentally approved as a reasonable thing for the package to need.<\/p>\n
That built-in trust is what made a malicious fork’s authentication request look unremarkable rather than suspicious, the same request a legitimate Baileys install would also make. Packages in categories that inherently require sensitive authentication (messaging, payment, cloud-account automation) deserve a correspondingly higher bar for verifying the maintainer before installing, compared to a package that’s just doing string formatting or date parsing with no real access to anything sensitive.<\/p>\n
Building This Into How You Install Dependencies Going Forward<\/h2>\n
On a self-managed VPS or dedicated server, where you have full root access and nobody else is vetting what gets installed, dependency hygiene is entirely on the account holder. A lockfile (package-lock.json or equivalent) pinned to specific, already-reviewed versions prevents an automatic minor-version bump from silently pulling in a compromised update to a package that was clean when first installed. Running npm audit<\/code> regularly catches known-bad packages already reported to npm’s advisory database, though it won’t catch a brand-new campaign before it’s been flagged, which is exactly the window this campaign operated in before discovery.<\/p>\nFor any project handling something as sensitive as an authenticated messaging session, treating a “fork” or “alternative” of the real library with the same scrutiny as an unfamiliar package entirely, rather than borrowed trust from the original project’s reputation, is the one habit that would have stopped this specific campaign at the install step, before any of the 490,000 downloads ever ran.<\/p>\n
Related reading: A Malicious npm Package Posed as a Twilio Bug-Bounty Tool. Here’s What Developers Should Check<\/a> and 14 Trojanized npm Packages Are Dropping a Linux Backdoor<\/a>.<\/p>\nFurther reading: npm Docs: npm audit<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"A Normal npm Install Was the Entire Attack A campaign researchers are calling PhantomSub placed 101 malicious packages on npm, collectively downloaded\u2026<\/p>\n","protected":false},"author":2,"featured_media":1364,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"rank_math_title":"Baileys npm Packages: 101 Fakes Hijacked WhatsApp Sessions","rank_math_description":"101 fake Baileys forks on npm hijacked WhatsApp sessions at install. How the PhantomSub campaign worked and how to vet a package before adding it.","rank_math_focus_keyword":"baileys, malicious npm packages whatsapp, baileys npm security, npm supply chain attack","rank_math_canonical_url":"","rank_math_robots":[],"footnotes":""},"categories":[10],"tags":[],"class_list":["post-1365","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/posts\/1365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/comments?post=1365"}],"version-history":[{"count":4,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/posts\/1365\/revisions"}],"predecessor-version":[{"id":1778,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/posts\/1365\/revisions\/1778"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/media\/1364"}],"wp:attachment":[{"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/media?parent=1365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/categories?post=1365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/allcloudhost.net\/blogs\/wp-json\/wp\/v2\/tags?post=1365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}