MALFEX imgdecode npm Package: Native Windows Loader

SafeDep's analysis of the imgdecode package describes a MALFEX-linked npm package that moved malicious loader behavior from visible JavaScript into a compiled Windows native add-on. The package presented itself as an image-decoding utility. Its small JavaScript entry point loaded a .node binary; the consequential behavior was inside that native module, not obvious from the package name or README.

SafeDep examined versions 1.0.0 through 1.0.3, published by npm account malfexteste8. In versions 1.0.1 onward, requiring the module could trigger the loader during native module initialization. The analyzed behavior was conditional on an interactive Windows console. SafeDep reported that the module attempted to retrieve an encrypted file from GitHub and inject the decrypted content into a dllhost.exe process. We intentionally omit the payload URL, cryptographic material, and execution recipe; responders can retrieve indicators from the researcher's report.

SafeDep connected the package to the broader MALFEX campaign through shared staging and related recovered artifacts. It did not recover the specific banner.jpg payload requested by imgdecode, so it could not confirm that this exact loader delivered the same stealer/RAT payload found in a related chain. Similar campaign infrastructure is meaningful evidence, but it is not proof that every branch delivered an identical payload.

Why ordinary dependency review can miss this

The package name and README are not behavior. The advertised exec() API did not match the package's actual export in the analyzed 1.0.3 package.
Install-time checks are not enough. The package did not need a conventional post-install hook for the native add-on to execute code when an application later required the module.
Native code is less transparent in a source diff. Reviewers may see a short JavaScript wrapper while the compiled binary performs network and process operations.
Runtime conditions change detection. The reported loader behavior depended on Windows and an interactive console, so an ordinary CI run with redirected output might not exercise it.
Dependency removal does not remediate an executed payload. A lockfile change prevents future resolution but does not establish whether a workstation already loaded the module.

The npm registry record for imgdecode showed 1.0.3 as the latest published version when reviewed on October 18, 2026. Registry availability can change quickly. Check the current record and your own lockfiles during response rather than assuming the package is still available or has been removed.

Response if the package is in your dependency graph

Find direct and transitive references without installing the package. Search package.json, lockfiles, workspace manifests, SBOMs, build artifacts, package caches, and dependency inventories for imgdecode and the reviewed versions. Preserve the original lockfile and package metadata.
Identify whether it was loaded. Correlate package presence with Node.js process history, module resolution or application logs, endpoint telemetry, interactive Windows sessions, and the time the affected build or tool ran. Presence in a lockfile is exposure potential, not proof of code execution.
Isolate and investigate systems where it ran. SafeDep advises treating Windows workstations that loaded the package as potentially compromised. Preserve endpoint evidence and investigate child processes, unexpected dllhost.exe activity, network connections, persistence, and credential access before rebuilding.
Rotate credentials from a clean environment. Prioritize npm publishing tokens, source-control credentials, cloud secrets, and developer or CI credentials that may have been available to the affected host. Revoke active sessions and tokens according to your incident procedure.
Remove the dependency through a reviewed change. Rebuild from a clean environment with a known-good lockfile and trusted artifacts. Do not treat deleting node_modules or updating a transitive package as proof that the endpoint is clean.
Harden package intake. Pin and review new dependencies, generate SBOMs, monitor publisher and package changes, restrict install/build egress, review native add-ons, and add runtime controls for unexpected child processes and network access.

Evidence boundaries

Question	Finding
Which package and versions?	SafeDep analyzed npm `imgdecode` 1.0.0–1.0.3.
What was the trigger?	Requiring the module loaded the Windows native add-on; the analyzed later versions ran behavior during module initialization.
Did it run on every platform or environment?	SafeDep describes a Windows and interactive-console condition, not universal execution.
Was a stealer payload recovered from this exact URL?	No. SafeDep says it did not recover the `banner.jpg` requested by this loader; the exact payload linkage remains unconfirmed.
Does package presence prove compromise?	No. It establishes a dependency to investigate; execution and host impact need evidence.

This is a dated research snapshot based on SafeDep's October 13, 2026 analysis and npm registry metadata reviewed on October 18. Recheck package status and the researcher's current indicators during incident response.

Trace the package from dependency to execution

Package investigations often stop at the lockfile. That is only the first point in the chain. For imgdecode, the important question is whether a build or application actually loaded the module in the reported Windows console condition.

Stage	Evidence to review	What it means
Resolution	Manifest, lockfile, workspace configuration, SBOM, and package cache	The project could resolve or retain the package; this does not prove it ran.
Installation	Build logs, package-manager logs, and the installed package contents	The package reached an environment; this does not prove the native module was loaded.
Import	Node.js process history, application logs, and endpoint telemetry for module loading	The runtime may have initialized the `.node` add-on. Correlate operating system and console conditions.
Follow-on activity	Child-process, network, file, and persistence telemetry	These records can support or rule out subsequent behavior, subject to log coverage.

Do not test the package by importing it on a developer workstation. If analysis requires opening the artifact, use an isolated environment with no production credentials, restricted egress, snapshots, and a clean recovery path. Review the JavaScript wrapper and native binary as separate artifacts. A source-only diff may not expose behavior compiled into a .node file.

Strengthen npm intake without relying on install hooks alone

Review packages before they enter a build environment. Compare the declared API with the actual exports, inspect native add-ons and their platform conditions, record package integrity and publisher changes, and require a documented reason for adding a binary dependency. Build workers should receive only the secrets and network access required for that job. Runtime monitoring should distinguish the expected Node.js process tree from unexpected child processes or network destinations.

Package reputation and vulnerability scanners can help prioritize review, but a clean result does not prove that a package is benign. The relevant controls are provenance, artifact inspection, dependency approval, restricted build execution, and host-level evidence after use.

Questions about the `imgdecode` npm package

Does having imgdecode in a lockfile prove an endpoint was compromised? No. It shows a dependency to investigate. Establish whether it was installed, imported under the reported conditions, and followed by suspicious activity.

Would disabling npm install scripts have prevented this behavior? The reported trigger was loading the native module when the application required it, not only a conventional install hook. Review runtime imports and native dependencies as well as install scripts.

Related reading: Axios npm supply-chain attack analysis.