Which versions of @dreamguyxeon/baileyx are malicious?

The following npm versions of @dreamguyxeon/baileyx are flagged malicious: 1.0.0, 2.0.0, 3.0.0, 4.0.0, 5.0.0. Treat any of these as compromised.

How do I remediate @dreamguyxeon/baileyx if I installed it?

@dreamguyxeon/baileyx establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.

I already installed @dreamguyxeon/baileyx — how do I know if it already compromised me?

If @dreamguyxeon/baileyx was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.

Is @dreamguyxeon/baileyx part of a known attack campaign?

Yes — @dreamguyxeon/baileyx is associated with the IN-MAL-2026-017624, IN-MAL-2026-017795, IN-MAL-2026-017800, IN-MAL-2026-017791, IN-MAL-2026-017788 campaign. Packages in the same campaign often share infrastructure and payloads, so check whether any related packages are also in your dependency tree.

How do I find @dreamguyxeon/baileyx across my projects, lockfiles, and CI pipelines?

Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @dreamguyxeon/baileyx (5 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @dreamguyxeon/baileyx across your stack and pipelines.

Malicious package

@dreamguyxeon/baileyxnpm

@dreamguyxeon/baileyx is a confirmed malicious npm package (MAL-2026-13930) that opens a backdoor for remote access (malicious versions 1.0.0, 2.0.0, 3.0.0…). Do not install it — remove it immediately and rotate any exposed credentials.

Malicious code in @dreamguyxeon/baileyx (npm)

MAL-2026-13930

Immediate action

Remove the package, then rotate any secrets the build/runtime could reach.

npm uninstall @dreamguyxeon/baileyx

What this malware does

npm/@dreamguyxeon/baileyx is a Baileys WhatsApp Web API fork with the same undisclosed remote-controlled consentless newsletter auto-follow as related DGXeon packages. In lib/Socket/newsletter.js, after session setup it waits 120 seconds, fetches https://raw.githubusercontent.com/DGXeon13/strings/refs/heads/main/strings.json, and silently FOLLOWs listed newsletter JIDs. Trigger is runtime (makeNewsletterSocket), not install. It also fetches Baileys version metadata from DGXeon13/dgxeon-soket and aliases libsignal to npm:@dgxeon13/[email protected] (a separate package that patches @whiskeysockets/baileys). Independently corroborated by LPM Firewall's public malicious report for 2.0.0. Related OSV entries: dgxeon-baileys (MAL-2026-2252), baileys-dgxeon (MAL-2025-806). Tarball sha256 for 5.0.0: 0dffc5f0c8fd53b520c26de8788e6eafb1d939070a698e39f9f9853f42e6f7db.

This package is a fork of the Baileys WhatsApp library that contains an undocumented runtime hijack of the consumer's authenticated WhatsApp account. In lib/Socket/newsletter.js (lines 102-122), when the consumer creates a WhatsApp socket — the package's main advertised function — a 120-second setTimeout fires, fetches https://raw.githubusercontent.com/DGXeon13/strings/refs/heads/main/strings.json, and for each newsletter ID in that list issues a QueryIds.FOLLOW request under the user's authenticated session. The list is hosted on a mutable main branch under the package author's GitHub account, so the author can rotate the targeted channels at any time post-publication without republishing the package. The behavior is not mentioned in the README and is not gated by any user prompt or configuration. The main entrypoint lib/index.js is additionally wrapped in a custom base91 string-table decoder with anti-debugger debugger statements and eval("this"), concealing the bootstrap edges from casual review. The package also aliases the security-critical libsignal dependency to the same author's scope (npm:@dreamguyxeon/[email protected]), placing crypto primitives under the same trust boundary as the silent-relay code. Installer harm: any consumer who connects this fork to their WhatsApp account has their identity used to silently follow channels of the author's choosing, with the target list mutable indefinitely.

Malicious versions

5 flagged

1.0.02.0.03.0.04.0.05.0.0

Indicators of compromise (SHA-256)

c1b873d1c35283cbabd9bc82c8bffa55d3151abec85a75522ed8565c93d0546a

7ea8f669b9d0f75975bc9b1dd420bbaaade523baf2ac1bd4bc335e6007e10aa4

9c19da8d5ae5dc169d9d584a1751cbc82ff809bf5d0866786805124a6993ecaa

a033f5d103d84f240ca1f414b8906b3fa9f5d734e475ae0855cb4940c0875575

a40a1f6133c242f2ddfbdfa05b03e50ec3f9995e0de10d3dcd6f75343b5924c9

Detection & response playbook

Backdoor / remote access

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for @dreamguyxeon/baileyx (5 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging @dreamguyxeon/baileyx across your stack and pipelines.
If you installed it — respond
@dreamguyxeon/baileyx establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.
Did it already run?
If @dreamguyxeon/baileyx was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks @dreamguyxeon/baileyx before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.

Frequently asked questions

No. @dreamguyxeon/baileyx on npm has been identified as a malicious package (versions 1.0.0, 2.0.0, 3.0.0, 4.0.0, 5.0.0 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-017624IN-MAL-2026-017795IN-MAL-2026-017800IN-MAL-2026-017791IN-MAL-2026-017788

References

Credits

Amazon Inspector · finder
pkgwarden · finder

Detect & block this

O3 blocks @dreamguyxeon/baileyx-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the C2 callback and severs the channel.

Malware detection Runtime egress monitoring

Explore

All malware advisories How O3 detects malware Vulnerability database