Fake WhatsApp API Package on npm: How It Steals Chats (and How to Stop It)

The package (“lotusbail”) had significant download volume and remained available at the time of reporting—making this a high-signal reminder that software supply chain risk is now a default condition, not an edge case.

What happened (plain English)

A developer installs an npm library that claims to provide a WhatsApp API integration.

The library actually functions, so it passes quick functional testing.

While the app is sending/receiving WhatsApp messages, the package intercepts chats and authentication material, collects contacts and media, and sends it to an attacker-controlled server.

It also abuses WhatsApp’s “linked devices” behavior so the attacker’s device can remain connected to the victim’s WhatsApp account even after the package is removed—until the victim manually unlinks that device.

Why this matters beyond “one bad package”

Most malicious packages fail because they break builds or behave obviously suspiciously. This one is more dangerous because it sits in the “works as advertised” zone—exactly where teams lower their guard. Researchers noted the malware hides in the gap between “the code works” and “the code only does what it claims.”

For organizations, the impact is not limited to developer machines:

Customer-facing messaging risk: If WhatsApp is used for support, scheduling, or account workflows, message interception can expose sensitive conversations.

Account takeover and persistence: Linked-device hijacking means compromise can outlive the original infected environment.

Credential and token exposure: Captured tokens/session keys shift this from “data leakage” into repeatable access.

How the attack works

Researchers describe two core mechanisms:

Traffic interception via a wrapped WebSocket client

WhatsApp Web integrations rely on WebSockets. The malicious package wraps that client so messages and authentication artifacts pass through attacker-controlled code, enabling capture and exfiltration.

Persistence via device linking hijack

During the normal authentication flow, the package triggers a device-linking path using a hard-coded pairing approach described by researchers, silently linking an attacker device to the account. Removal of the library does not automatically remove the linked device.

It also included anti-debug behavior designed to frustrate analysis by freezing under debugging conditions.

What to do now (InfoSight perspective: reduce blast radius, then reduce probability)

1) Contain: assume exposure if this package touched production

If “lotusbail” was installed anywhere in your SDLC (dev laptops, CI runners, build images, containers), treat it like a credential compromise event:

Rotate secrets potentially accessible to that environment (API keys, service tokens, CI creds).

Inspect outbound connections from build/runtime to unknown hosts around the time of WhatsApp integration activity.

Review WhatsApp linked devices and remove anything unrecognized. WhatsApp documents the unlink process under Linked devices.

2) Verify: don’t rely on “download count = safe”

This case explicitly shows popularity signals can be manufactured or misleading, and functional code can still be malicious.

Minimum control set for teams building with Node.js:

Lock dependencies (lockfiles), pin versions, and block unexpected upgrades.

Enforce allowlists for new packages and new maintainers on critical integrations.

Require automated software composition analysis (SCA) in CI plus runtime egress monitoring for unexpected destinations.

Maintain an SBOM for externally facing services so you can answer “where is this dependency deployed?” in minutes, not days.

3) Prevent: treat messaging integrations as “sensitive identity plumbing”

WhatsApp integrations often become an authentication-adjacent channel (OTP links, customer support identity verification, account recovery conversations). That means:

Segment the service handling messaging integrations.

Restrict token scope and lifetime.

Store no more message content than necessary.

Monitor for anomalous session behavior and unusual linked-device changes where feasible.

The broader pattern: npm is not alone

The same reporting cycle highlighted malicious packages in other ecosystems (NuGet) impersonating legitimate developer libraries, including cases targeting crypto transfers and OAuth credentials. The technique is consistent: look legitimate, behave correctly, then trigger malicious behavior under real usage conditions.

Bottom line

This incident is a clean example of modern supply chain tradecraft: keep the features, add the theft, and persist through a legitimate platform behavior (linked devices). If your org builds software, “dependency risk” is operational risk—managed with engineering controls, monitoring, and incident playbooks, not awareness posters.

Source