By ByteBot
The lotusbail npm package has stolen WhatsApp credentials, intercepted messages, and harvested contacts from over 56,000 downloads since May 2025—and it’s still live on npm as of December 22, 2025. Disguised as a WhatsApp Web API library (a fork of the legitimate @whiskeysockets/baileys package), the malware survived six months undetected. The critical threat: uninstalling the package doesn’t remove the attacker’s access. Their device stays linked to your WhatsApp account until you manually revoke it in settings. If you’ve used lotusbail or any WhatsApp API library, check your node_modules and WhatsApp linked devices right now.
Why Lotusbail Is So Dangerous: Functional Malware That Actually Works
This isn’t broken code raising red flags. Lotusbail provides full WhatsApp API functionality—send messages, receive chats, handle webhooks—while silently stealing everything. The malware uses four layers of obfuscation: Unicode variable manipulation, LZString compression, Base-91 encoding, and AES encryption. Moreover, 27 anti-debugging infinite loop traps explain why it evaded detection for six months.
The persistent backdoor mechanism is what makes this truly dangerous. During authentication, the malware uses a hardcoded AES-encrypted pairing code to link the attacker’s device to your WhatsApp account. Even after you uninstall the npm package, the attacker’s device remains linked. Consequently, they retain full access—reading messages, viewing contacts, downloading media—until you manually unlink their device in WhatsApp settings. Most developers won’t know to check.
Functional malware is the new standard for npm supply chain attacks. When packages work exactly as advertised, developers have no reason to audit the code. The npm ecosystem’s scale—2 million packages, open registration, minimal vetting—makes automated detection nearly impossible. Lotusbail proves that obfuscation still works.
Complete WhatsApp Compromise: What Data Is Stolen
Lotusbail wraps the legitimate WebSocket client that communicates with WhatsApp servers, intercepting every message before and after encryption. The data captured includes authentication tokens and session keys, all message history (past messages from local cache plus every new incoming and outgoing message), complete contact lists with phone numbers and profile information, and all media files and documents shared through WhatsApp.
The exfiltration mechanism uses a custom RSA implementation to encrypt stolen data, applies the same four-layer obfuscation to hide server URLs in compressed payloads, and sends everything to an encrypted endpoint controlled by the attacker. For businesses running WhatsApp automation—customer support, marketing campaigns, sales outreach—this means total exposure of confidential conversations and customer data.
How to Check If You’re Affected (Do This Now)
Run this command to check your dependencies:
# Search package.json, node_modules, and package-lock.json
grep -r "lotusbail" package.json node_modules package-lock.json
# Check nested dependencies
npm list | grep lotusbailThen check WhatsApp linked devices. Open WhatsApp on your phone, go to Settings → Linked Devices, and look for any device you don’t recognize. Pay attention to device link dates—anything from May 2025 onward is suspicious. The attacker’s device won’t have an obvious name; it’ll look like a normal browser or desktop client.
If you find lotusbail in your dependencies or unknown devices in WhatsApp, take immediate action. Unlink all unknown devices in WhatsApp settings. Log out of ALL browsers and desktops, then re-link only devices you personally own. Furthermore, remove lotusbail from your package.json and delete node_modules. Run npm audit to check for other malicious packages. Rotate any credentials or secrets that existed in the environment where the compromised package ran. The uninstall alone doesn’t fix this—the manual WhatsApp device unlink is non-negotiable.
The Bigger Problem: npm’s 2025 Supply Chain Meltdown
Lotusbail isn’t an anomaly. It’s part of a pattern. September 2025 saw 18 widely-used packages—chalk, debug, ansi-styles, strip-ansi—compromised via maintainer account hijacking, affecting 2.6 billion weekly downloads. The Shai-Hulud worm campaign in November infected 25,000+ repositories with self-propagating malware that spread at roughly 1,000 new repos every 30 minutes. Additionally, December’s “elf-” wave detected nearly 1,000 suspicious packages in a single week. CISA issued government-level security alerts for the September attack.
All these campaigns share common traits: multi-layer obfuscation to bypass automated scanning, credential theft targeting GitHub tokens and cloud provider access keys, long undetected periods (lotusbail lasted six months), and sophisticated attack mechanisms that exploit developer trust. npm’s security model—open registration, minimal package vetting, no mandatory malware scanning—can’t scale to 2 million packages. The ecosystem needs fundamental changes: mandatory behavioral analysis, code signing requirements, and automated malware detection that can spot obfuscated threats.
Fork-jacking is becoming the dominant attack vector. Lotusbail forked the legitimate @whiskeysockets/baileys package, maintained 100% original functionality, added malware hidden by four layers of obfuscation, and published with a similar-sounding name. npm search shows dozens of Baileys forks—baileys-pro, @iamrony777/baileys, @fizzxydev/baileys-pro. Which ones are safe? Without source code audits, you can’t tell. Developers installing forks for specific features or bug fixes are playing Russian roulette.
What Developers Need to Do Differently
Treat every npm package as untrusted by default. Pin exact dependency versions in package-lock.json and audit changes before updating. Check WhatsApp and other service linked devices regularly—make it a monthly security task. Run npm audit frequently, but understand it only catches known vulnerabilities. Use tools like Socket.dev or Snyk that analyze package behavior at install time. For critical applications, consider vendoring dependencies or using private registries with manual vetting.
The lotusbail attack proves that uninstalling compromised packages isn’t enough. Persistent access mechanisms—linked devices, stolen credentials, backdoor accounts—survive cleanup. After any npm compromise, rotate all secrets, audit service linked devices, review authentication logs for unauthorized access, and check for unexpected API keys or webhook configurations. Assume breach, verify recovery.
npm supply chain security is broken at a fundamental level. Until the ecosystem implements mandatory scanning, code signing, and better fork verification, every dependency is a potential threat. Lotusbail’s six-month undetected run and 56,000 downloads aren’t a failure of developers—they’re a failure of npm’s trust model. Check your dependencies. Check your WhatsApp. Do it now.
