MAL-2026-19149: Malicious code in superlib_ex3 (npm)
Malicious package. superlibex3 is a multi-stage loader: on install it fetches and executes a second-stage payload from the attacker-controlled host x.exxcube.fr (the install hook was observed in dynamic detonation retrieving https://x.exxcube.fr/postInstall). No legitimate functionality; all published versions are malicious. Full indicators at the reference below.
--- -= Per source details. Do not edit below this line.=-
Source: amazon-inspector (bd1ec5b1f032d6879c69671f7c67499798ca134a341c87d69d310e2a36c6603b) superlibex3 advertises itself as a trivial hello-world library exposing a single hello() function, but its npm postinstall lifecycle hook performs an unconditional network fetch to the hardcoded URL https://x.aaaaa.fr/postInstall and writes the response bytes to ./postInstall.sh in the installer's current working directory. The destination host is unrelated to the package name, has no connection to any declared publisher, and the download is unpinned, unversioned, and lacks any hash or signature verification. The fetched content is a shell script staged under a filename that collides with lifecycle-script semantics on the installer's machine. The package has no documented reason to perform network I/O or stage shell scripts, and the fetched bytes can be changed by the operator of x.aaaaa.fr at any time without any change to the published package.
Affected Software
Event History
Frequently Asked Questions
Which installations are exposed to the malicious behavior?
All published versions are malicious. The package's postinstall hook runs during installation and unconditionally retrieves a second-stage payload from an attacker-controlled host.
What must an attacker do to trigger execution?
No separate attacker interaction is described: installing the package is sufficient for its lifecycle hook to fetch and execute the second-stage payload. The downloaded content is unpinned and has no hash or signature verification.
Is this limited to a particular application configuration?
No. The observed behavior is tied to the npm postinstall lifecycle hook and is described as unconditional, rather than dependent on use of the advertised hello() function or a specific runtime configuration.
How can I identify potentially affected environments?
Check dependency manifests, lockfiles, package caches, and installation logs for superlib_ex3. Also investigate network activity to x.exxcube.fr or x.aaaaa.fr and look for a postInstall.sh file written in the installer's working directory.