MAL-2026-19219: Malicious code in @wanzforme/bails4u (npm)
--- -= Per source details. Do not edit below this line.=-
Source: amazon-inspector (7db6d4bfe675bbaa2043f2958993761070ab6e5a09572d884082465b51bdf437) package.json declares a runtime dependency libsignal with the source github:wanzchil/libsignal-node. The reference has no commit SHA, tag, or integrity hash, so npm install resolves whatever the referenced repository's default branch currently contains and executes any lifecycle scripts bundled with it on the installer's machine. The owner of wanzchil/libsignal-node can push new commits at any time, and future installs will fetch and run those bytes with no version pin and no verification — fully bypassing the npm registry's integrity model for this dependency. A separate static match in lib/Utils/generics.js around a ping/HTTP pattern is consistent with WhatsApp/Baileys-style network utilities and is not independently indicative of malice.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Replace the unpinned github:wanzchil/libsignal-node dependency reference with a specific commit SHA and an integrity hash so installs cannot resolve and execute arbitrary content from the repository's default branch.
package.json dependency libsignal dependency source pinning and integrity verification = Pin github:wanzchil/libsignal-node to a specific commit SHA and verify it with an integrity hash
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems that run npm install for @wanzforme/bails4u and resolve its runtime dependency on github:wanzchil/libsignal-node are exposed. This includes developer workstations and CI/CD runners, because lifecycle scripts from the fetched dependency may execute during installation.
What does an attacker need to exploit it?
An attacker would need the ability to push commits to the wanzchil/libsignal-node repository's default branch. Future installs can then fetch the changed repository contents because the dependency reference has no commit SHA, tag, or integrity hash.
Are existing installations automatically affected?
The described risk applies to future dependency resolution and installation. The available data does not establish that an already installed copy has fetched malicious content.
What can be done if the package cannot be removed immediately?
Avoid reinstalling or updating the dependency while it points to an unpinned GitHub default branch. Use a reviewed, immutable dependency source with a specific commit SHA or otherwise prevent unreviewed repository changes from being resolved during installation.