January 2026

When “Trusted” Open Source Isn’t: Lessons from a Malicious npm Package Stealing WhatsApp Messages

Open source software is the backbone of modern application development. From cloud platforms to internal tools, organisations rely heavily on public code libraries to move faster and innovate at scale. But a recent discovery involving a malicious npm package called lotusbail is a sharp reminder that speed and trust can also introduce hidden risk.

This incident is not just about WhatsApp messages being stolen. It’s about how software supply chains are being quietly weaponised - and why organisations need to rethink how they manage cyber risk in development environments.

What Happened?

Security researchers recently identified lotusbail, a malicious npm package posing as a legitimate WhatsApp API library. At first glance, it appeared harmless:

• It worked exactly as expected

• It mimicked the popular @whiskeysockets/baileys library

• It had accumulated over 56,000 downloads

But underneath that legitimate functionality was a malicious wrapper designed to silently intercept and exfiltrate:

• WhatsApp authentication tokens

• Session keys

• Message history and media

• Contact lists

More concerningly, the package hijacked WhatsApp’s device-linking process, using a hard-coded pairing code to link an attacker-controlled device to the victim’s account. This gave the attacker persistent access to conversations, even after the package was removed.

To frustrate analysis, the malware also included anti-debugging logic that deliberately froze execution when inspection tools were detected.

In short: this was not crude malware. It was a deliberate, well-engineered supply-chain attack.

Why This Matters More Than the Malware

What makes this incident significant isn’t just the data theft - it’s how effectively it bypassed traditional trust signals.

Many organisations still equate “safe” open source with:

• High download counts

• Working functionality

• Community adoption

In this case, all three worked against defenders.

Because the malicious package delivered genuine WhatsApp functionality, static analysis and reputation-based controls were ineffective. The library didn’t break applications, raise obvious alarms, or behave noisily. It simply did its job - while quietly doing something else.

This reflects a broader trend Matrium sees across the threat landscape:
attackers are embedding themselves into trusted systems rather than attacking from the outside.

A Textbook Software Supply Chain Attack

This campaign aligns closely with well-documented software supply chain techniques highlighted by CISA and NIST, including:

Compromised Open-Source Code

Threat actors insert malicious functionality into public libraries that developers unknowingly integrate into production systems. This risk extends well beyond development machines into customer data, credentials, and communications platforms.

Trust Exploitation Over Exploits

Rather than relying on vulnerabilities, attackers exploit human trust in ecosystems—npm, PyPI, GitHub—where scale and convenience often outweigh scrutiny.

Limited Post-Compromise Options

Once a compromised dependency is deployed, organisations have little control over downstream exposure. Remediation becomes complex, reactive, and costly.

As CISA notes, this is precisely why prevention and governance matter more than rapid response in supply chain security.

What Should Organisations Take Away from This?

At Matrium, we see this incident as a reminder of several hard truths:

1. Popularity Is Not a Security Control

High download numbers and functional parity are not indicators of safety. They are easily manipulated and increasingly used by threat actors to build credibility.

2. Developers Are Now a Primary Attack Surface

Modern attackers understand that compromising software dependencies provides scale, persistence, and access that traditional perimeter attacks cannot.

3. Supply Chain Risk Is Business Risk

Incidents like this don’t stay confined to development teams. They impact customer trust, regulatory obligations, incident response costs, and brand reputation.

Strengthening Supply Chain Security

Frameworks like NIST Cyber Supply Chain Risk Management (C-SCRM) provide practical guidance that applies directly to incidents like this. Key practices include:

• Knowing and managing critical software components

• Understanding where third-party code is used

• Continuously assessing supplier and dependency risk

• Integrating security across the full software lifecycle

• Treating open source as production infrastructure, not free tooling

These practices aren’t about slowing development - they’re about ensuring speed doesn’t come at the cost of control.

Final Thoughts

The lotusbail incident is unlikely to be an outlier. It is a sign of where modern cyber risk is heading: quiet, embedded, and trusted by design.

Organisations that rely on software - especially open source - must assume that compromise can originate from inside their supply chain, not just outside their network.

At Matrium Technologies, we help organisations navigate this reality by aligning cyber risk, governance, and operational controls - whether through Essential Eight, NIST, or broader security strategy.

Because in today’s threat landscape, trust must be verified - especially when it comes packaged as code.