Three-Year NPM Supply Chain Campaign Hits 40,000 Downloads

MALFEX Campaign Spans Three Years, Eight Packages

A long-running malicious code campaign on the npm registry, tracked under the name MALFEX, has accumulated roughly 40,000 downloads since it began in August 2023, according to a report from SecurityWeek published October 6, 2026. The campaign involves eight malicious packages published to npm, the primary package manager for JavaScript and Node.js projects used by millions of developers worldwide.

Npm, short for Node Package Manager, is the default package registry and command-line tool for distributing open-source JavaScript libraries. Developers pull packages from it to add functionality to their applications without writing that code themselves. Because any registered user can publish a package, npm has become a recurring target for attackers who disguise malicious code as legitimate utilities, hoping developers or automated build pipelines install it by mistake.

The reported three-year runtime stands out. Most publicized npm malware incidents are detected and removed within weeks of publication. A campaign that persisted from 2023 into 2026 across eight separate packages suggests the operators were either slow to draw attention, actively evaded automated scanning, or both. The 40,000-download figure represents cumulative installs, not necessarily unique organizations or active deployments, but each download reflects at least one build process, developer machine, or CI/CD pipeline that pulled the package's code.

Why Long-Running NPM Campaigns Are Hard to Catch

The specific technical payload of the MALFEX packages has not been detailed in the available reporting. The pattern does fit a category of open-source supply chain attacks security teams have tracked for years. Attackers typically rely on typosquatting (publishing a package with a name similar to a popular library), dependency confusion (exploiting naming overlaps between public and private registries), or compromised maintainer accounts to get malicious code installed. Once installed, these packages often run automatically through install scripts, giving attackers code execution on the host machine before a developer ever reviews the code.

The npm registry, operated by npm, Inc., a subsidiary of GitHub, relies on automated scanning and community reporting to catch bad packages. GitHub maintains the GitHub Advisory Database as a public record of known vulnerable and malicious packages across ecosystems including npm. The Open Source Security Foundation, an industry group focused on securing the open-source supply chain, has repeatedly flagged install-time scripts and low-reputation maintainer accounts as high-risk signals that automated tooling should weigh more heavily. A package surviving three years and multiple variants before wide reporting suggests gaps remain between how fast malicious packages can be published and how fast they get flagged.

What This Means for Healthcare Practices, Tax Firms, and Small Businesses

Most readers of this site are not JavaScript developers, but many run patient portals, booking systems, tax-prep software, or e-commerce platforms built on web applications that depend on npm packages somewhere in the stack. A compromised dependency can reach a healthcare practice's scheduling system or a tax firm's client portal without anyone on staff writing a single line of vulnerable code; the risk arrives through a vendor's or contractor's software supply chain.

If you outsource web or app development, ask your vendor directly whether they run automated dependency scanning, such as npm's own audit command or third-party tools, on every build, and whether they pin dependency versions with a lockfile rather than allowing automatic updates to the latest version. Lockfiles, typically a package-lock.json file, prevent a build from silently pulling in a newer, compromised version of a package that was safe when it was first added.

For in-house IT and development teams: once npm or GitHub publishes the specific MALFEX package names, check whether any production or CI/CD system has installed them, including build logs going back to August 2023 for older projects. Removing a malicious package after the fact does not undo code it already executed. Treat an affected build server or developer machine as potentially compromised and rotate any credentials, API keys, or tokens that were accessible from that environment.

This campaign is also a case for maintaining a software bill of materials, a formal inventory of every component in an application including indirect dependencies. The Cybersecurity and Infrastructure Security Agency has published SBOM guidance for organizations that want a structured way to track this exposure before a report like this one goes public, rather than after.

What to Watch Next

Expect npm and GitHub's security team to pull the eight identified packages once their names are confirmed, which typically happens within days of a public report like this one. Watch for an official advisory in the GitHub Advisory Database naming the MALFEX packages directly, since that listing lets automated scanners flag the exact package names and versions instead of relying on a general description. Until that advisory is published, the most effective defense is procedural: require dependency scanning before every deployment, limit who can add new npm dependencies without review, and keep lockfiles in version control so any unexpected package change shows up as a visible code diff.