Malicious npm package impersonating WhatsApp API silently hijacks accounts after 56,000 installs

Home » Python » Malicious npm package impersonating WhatsApp API silently hijacks accounts after 56,000 installs

A seemingly harmless npm package advertised as a WhatsApp Web API helper has been caught quietly siphoning chats, contacts and access credentials from unsuspecting developers and their users. The library, published under the name “lotusbail”, remained available for months on the official npm registry and managed to rack up more than 56,000 downloads before drawing serious scrutiny.

According to multiple independent write‑ups and a detailed investigation by Koi Security, the package behaves like a normal WhatsApp automation toolkit on the surface, but in the background it intercepts every message, collects account data and establishes a persistent backdoor to compromised WhatsApp accounts. Because the malicious behavior is woven into legitimate functionality, many projects could have integrated it without noticing anything obviously wrong.

How the fake WhatsApp Web API package slipped into npm

The malicious library appeared on npm around May 2025, uploaded by a user going by “seiren_primrose” and described as a convenient API to interact with WhatsApp Web. Under the hood, it is a fork of the popular open‑source project @whiskeysockets/baileys, a TypeScript/JavaScript library that offers a WebSocket‑based API for building bots and automations on top of WhatsApp Web.

By closely mirroring Baileys’ public interface and behavior, the threat actor ensured that developers could drop the package into existing workflows with minimal changes. Documentation and naming were crafted to look legitimate, reducing the chances that busy teams would question its origin, particularly given the way npm usage numbers often act as a proxy for trust.

Over roughly half a year, the package accumulated more than 56,000 total installs and hundreds of weekly downloads. During that time it remained searchable and installable from the official registry, effectively turning it into a quiet supply‑chain threat for any application that integrated WhatsApp functionality via JavaScript.

Researchers emphasize that nothing about the basic npm publishing process prevented this upload: any user can publish a package with a professional‑sounding name, copy the API of a known project and immediately gain visibility in the ecosystem. That reality is precisely what attackers leveraged in this case.

Abusing the WebSocket client to capture WhatsApp data

The core of the attack lies in how lotusbail wraps the legitimate WebSocket client that talks to WhatsApp’s web protocol. Instead of building a new interface from scratch, the package interposes a custom container around the standard Baileys WebSocket implementation, allowing every inbound and outbound message to pass through the malware first.

Koi Security’s analysis explains that once a developer authenticates with WhatsApp through this library, the wrapper immediately grabs authentication tokens and session keys. From that point on, every message that flows through the connection – incoming or outgoing – is transparently mirrored to the attacker’s infrastructure.

That mirroring extends beyond plain text chats. The package is engineered to exfiltrate message histories, contact lists and all attached media files, including photos, videos, audio clips and documents. In effect, it clones the user’s conversation environment: who they talk to, what they send and what they receive.

Crucially, none of this breaks the normal behavior that developers expect. The official functionality still appears to work properly, bots continue to respond, automations run as usual and WhatsApp sessions remain stable. The malware simply adds what one researcher described as “a second, invisible recipient for everything”, making detection by casual observation extremely unlikely.

All of this is triggered through ordinary use of the API. There is no need for the victim to run extra commands or enable special flags; authentication and routine message handling are enough to activate the spying capabilities, which is one reason the campaign managed to operate undetected for months.

Stealthy backdoor access: pairing the attacker’s device

Beyond data theft, lotusbail introduces a more insidious capability: it quietly pairs a device controlled by the attacker to the victim’s WhatsApp account. This leverages the same multi‑device pairing workflow that legitimate users rely on to connect additional phones or desktops to their account.

During the login process, the malware triggers a hidden pairing routine. Researchers report that the code generates an eight‑character random string and feeds it into WhatsApp’s device‑linking mechanism, hijacking the standard process with a hard‑coded pairing flow embedded in the malicious package.

Once that pairing completes, the attacker’s device effectively becomes another authorized client on the target account. From then on, threat actors can read and send messages, view contacts and access media as if they were the account owner – and they can do so without relying on the original, malicious package being present anymore.

This is what gives the attack its persistence. Even if a security‑conscious developer spots the suspicious dependency and removes it from the project, the compromise is not automatically undone. The malicious npm code may be gone, but the attacker’s linked device remains active until it is explicitly removed from WhatsApp’s list of trusted sessions.

Experts underline that this characteristic makes the incident more than a simple package‑level infection: it turns an npm misstep into a full account takeover that survives beyond cleanup, and it can continue to expose end users long after the vulnerable software has been updated.

What exactly the malware steals – and how it hides it

Technical notes from Koi Security and other researchers paint a detailed picture of the data being collected. The lotusbail package is programmed to harvest a variety of sensitive WhatsApp artifacts, far beyond just message bodies.

Among the targeted items are authentication tokens, session keys and pairing codes used to maintain the link between clients and WhatsApp’s servers. With those in hand, attackers can recreate or sustain sessions even if certain devices are rebooted or software is reinstalled.

The malware also pulls complete lists of contacts and group memberships, enabling threat actors to map a victim’s social graph, identify high‑value targets or pivot toward additional accounts. Combined with message content, this gives adversaries a broad view of relationships, business processes and private conversations.

Files exchanged over WhatsApp are similarly exposed. As the wrapper sees every WebSocket frame, it can capture metadata and payloads for photos, videos, voice notes and documents before they are decrypted and rendered by the client. That material is then prepared for exfiltration to attacker‑controlled servers.

To avoid straightforward detection at the network level, the package uses a full, custom implementation of RSA encryption. Before leaving the compromised environment, all captured data is encrypted locally, meaning that intrusion detection systems or network monitors that rely on deep packet inspection will see little more than opaque encrypted blobs moving to remote endpoints.

On top of that, the malware incorporates anti‑debugging defenses aimed at frustrating security analysts. Reports describe logic that detects common debugging or analysis scenarios and responds by pushing the code into an infinite loop, effectively locking up the process and making dynamic inspection much harder.

Persistent risk even after uninstalling the npm package

One of the more counter‑intuitive aspects of this incident is that removing the malicious dependency from a project does not automatically secure affected WhatsApp accounts. The persistent link created through the pairing process ensures that the attacker’s access survives uninstallation.

Security teams highlight that lotusbail takes advantage of how WhatsApp’s multi‑device model is designed: once a device has been successfully linked, it continues to receive messages and account updates until the owner manually revokes it in the app’s settings. There is no automatic timeout tied to the lifecycle of the npm package or the hosting application.

As a result, even diligent developers who identify and delete the library may leave their users exposed if they do not also instruct them to review the list of linked devices inside WhatsApp. Any unfamiliar session appearing in that list should be disconnected immediately.

Investigators stress that this nuance changes how organizations should think about remediation. It is no longer enough to purge malicious code from build pipelines and servers; incident response must also extend to the application ecosystem the code interacted with – in this case, the WhatsApp accounts that were tied to compromised sessions.

In practical terms, affected projects may need to notify users and rotate WhatsApp credentials, re‑establish sessions through known‑good tools and verify that no attacker‑controlled devices remain authorized on any account used in production or testing.

Who uncovered lotusbail and how it was investigated

The campaign came to light thanks to Koi Security, led by researcher Tuval Admoni, which published an in‑depth breakdown of the package’s behavior. Additional commentary from researcher Idan Dardikman helped clarify that the malware behaves as a transparent wrapper around the WebSocket client, activating as soon as normal authentication and message flows begin.

Admoni summarized the threat in blunt terms: the package steals WhatsApp credentials, intercepts every message, harvests contacts, installs a persistent backdoor and encrypts everything before sending it off to an attacker‑controlled server. That combination of stealth, breadth and persistence is what elevates this from a simple nuisance to a serious supply‑chain incident.

Static analysis alone proved inadequate to flag the risk. Because the codebase exposes the same interfaces and baseline behavior as legitimate libraries, reputation‑based signals such as download counts, star ratings or basic linting do little to distinguish it from genuine tooling. The package was able to live in plain sight despite its malicious additions.

Researchers also noted that anti‑analysis techniques built into the malware slowed down reverse engineering, requiring more careful instrumentation and sandboxing to fully map out its capabilities. By the time the report was published, the campaign had already enjoyed several months of operational time.

The case has quickly joined a growing list of npm‑based attacks that highlight how open package registries have become prime terrain for supply‑chain threats. While platforms can react by yanking known‑bad packages, the initial detection burden often still falls on independent security teams and vigilant developers.

Broader wave of supply‑chain malware targeting developers

The discovery of lotusbail coincided with disclosures about other malicious packages aimed at developer ecosystems, underscoring that this incident is part of a wider trend rather than a one‑off anomaly.

In parallel research, security firm ReversingLabs detailed a cluster of 14 rogue NuGet packages impersonating Nethereum and other cryptocurrency‑related libraries in the .NET world. Much like the WhatsApp npm case, these packages were designed to blend in with legitimate tooling used by developers working with blockchain and digital assets.

According to those findings, the NuGet packages redirected funds from cryptocurrency transactions to wallets controlled by attackers or silently extracted private keys and seed phrases whenever transfers exceeded 100 US dollars. Package names such as “binance.csharp”, “Bitcoin Core”, “bitapi.net”, “coinbase.api.net”, “googleads.api”, “nbitcoin.unified”, “nethereumnet”, “nethereumunified”, “nethereum.all”, “solananet”, “solnetall”, “solnetall.net”, “solnetplus” and “solnetunified” were crafted to evoke well‑known tools and services.

To build trust, the operators behind these libraries reportedly inflated download statistics and pushed frequent updates to simulate active maintenance and popularity. This social‑engineering layer echoes the way lotusbail relied on npm’s visibility and the reputation of the Baileys project to gain traction.

Experts from both research teams converge on the same point: supply‑chain attacks against developers are not fading; they are becoming more sophisticated. Adversaries have learned to target exactly the tools that engineers depend on every day, whether for messaging integrations, financial operations or general infrastructure.

Why conventional defenses struggle with npm supply‑chain threats

Lotusbail also highlights the limits of many current defenses used to protect software pipelines. Traditional approaches such as static code scanning, basic linting, simple signature checks and reputation metrics are often tuned to spot obvious red flags, but they can easily miss subtle malicious logic embedded in otherwise valid packages.

Because the library faithfully implements the expected WhatsApp Web API surface, automated tools may see nothing more than a slightly modified fork of a known‑good repository. Even manual spot checks might not immediately reveal the danger, especially when the harmful code is intertwined with legitimate networking and encryption routines.

Reputation‑based systems fare no better here. Many organizations subconsciously equate high download counts and frequent updates with safety, yet in this case those signals were either naturally accumulated over time or could be artificially bolstered by the attacker. Popularity does not guarantee integrity when anyone can publish a look‑alike package with a convincing description.

The anti‑debugging layer further complicates dynamic analysis. Once a package can detect that it is running under instrumentation or attached to a debugger and then trigger infinite loops or crashes, automated sandboxes struggle to obtain a complete behavioral profile. That, in turn, slows down signature creation and public disclosure.

These challenges point to a need for more robust, behavior‑oriented monitoring in production environments, where suspicious network flows, unexpected encryption patterns or anomalous data access can be flagged even if static checks initially approve a package.

What developers and organizations can do right now

Security specialists who examined the lotusbail incident stress that developers should treat third‑party packages as untrusted code, even when they come from major registries like npm. Practical steps can help reduce exposure to similar threats in the future.

First, teams are encouraged to verify the provenance of critical dependencies. That includes checking official documentation or repositories for recommended package names, validating publisher identities, and preferring libraries maintained by well‑established organizations or known maintainers whenever possible.

Second, experts recommend adding runtime monitoring and anomaly detection around sensitive integrations such as messaging APIs, payment modules or cryptographic tooling. Unusual outbound connections, unexpected encryption activity or data flows that do not align with documented behavior can be early signs of a compromised dependency.

Third, organizations should maintain an inventory of all third‑party packages in use and track changes over time. Pinning versions, reviewing changelogs and performing security assessments before major upgrades can help catch problematic code before it reaches production.

Finally, in cases where WhatsApp integrations relied on the malicious npm library, incident response should go beyond code cleanup. Affected users should be guided to open WhatsApp’s settings, inspect linked devices and remove any unknown sessions. Without that step, the attacker’s paired device may continue to have full access to conversations and content.

The lotusbail episode serves as a pointed reminder that trusting a package because it looks familiar, has thousands of downloads or mimics a popular project is no longer enough. With attackers increasingly targeting developer ecosystems, careful vetting of dependencies and close observation of runtime behavior have become essential parts of keeping WhatsApp accounts – and the applications built around them – truly secure.