A Familiar Registry, a New Payload

Supply chain attacks against open-source package registries continue to evolve, and the latest example shows how attackers are pushing malicious logic beyond JavaScript and into compiled native code. Researchers have identified a malicious npm package called imgdecode that is tied to a broader software supply chain campaign tracked as MALFEX. According to reporting from The Hacker News, the package was published to the npm registry on September 30, 2026, by a user operating under the handle malfexteste8.

At the time of the report, imgdecode had been downloaded 979 times and remained live on npm—a reminder that malicious packages can persist on major registries even after public disclosure.

Why a Native Addon Matters

The defining characteristic of this package is not its JavaScript wrapper but what sits underneath it. imgdecode conceals a shellcode loader inside a Windows native addon. Native addons are compiled binaries (often .node files) that legitimate npm packages use to bridge Node.js with platform-specific C or C++ code. Because they execute as native machine code rather than interpreted JavaScript, they can be far harder for registry scanners and static analysis tools to inspect meaningfully.

That design choice is significant. Much of the ecosystem's automated defense against malicious packages relies on pattern matching, heuristics, and reputation signals applied to readable source. A compiled binary offers attackers a place to hide logic that traditional tooling may not flag or fully unpack. In this case, the addon reportedly acts as a loader for shellcode—code intended to be executed directly in memory, which can help an attacker evade file-based detection once the initial package is installed.

The MALFEX Campaign Context

imgdecode is described as part of the recently disclosed MALFEX campaign, which points to an organized, multi-package supply chain operation rather than an isolated prank or experiment. The account name used to publish the package (malfexteste8) reinforces that this is a coordinated effort with consistent naming conventions across its infrastructure.

Supply chain campaigns of this type typically follow a predictable arc: publish plausible-looking packages, sometimes with typosquatted or generic-sounding names, then wait for developers or automated dependency resolution to pull them in. The relatively modest download count here—under a thousand—does not diminish the risk. Small download numbers can still translate into meaningful exposure if the package is pulled into CI/CD pipelines, build environments, or developer workstations with broad network access.

The Native Code Blind Spot

This incident highlights a structural weakness in how the JavaScript ecosystem manages trust. Registries like npm are enormous and largely automated; human review of every package is impossible. Security teams often lean on tooling that inspects JavaScript for obfuscation, suspicious network calls, or install-time scripts. Native addons sit awkwardly in that model. They may be legitimate performance-critical components, but they also represent an opaque execution surface.

Organizations that permit native addons in their dependency trees should consider whether their software composition analysis (SCA) tooling actually inspects compiled binaries, and whether policies exist to flag packages that ship platform-specific binaries without a clear, reputable maintainer history.

Practical Guidance for Defenders

Security teams can reduce exposure to packages like imgdecode with a few concrete measures:

  • Pin and review dependencies. Avoid automatically consuming newly published packages in production builds, and prefer lockfiles with vetted versions.
  • Treat native addons as high-risk. Require additional review for any package that ships .node binaries or platform-specific compiled artifacts.
  • Monitor install-time behavior. Watch for unexpected process execution, network egress, or memory-resident payloads during npm install and build steps.
  • Audit developer environments. Build agents and developer machines often hold credentials and network access that make them attractive targets.
  • Use registry security signals. Enable alerts for malware advisories and maintain an inventory of approved packages and maintainers.

The Bigger Picture

The imgdecode case is a useful case study in how attackers adapt to defensive tooling. As JavaScript-level detections improve, malicious actors move their payloads into places that are harder to read—compiled binaries, install scripts, and in-memory execution paths. The MALFEX campaign's use of a Windows native addon to deliver shellcode shows that supply chain attacks are not simply about typosquatting names or stealing credentials; they are increasingly about delivering executable code through trusted developer workflows.

For defenders, the takeaway is clear: trust in a package registry is not the same as trust in a package. Every dependency, especially one with native components and a thin publication history, deserves scrutiny before it reaches a build pipeline.

Source: The Hacker News — MALFEX npm Package 'imgdecode' Hides Shellcode Loader in Windows Native Addon