A long-running malware campaign targeting the NPM ecosystem has accumulated more than 40,000 downloads since it first appeared in August 2023. Tracked as MALFEX, the campaign has been used to distribute several types of malware, including the Overlord remote access trojan and information-stealing payloads. Researchers say the activity has persisted for more than three years, with the same threat actor repeatedly publishing malicious packages under different names.
So far, 12 packages have been linked to the operator, eight of which were identified as malicious. Five have already been removed from the NPM registry, but three remained available for installation as of 1 October: function-flag, function-color, and cdn-img-fetch. The continued availability of some packages highlights how software supply-chain attacks can remain active for long periods when malicious code is hidden inside seemingly ordinary developer dependencies.
Function-Flag Stands Out With More Than 37,000 Downloads
Among all the packages involved, function-flag is particularly notable because of its reach. The package has reportedly been malicious since July 2025 and has accumulated more than 37,000 downloads. Despite this, no advisory currently flags the package itself as malicious.
That makes it one of the more concerning components of the campaign, especially because developers may see a relatively high download count as a sign that a package is legitimate or widely trusted. In reality, popularity alone does not guarantee that an open-source package is safe. A package can remain available for months or years while quietly delivering malicious behaviour.
Six Malicious Packages Have Published OSV Advisories
Open Source Vulnerabilities, or OSV, advisories have been published for six packages linked to the campaign. These include tlxbnhd, tldriver, mxdriver, img-to-native, native-runner, and cdn-img-fetch. However, the advisory covering cdn-img-fetch reportedly documents only two of the four malicious versions identified.
This gap is important because developers may rely on public advisories and security scanners to determine whether a package is known to be dangerous. If only some malicious versions are listed, older or newer compromised releases may still appear safe during automated checks. The campaign therefore shows the limits of relying solely on advisory databases without reviewing package behaviour and provenance.
Three Separate Malware Delivery Paths Were Used
Researchers identified three independent delivery mechanisms within the MALFEX campaign. Although the infrastructure used by each path does not overlap, the activity has been linked back to the same threat actor. This suggests the operator deliberately diversified its methods rather than relying on one infection chain.
Using separate delivery paths can make investigation more difficult because individual packages may appear unrelated when examined in isolation. It also gives the attacker multiple ways to continue distributing malware if one infrastructure component is detected or taken offline. In practical terms, the campaign behaves more like a collection of related operations than a single static attack.
One Path Delivers The Overlord RAT
The first infection route uses loaders for the Overlord RAT together with obfuscated scripts that execute during npm install. The installation scripts can run on Windows, macOS and Linux, but the actual malware payload only functions on Windows systems. This means developers using other operating systems may see the package install successfully without experiencing the same final-stage infection.
Overlord RAT provides attackers with extensive monitoring and remote-control capabilities. Its functions reportedly include screen capture, keylogging, window monitoring, remote shell access and file searching. It also supports a hidden desktop feature, allowing the operator to perform malicious activity in a separate desktop environment that may remain invisible to the victim.
These capabilities make the malware particularly dangerous on developer workstations. A compromised development machine can contain source code, credentials, API keys, internal documentation and access to production systems, giving attackers far more than just control of one computer.
Another Infection Path Drops The Movinlike Infostealer
The second route executes malicious code when the compromised NPM package is loaded. Instead of installing a remote access trojan, this path drops a Node.js information stealer known as movinlike. The malware is designed to collect sensitive information from commonly used applications.
It reportedly targets eight Discord clients, seven popular web browsers and cryptocurrency wallets. Data stored inside browsers can include saved passwords, authentication cookies and other session information, while Discord credentials may provide access to private communities or developer channels. Cryptocurrency wallet theft adds a direct financial motive to the campaign alongside credential collection.
The use of Node.js for the stealer also fits naturally into the NPM ecosystem. Developers may be less suspicious of JavaScript or Node-based behaviour originating from a package they intentionally installed, making malicious actions easier to disguise among legitimate development activity.
Function-Flag Uses A Different Downloader In Every Malicious Release
The third delivery path is the longest-running component of the campaign and centres around function-flag. Each malicious version contains a separate downloader designed to retrieve its payload from a different location. Changing the download infrastructure between releases can make static detection and takedown efforts more difficult.
The infection logic is also designed so that package installation can complete normally even when the malicious payload cannot be downloaded. Instead of producing an obvious installation error, the process can fail quietly. This reduces the likelihood that developers will investigate the package simply because something went wrong during installation.
On macOS and Linux, the malicious routine reportedly fails silently, leaving Windows systems as the primary target. Developers on those platforms could therefore install the package without immediately recognising that it contains malicious logic, potentially contributing to the package remaining undetected for longer.
The Campaign Relies On Direct Package Installation
Researchers found no legitimate or widely used packages that depend on the malicious packages identified in the campaign. This means the exposure is currently limited to systems where users directly installed those package names. The attack is therefore different from a dependency compromise where malware automatically spreads downstream through large numbers of unrelated projects.
No specific geographical region, company or industry appears to have been targeted. Anyone who directly installed the malicious packages could potentially become a victim. In the case of the information-stealing variants, the attacker appears interested in whatever data can be collected rather than a particular organisation.
This broad targeting model can still be effective because public package repositories are used globally. Even relatively obscure packages can accumulate thousands of downloads if their names resemble useful utilities or if developers discover them while searching for particular functionality.
Why NPM Packages Remain Attractive To Attackers
NPM is deeply integrated into modern JavaScript development, with applications frequently depending on dozens or even hundreds of third-party packages. Installing one dependency can execute scripts automatically, giving malicious maintainers an opportunity to run code on a developer's computer. This makes package registries attractive targets for attackers looking to compromise software supply chains.
Developers often make installation decisions quickly, especially when experimenting with libraries or trying to solve a specific problem. Package names, download counts and documentation can create the appearance of legitimacy even when the code itself has not been carefully reviewed. Attackers can exploit this trust by publishing seemingly useful packages that hide malicious installation scripts or payload downloaders.
The MALFEX campaign demonstrates how long these attacks can persist. Rather than relying on a single high-profile package, the operator has maintained multiple packages and infection mechanisms over several years.
Developers Should Review Installed Dependencies
Organisations using JavaScript and Node.js should review whether any of the known malicious packages are present in development environments, build servers or application projects. Particular attention should be given to function-flag, function-color, cdn-img-fetch, tlxbnhd, tldriver, mxdriver, img-to-native, and native-runner.
If one of these packages has been installed on a Windows system, simply removing the dependency may not be enough. Because the packages can download separate malware, organisations should also investigate the affected endpoint for signs of credential theft, remote-access activity or additional payloads.
Developer workstations should be treated as sensitive systems because they often hold credentials capable of reaching repositories, cloud platforms and deployment environments. A successful compromise can therefore extend far beyond the original machine.
Final Thoughts
The MALFEX campaign is a reminder that malicious packages can remain active inside public software ecosystems for years while accumulating tens of thousands of downloads. With at least eight malicious packages, three independent delivery paths and payloads ranging from information stealers to the Overlord RAT, the operation shows a sustained effort to target developers through trusted development infrastructure.
The case of function-flag is especially concerning because it has reportedly been malicious since July 2025 and has exceeded 37,000 downloads without a dedicated advisory identifying it as malicious. Developers should not assume that a popular or still-installable package is necessarily safe. Careful dependency review, endpoint monitoring and rapid investigation of suspicious packages remain essential parts of modern software supply-chain security.
Comments 0