The MALFEX campaign has been dropping malware into NPM packages since August 2023. Over 40,000 downloads later, three malicious packages were still installable as of October 1, 2025. One package, function-flag, carried malware for months with more than 37,000 downloads and no Open Source Vulnerabilities (OSV) advisory flagging it as malicious.
This isn't a failure of tooling. It's a failure of intake discipline. When your team pulls in open-source dependencies without structured review gates, you're not managing supply chain risk, you're inheriting it blindly.
Why These Mistakes Keep Happening
Your developers install packages to solve problems, optimizing for speed, not vendor risk. Meanwhile, your third-party risk management (TPRM) function often treats "vendor" as shorthand for "entity with a contract," so open-source components fall into a governance gap. No one owns the intake decision for a package that arrives via npm install.
The result: malicious code enters your build environment through the same workflow you use for legitimate dependencies. The threat actor behind MALFEX published 12 packages, eight of them malicious. Five were eventually removed, but removal is reactive. The damage happens during the window between publication and detection, and that window can span years if your intake controls don't catch it.
Mistake 1: Treating Package Registries as Trusted Sources
Why it happens: Your team assumes NPM, PyPI, or Maven Central vet submissions before publication. They don't. These registries host millions of packages with minimal pre-publication review. The MALFEX actor published packages freely; the only friction came after researchers flagged them.
Real consequence: You inherit malware during routine dependency updates. The MALFEX packages included loaders for the Overlord RAT, which provides screen capture, keylogging, window monitoring, and remote shell access. One package, movinlike, targeted eight Discord clients, seven browsers, and cryptocurrency wallets for credential theft.
The fix: Implement a package allowlist tied to your Criticality Classification framework. High-criticality applications should only pull from pre-approved packages. For new dependencies, require a lightweight intake review: Who published it? What's the maintainer history? Does it have OSV advisories? This isn't a full vendor assessment, it's a two-minute sanity check before you grant the package access to your build environment.
Mistake 2: Relying on OSV Advisories as Your Only Signal
Why it happens: OSV advisories are free, machine-readable, and integrate cleanly with CI/CD pipelines. Your team configures a scanner, sees green checkmarks, and moves on.
Real consequence: Advisories lag behind threats. Checkmarx found that function-flag had been malicious since July 2025 with no advisory coverage. Another package, cdn-img-fetch, had an OSV entry that covered only two of its four malicious iterations. If your intake gate is "no advisory = safe," you're blind to zero-day supply chain threats.
The fix: Layer behavioral analysis on top of advisory scanning. Use tools that inspect what a package does during installation, does it spawn network connections, write to unexpected directories, or execute obfuscated scripts? The MALFEX packages executed malicious code during npm install, a pattern that behavioral scanners can flag even without a named advisory. Pair this with a manual review trigger: any package that requests network access or filesystem writes during installation should require human approval before it enters production builds.
Mistake 3: Ignoring Cross-Platform Payload Differences
Why it happens: Your security team tests on Linux because that's where your production workloads run. Your developers work on macOS. No one tests the Windows path because "we don't deploy to Windows."
Real consequence: You miss platform-specific malware. The MALFEX campaign delivered payloads that only executed on Windows systems. The infection routine failed silently on macOS and Linux, so if you tested on those platforms, you saw nothing suspicious. But the malware was still there, dormant, waiting for a Windows environment.
The fix: Test new dependencies in all environments your team uses, not just production targets. Developer workstations are part of your attack surface. If a package drops malware on a Windows laptop during local development, that laptop becomes a pivot point for lateral movement. Your intake review should include: "Does this package behave differently on Windows, macOS, or Linux?" If yes, test all three before approval.
Mistake 4: Skipping Dependency-of-Dependency Analysis
Why it happens: You review the package your developer requested but not what that package pulls in. Transitive dependencies feel like someone else's problem.
Real consequence: Malicious code enters through the back door. Checkmarx noted that no legitimate or widely used packages depended on the MALFEX packages, which limited exposure to direct installations. But if a popular package had listed one as a dependency, the blast radius would have expanded exponentially. You can't assess what you don't see.
The fix: Map the full dependency tree before approving any new package. Tools like npm ls, pip-tree, or dependency-check plugins show you every transitive dependency. Flag any package in the tree that lacks an OSV advisory, has fewer than 1,000 downloads, or was published in the last 90 days. These aren't automatic rejections, they're triggers for closer review. Your intake checklist should ask: "Do we trust everything this package depends on?"
Mistake 5: No Removal Trigger for Post-Intake Discoveries
Why it happens: You approved a package six months ago. It's now embedded in 15 repositories. When an advisory finally appears, no one owns the response.
Real consequence: Known-malicious code stays in your environment. Five MALFEX packages were removed from NPM, but removal doesn't revoke what's already installed. If your team doesn't actively monitor for post-approval advisories and trigger remediation, you're running malware until the next major refactor.
The fix: Implement Continuous Monitoring of Active Arrangements for open-source dependencies. Subscribe to OSV feeds, GitHub Security Advisories, and registry-specific alerts. When an advisory drops for a package you've approved, your process should automatically: (1) identify which applications use it, (2) assess whether the malicious version is present, (3) escalate to the application owner with a removal deadline, and (4) block future installations until a clean version is verified. This is the same Incident Escalation workflow you use for vendor breaches, apply it to your supply chain.
Prevention Checklist
Before approving any open-source package for production use:
- Verify the package name against a typosquatting check (common names with slight variations are red flags)
- Review the maintainer's publication history (new accounts with no track record warrant scrutiny)
- Check for OSV advisories covering all published versions, not just the latest
- Run behavioral analysis during installation in a sandboxed environment
- Test installation behavior on Windows, macOS, and Linux if your team uses multiple platforms
- Map and review all transitive dependencies, flagging any with <1,000 downloads or <6 months age
- Document the business justification (what problem does this package solve that vetted alternatives don't?)
- Assign an owner responsible for monitoring post-approval advisories
- Set a review cadence (quarterly minimum) to reassess whether the package is still necessary
Your intake process is your first line of defense. The MALFEX campaign succeeded because teams installed packages without asking basic questions. You can't audit every line of open-source code, but you can enforce a gate that requires evidence of trustworthiness before you grant supply chain access. That's not overhead, it's governance.
