Open source software has become an essential part of modern application development.
Organizations rely heavily on npm packages to build web applications, APIs, developer tools, automation workflows, and enterprise platforms. This ecosystem enables developers to move faster, but it also creates a significant cybersecurity challenge.
A recently identified long running npm malware campaign, tracked as MALFEX, demonstrates how attackers can quietly maintain malicious packages for extended periods while accumulating thousands of downloads.
Security researchers found that packages connected to the campaign recorded more than 40,000 downloads, with one malicious package accounting for the overwhelming majority of that activity. The campaign has been linked to a single operator and has remained active across multiple packages and publishing accounts.
The incident highlights a critical reality for modern organizations:
A package download is not simply a development event. It can become a security event when malicious code enters the software supply chain.
How the npm Campaign Worked
Researchers identified multiple npm packages associated with the MALFEX operation.
The campaign involved packages that appeared to provide legitimate functionality but contained malicious components capable of executing during the npm installation or package loading process.
Some packages used installation scripts that could automatically trigger malicious activity when developers installed them.
Researchers identified multiple malicious packages associated with the campaign, including packages that delivered remote access capabilities and credential stealing malware. Some packages were removed from npm, while other malicious packages remained available during the research period.
This is particularly concerning because developers often trust package registries as part of their normal software development workflow.
A malicious package does not necessarily need to exploit a vulnerability in the developer’s operating system.
The package itself can become the delivery mechanism.
40,000 Downloads Does Not Mean 40,000 Infected Systems
One important distinction should be made when discussing npm download statistics.
Researchers recorded more than 40,000 downloads across the malicious packages. However, download counts do not automatically mean that 40,000 systems were compromised.
A package can be downloaded multiple times by the same environment, appear in automated processes, or be retrieved as part of a dependency relationship.
Therefore, the download figure represents the potential reach of the campaign rather than a confirmed number of compromised devices.
Even so, the scale is significant because every download represents an opportunity for malicious code to enter a development environment.
Checkmarx reported 40,767 downloads across eight malicious packages, including more than 37,000 associated with the function-flag package.
The Hidden Danger of Installation Scripts
One of the most important security concerns surrounding npm malware is the use of lifecycle scripts.
Packages can contain scripts that execute during installation or other package lifecycle events.
When these capabilities are abused, installing what appears to be an ordinary development dependency can trigger malicious activity.
This creates a challenge for organizations because the malicious behavior may occur within trusted development processes.
Security teams therefore need to monitor not only applications running in production but also what happens inside developer environments and CI/CD pipelines.
A compromised developer workstation can potentially expose:
• Source code
• API keys
• Cloud credentials
• npm tokens
• Git credentials
• Environment variables
• CI/CD secrets
• SSH keys
• Database credentials
• Internal application information
The development environment can therefore become a high value target.
Credential Theft Can Turn One Compromise Into Many
Malware operating inside a developer environment can create consequences beyond a single workstation.
If credentials or tokens are stolen, attackers may attempt to access other systems connected to the development workflow.
For example, compromised credentials can potentially expose:
• Source code repositories
• Package registries
• Cloud platforms
• CI/CD systems
• Container registries
• Deployment environments
• Internal applications
• SaaS platforms
This creates the possibility of lateral movement across the software development lifecycle.
An organization may have strong perimeter security while still being exposed through a compromised developer machine.
The Software Supply Chain Is Now an Enterprise Security Boundary
Traditional cybersecurity programs often focus on protecting production infrastructure.
That approach is no longer sufficient.
Modern applications are assembled from thousands of open source components, third party libraries, APIs, containers, plugins, and development tools.
Every component introduces some level of supply chain risk.
Attackers understand this.
Instead of attacking a large organization directly, they may target a smaller component that is trusted by many developers.
A successful compromise of one package can potentially provide access to multiple downstream organizations.
This makes software supply chain security an enterprise risk management issue rather than simply a developer responsibility.
Why Long Running Campaigns Are Especially Concerning
The MALFEX campaign demonstrates another important characteristic of modern supply chain attacks: persistence over time.
Researchers identified malicious activity associated with the campaign across multiple years, with some malicious packages remaining active without security advisories for extended periods. CloudSEK reported that one malicious npm postinstall package had remained without an advisory for approximately 14 months.
This demonstrates why organizations should not assume that older dependencies are automatically safe.
A package may have existed for months or years before malicious behavior is discovered.
Security teams should therefore continuously evaluate dependencies rather than relying on one time security reviews.
Package Names Can Create False Confidence
Developers frequently choose packages based on names, documentation, download numbers, community activity, or apparent functionality.
Attackers can exploit these expectations.
A package can appear harmless while containing malicious functionality that is difficult to identify through casual inspection.
This is particularly dangerous when developers install packages quickly to solve development problems.
Organizations should therefore establish controls that reduce reliance on trust based assumptions.
AI Development Makes Supply Chain Security Even More Important
The growing use of AI assisted development introduces another dimension to the problem.
Developers increasingly use AI coding assistants to recommend libraries, generate application code, troubleshoot errors, and accelerate development.
This can increase the speed at which dependencies are introduced into projects.
If dependency selection is not properly reviewed, AI assisted development could unintentionally increase the number of external packages introduced into an organization’s software environment.
Security teams should therefore ensure that AI assisted development remains subject to the same dependency governance and security controls applied to human generated code.
What Organizations Should Do
Organizations can take several practical steps to reduce the risk of malicious npm packages.
1. Maintain a Complete Software Bill of Materials
Organizations should maintain visibility into the open source components used across applications and development environments.
An SBOM can help security teams identify where vulnerable or suspicious dependencies are being used.
2. Use Software Composition Analysis
Software Composition Analysis tools can help identify known vulnerabilities, outdated dependencies, licensing issues, and potentially risky components.
However, organizations should combine automated scanning with broader behavioral and supply chain analysis.
3. Control npm Package Installation
Organizations should establish policies around which package registries, packages, and versions developers can use.
Where appropriate, approved internal repositories can provide additional control over dependencies.
4. Monitor Installation Scripts
Security teams should pay particular attention to npm lifecycle scripts and unexpected changes to package behavior.
Packages that suddenly introduce installation scripts or modify their behavior should receive additional review.
5. Protect Developer Credentials
Developer environments should not contain unnecessary long lived credentials.
Organizations should use short lived credentials, strong authentication, secrets management, and least privilege access wherever possible.
6. Secure CI/CD Pipelines
Build and deployment environments should be treated as critical security infrastructure.
Organizations should protect:
• CI/CD credentials
• Repository access tokens
• Cloud deployment credentials
• Package publishing tokens
• Build runners
• Secrets
• Artifact repositories
7. Monitor Package Changes
Organizations should monitor dependency updates rather than automatically accepting every new release.
Unexpected changes to package maintainers, publishing behavior, dependencies, installation scripts, or package contents should trigger investigation.
8. Establish Dependency Governance
Development teams should have clear processes for approving new dependencies.
Security should be considered before a package enters the organization’s production software supply chain.
Industries Most Exposed
The risks demonstrated by npm malware affect virtually every industry that develops or operates software.
Financial Services and Banking
Banks, fintech organizations, payment providers, and investment companies depend heavily on software applications and APIs.
COE Security can help these organizations assess application dependencies, secure CI/CD environments, protect developer credentials, conduct application security testing, and strengthen software supply chain controls.
Healthcare and Life Sciences
Healthcare organizations increasingly rely on digital applications, patient platforms, APIs, cloud environments, and third party software.
COE Security can help assess application security, dependency risks, cloud environments, APIs, and data protection controls while supporting compliance requirements.
Retail and E-commerce
Retail organizations depend on large application ecosystems involving payment systems, customer platforms, mobile applications, APIs, analytics systems, and cloud services.
COE Security can help organizations evaluate open source dependencies, application security, APIs, cloud infrastructure, and third party technology risks.
Manufacturing and Industrial Organizations
Manufacturers increasingly rely on software for connected operations, supply chain systems, cloud applications, industrial platforms, and enterprise systems.
COE Security can help strengthen application security, cloud security, software supply chain controls, vulnerability management, and secure development practices.
Government and Public Sector
Government organizations operate applications containing sensitive citizen, operational, and administrative information.
COE Security can help government organizations assess software supply chain risks, application security, cloud environments, vulnerability management programs, and compliance controls.
Technology and SaaS Companies
Technology companies are particularly exposed because their products may depend on hundreds or thousands of open source components.
A compromised dependency can potentially affect both the organization and its customers.
COE Security can support SaaS and technology organizations with SSDLC implementation, Software Composition Analysis, application penetration testing, cloud security assessments, CI/CD security reviews, dependency assessments, and software supply chain security.
The Bigger Lesson for Developers and Security Teams
The npm ecosystem demonstrates how closely development and cybersecurity are now connected.
Security cannot begin after an application reaches production.
It must begin when a developer selects a package.
Organizations should therefore integrate security throughout the software development lifecycle.
This includes:
• Secure dependency selection
• Software Composition Analysis
• SBOM management
• Dependency monitoring
• Secrets management
• Secure coding
• CI/CD security
• Developer identity protection
• Application security testing
• Vulnerability management
• Supply chain risk assessment
• Continuous security monitoring
The objective is not to eliminate open source software.
Open source remains critical to modern innovation.
The goal is to use it responsibly while maintaining visibility into what enters the organization’s software environment.
Conclusion
The long running npm malware campaign is another reminder that software supply chain attacks do not always require sophisticated exploitation of a major enterprise.
Sometimes the attack begins with something as ordinary as installing a package.
More than 40,000 recorded downloads demonstrate how malicious packages can achieve meaningful reach while remaining part of normal development workflows. Researchers also found that some campaign components remained available or lacked advisories for extended periods, reinforcing the importance of continuous dependency monitoring.
Organizations should treat open source dependencies, developer environments, package registries, CI/CD pipelines, and software publishing systems as critical components of their cybersecurity architecture.
Strong dependency governance, Software Composition Analysis, SBOM visibility, secrets protection, secure development practices, continuous monitoring, and penetration testing can significantly improve resilience against software supply chain threats.
The security of an application increasingly depends on the security of everything used to build it.
About COE Security
COE Security partners with organizations in financial services, healthcare, retail, manufacturing, and government to secure AI-powered systems and ensure compliance.
Our offerings include:
• AI-enhanced threat detection and real-time monitoring
• Data governance aligned with GDPR, HIPAA, and PCI DSS
• Secure model validation to guard against adversarial attacks
• Customized training to embed AI security best practices
• Penetration Testing (Mobile, Web, AI, Product, IoT, Network & Cloud)
• Secure Software Development Consulting (SSDLC)
• Customized CyberSecurity Services
• Follow COE Security on LinkedIn for ongoing insights into safe, compliant AI adoption.
In addition, COE Security helps organizations strengthen software supply chain security through Software Composition Analysis, SBOM assessments, dependency security reviews, secure CI/CD assessments, application security testing, source code reviews, vulnerability management, cloud security assessments, secrets management reviews, developer environment security assessments, and software supply chain risk assessments.
For financial services and banking organizations, COE Security can help secure digital banking applications, APIs, cloud environments, development pipelines, software dependencies, authentication systems, and sensitive financial data.
For healthcare and life sciences organizations, we help assess applications, APIs, cloud infrastructure, third party dependencies, data protection controls, and software development environments while supporting regulatory requirements.
For retail and e-commerce organizations, we help secure customer facing applications, payment platforms, APIs, cloud environments, open source dependencies, and third party software components.
For manufacturing and industrial organizations, we help strengthen application security, cloud security, connected systems, software supply chain security, vulnerability management, and secure development practices.
For government and public sector organizations, we help assess application security, software dependencies, cloud environments, development pipelines, access controls, and compliance requirements.
For technology and SaaS companies, we help identify risks across source code, open source dependencies, CI/CD pipelines, APIs, cloud environments, package registries, developer credentials, and software delivery infrastructure.
COE Security also helps organizations build stronger Secure Software Development Lifecycle programs that integrate security into development from dependency selection through deployment and continuous monitoring.
Our goal is to help organizations identify security gaps, reduce software supply chain risk, protect sensitive systems and data, strengthen cyber resilience, and maintain compliance across modern digital environments.
Follow COE Security on LinkedIn for ongoing insights into safe, compliant AI adoption and to stay updated and cyber safe.
Click to read our LinkedIn feature article