Notifications
Clear all
Topic starter
20/08/2026 6:07 pm
TL;DR: A malicious npm package, @dappaoffc/baileys-mod, hid runtime code injection that subscribed authenticated WhatsApp bot sessions to attacker-controlled newsletter channels after an 80-second delay, according to Xygeni. The case shows why install-time scanning is insufficient when dependency abuse shifts into runtime control flow and trusted internal APIs.
NHIMG editorial — based on content published by Xygeni: analysis of a malicious npm package hidden in a Baileys fork
Questions worth separating out
Q: What fails when install-time scanning is the only control for malicious npm packages?
A: Install-time scanning fails when malicious code is embedded in module logic that executes only after load.
Q: Why do authenticated non-human sessions increase supply chain risk?
A: Authenticated non-human sessions increase risk because compromised code can inherit legitimate access instead of stealing it.
Q: How do security teams detect malicious behaviour hidden in third-party libraries?
A: Security teams should combine provenance signals with runtime indicators.
Practitioner guidance
- Inspect module execution, not just lifecycle scripts. Require full-source analysis of dependency bodies, including immediately invoked functions, delayed execution logic, and internal API misuse.
- Restrict runtime egress from third-party libraries. Block or alert on dependency-originated outbound calls to raw content hosts, paste services, and unapproved control endpoints.
- Classify bot sessions as governed identities. Apply action scoping, session observability, and revocation paths to authenticated non-human sessions used by automation bots.
What's in the full article
Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact runtime injection flow inside lib/Socket/newsletter.js and how the IIFE delays execution by 80 seconds
- The dependency alias and metadata indicators that helped the package impersonate the upstream project
- The full signal set used by Malware Early Warning, including the fetch call, control flow, and silent error suppression
- The guardrail policy ideas for CI/CD that detect suspicious dependency graph changes and unexpected outbound calls
👉 Read Xygeni's analysis of the malicious npm package hidden in Baileys forks →
Runtime npm package abuse: what it means for supply chain controls?
Explore further
20/08/2026 6:42 pm
Runtime package abuse is becoming a governance problem, not just a malware problem. When malicious code runs inside a dependency after load, install-time scanners miss the decisive moment of abuse. That shifts the control question from package approval to behaviour verification. NHI and application security teams should treat third-party code execution as an identity-adjacent trust decision, not merely a software hygiene issue.
A question worth separating out:
Q: What should organisations do when a dependency can control bot actions at runtime?
A: Treat the dependency as part of the trusted execution path and limit what the bot can do if the library misbehaves. Restrict outbound network access, constrain the bot’s action scope, and require rapid revocation paths for the session. If runtime code can drive privileged actions, the identity itself needs containment.
👉 Read our full editorial: Runtime npm package abuse shows why install-time scans miss malware
