How malicious packages on npm bypass existing security tools

How malicious packages on npm bypass existing security tools

Speakers: Paul McCarty, Head of Research, Safety

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=emhocCFs9N4

Overview

In this compelling talk from DEF CON, Paul McCarty, Head of Research at Safety, sheds light on the escalating threat of malicious packages within the open-source ecosystem, particularly npm. McCarty argues that traditional security paradigms and tools are woefully inadequate against this modern adversary, which targets developers and CI/CD pipelines with increasing sophistication. He highlights fundamental design flaws in npm, coupled with unique characteristics of interpreted languages like JavaScript, that create a fertile ground for attackers to evade detection.

McCarty's presentation delves into the "why" and "how" of this evasion, explaining that open-source malware is fundamentally different from traditional binary-based threats. It leverages the inherent trust in developer workflows, the sheer volume of transitive dependencies, and the lack of specialized security tooling in development environments. The talk serves as a critical wake-up call for both engineering and security teams, emphasizing that a profound misunderstanding of this threat landscape persists across the industry.

This article dissects McCarty's key arguments, from npm's historical security oversights to the sophisticated obfuscation techniques employed by nation-state actors and criminal gangs. It explores the technical nuances that allow these packages to slip past defenses, the specific targets and methods of attackers, and crucially, provides actionable intelligence for organizations to fortify their software supply chain against this pervasive and evolving threat.

Background

▶ Watch: Introduction: Open source malware invading security tooling (0:00)

The problem of malicious open-source packages is deeply rooted in the foundational design and historical context of ecosystems like npm. Paul McCarty emphasizes several critical factors that contribute to npm's vulnerability:

Firstly, npm was built in 2011-2012, a period McCarty refers to as "before security." The original design and documentation reveal that security wasn't a primary consideration. This oversight is compounded by JavaScript's "no batteries included" philosophy, which historically pushed developers to import numerous small libraries for basic functionalities. This architectural choice leads to an astonishing number of transitive dependencies; GitHub data shows that an average JavaScript project has 10 direct dependencies but an astounding 683 indirect or transitive dependencies. This vast dependency tree provides an expansive attack surface, as a single malicious package can be pulled into thousands of projects unknowingly.

Secondly, npm's install scripts are, as Brian Fox from Sonatype aptly puts it, "RCE by design." Both pre-install scripts and post-install scripts allow packages to execute arbitrary code before or after installation. This feature, intended for legitimate deployment, becomes a perfect pipeline for attackers to run malicious payloads on developers' machines or within CI/CD environments.

Thirdly, the barrier to entry for publishing packages on npm is alarmingly low. McCarty demonstrated that creating a new Gmail, GitHub, and npm account can take less than five minutes, allowing an attacker to publish packages almost immediately. Furthermore, anyone can claim a namespace (e.g., @microsoft), regardless of affiliation, and package metadata like author and Git repository can be easily faked. This allows attackers to create highly legitimate-looking lookalike packages, often pointing to the original, legitimate GitHub repo and author, with only the npm user differing.

Finally, npm's operational security is lacking. Account takeover is made easier by the absence of mandatory 2FA/MFA for most users. More critically, the process for removing malicious packages is glacially slow. McCarty recounted finding a vetted malicious package in December 2024 that remained downloadable until May 2024. This delay allows malicious packages to compromise countless users for months. Additionally, vulnerability databases like GitHub Security Advisory (GHSA) and npm's own system fail to track crucial metadata like author information or the specific actions of malware, hindering security researchers from pivoting to other malicious packages by the same author. This combination of design flaws, ease of abuse, and slow remediation makes npm a prime target, accounting for an estimated 98.5% of all malicious packages observed by Sonatype.

Key Findings

▶ Watch: Why open source malware targets developers and CI/CD (2:00)

Paul McCarty’s talk unveiled several critical findings regarding the nature of open-source malware and its evasion techniques:

1. Interpreted Language Nature: Unlike traditional binary malware, open-source malware predominantly consists of interpreted languages like JavaScript and Python. This means traditional malware analysis, reverse engineering, and sandboxing tools (e.g., Any.run, Joe's Sandbox) designed for executables are largely ineffective or cannot even run the code.
2. Highly Iterative Payloads: Attackers can rapidly update their malicious packages. McCarty observed one package with 19 versions in two months, featuring three to four major changes in payload structure, encoding, and C2 (Command and Control) infrastructure. This rapid iteration makes detection and signature-based blocking extremely difficult.
3. Obfuscation as a Double-Edged Sword: While obfuscation is often legitimately used to protect business logic in JavaScript, attackers exploit it extensively. They layer multiple obfuscation techniques, such as control flow flattening and control flow reordering, making manual analysis incredibly challenging. This forces human intervention, slowing down detection.
4. Browser as a Primary Attack Surface: A significant portion of current open-source malware targets the browser environment, particularly crypto developers. Malicious packages are designed to be imported into web applications, performing their stated function while simultaneously exfiltrating sensitive data like wallet files, cookies, and access tokens. Browser extensions are also a rapidly growing vector.
5. Ineffectiveness of Current Security Tools: McCarty argues that existing AppSec tools (SCA, SAST) are built to find accidental vulnerabilities (e.g., OWASP Top 10) but not designed to detect malicious behavior. EDR solutions often have blanket exclusions for developers, and developers frequently do not run security agents at all. This leaves a significant gap in coverage.
6. CI/CD Pipelines as High-Value Targets: Attackers actively target CI/CD pipelines because they represent a nexus of core intellectual property (source code) and high-value access (API keys, AWS tokens, npm tokens). These pipelines rarely run security tools, have limited logging (GitHub's free tier logs disappear after 90 days), and reuse containers and libraries hundreds of thousands of times, making them ideal for widespread compromise.
7. Sophisticated Evasion of Detection Systems: Attackers employ tactics like self-removal from npm. If a malicious package is discovered and flagged (e.g., in OSV.dev), the attacker can pull it from npm, preventing it from being officially listed in GHSA. This allows them to reuse the package name and capability later, essentially "unburning" their exploit.
8. "Malware Doesn't Go Boom": Modern open-source malware is often subtle. Instead of disruptive actions, it quietly exfiltrates data. McCarty describes a malicious Web3 event logging library that perfectly mimicked its legitimate counterpart but secretly sent every logged event to the attackers. Such nuanced behavior is difficult to detect without deep inspection of the code after it's imported, not just installed. Nation-state actors, in particular, prefer using import statements rather than easily detectable install scripts.
9. Targeting "Hot" Technologies: Attackers consistently target emerging and popular technologies. McCarty specifically calls out Vite, MCP (which saw a 50% likelihood of packages being malicious at one point), and Solana (over 60% of packages discussing Solana were deemed malicious by McCarty's research) as current high-risk areas.
10. Role of Bug Bounty Researchers: A significant portion (over 40%) of malicious packages McCarty encounters originate from bug bounty researchers, who publish them as part of their proof-of-concept work. While well-intentioned, this practice inadvertently contributes to the noise and volume of malicious samples on public registries, making it harder to track genuine threats.

Technical Deep Dive

▶ Watch: npm's install scripts: RCE by design (4:36)

The technical underpinnings of open-source malware evasion are multifaceted, leveraging both the design peculiarities of the npm ecosystem and the characteristics of interpreted languages.

A core distinction highlighted by McCarty is the difference between interpreted languages (like JavaScript and Python) and compiled binaries. Traditional malware analysis relies heavily on techniques like disassembly, memory forensics, and static analysis of compiled executables. However, when dealing with raw source code, these techniques often become irrelevant. JavaScript, being the dominant language for npm malware (98.5% of observed malicious packages), presents a unique challenge. Security tools and analysts accustomed to binary analysis lack the "muscle memory" and specialized tools to effectively reverse-engineer or analyze interpreted code.

The iterative nature of payloads is another significant technical hurdle. Attackers can modify their malicious code, C2 infrastructure, and obfuscation techniques with extreme rapidity. McCarty gave an example of a package that had 19 versions over two months, with significant changes in payload structure and C2s. This means that a signature or indicator of compromise (IOC) for one version quickly becomes obsolete for the next. Traditional security models, which expect a relatively stable binary, are ill-equipped for this dynamic threat.

Obfuscation is paramount to evasion. While legitimate developers use obfuscation to protect intellectual property, attackers layer multiple, complex techniques to render their code incomprehensible to automated tools and human analysts. McCarty specifically mentioned control flow flattening and control flow reordering, which manipulate the logical execution path of the code using conditional statements, making it extremely difficult to follow the program's flow. Combined with identifier renaming (variable renaming), this creates a chaotic and unreadable codebase. Attackers are also experimenting with extreme encoding methods, such as encoding entire payloads into emojis, further complicating analysis. McCarty notes that while LLMs like Gemini are showing promise in deciphering obfuscated code, human verification remains critical, and the process is inherently time-consuming.

The inherent design of npm facilitates these attacks. The "no batteries included" philosophy of JavaScript leads to projects pulling in an average of 683 transitive dependencies. Each of these dependencies represents a potential entry point for malicious code. The pre-install and post-install scripts embedded within package.json files are a direct avenue for arbitrary code execution (RCE). These scripts run automatically during the package installation process, allowing attackers to execute their payloads without explicit user interaction beyond the npm install command.

Attackers further exploit npm's metadata system. Fields like author and repository can be freely manipulated, allowing threat actors to fake package metadata. This enables them to create highly convincing typo-squatting or dependency confusion packages that appear legitimate, often pointing to the official GitHub repository and author of the intended package. The only difference might be the npm user, which is often overlooked. This technique leverages trust and human error to trick developers into installing a malicious lookalike.

The chosen attack vectors are also technically sophisticated. Instead of relying on noisy install scripts, nation-state actors frequently use subtle tactics. McCarty describes a malicious Web3 event logging library that functioned identically to its legitimate counterpart but secretly exfiltrated every logged event to an attacker-controlled endpoint. This type of malware requires the developer to actively import and use the library within their application, making detection challenging. The malicious behavior is embedded directly within the application's logic, not in an obvious post-install script. These attackers also employ conditional logic within their payloads, enabling them to dynamically search for specific assets (e.g., Solana tokens, StarkNet files) and adapt their exfiltration methods accordingly, making them more versatile and harder to predict.

Finally, the evasion strategy of self-removal from npm is a clever technical maneuver. When a malicious package is identified by security researchers and listed in public databases like OSV.dev, attackers can quickly unpublish it from npm. This prevents the package from being officially tracked in GHSA (GitHub Security Advisory) as malicious, effectively "unburning" the capability. This allows the attacker to reuse the package name or concept in future campaigns, prolonging the lifespan of their attack infrastructure.

Demo / Proof of Concept

▶ Watch: Low barrier to entry: Easy account creation and publishing (5:10)

Paul McCarty’s talk did not feature a live, in-talk demonstration or proof-of-concept of a specific exploit. However, his extensive background and ongoing work in the field serve as a continuous, practical demonstration of the concepts discussed.

McCarty explicitly mentioned his new open-source tool, Malice, which is designed to "help identify malicious open source packages in the npm ecosystem or the Pi Pi ecosystem." While not demonstrated in the talk, the existence and purpose of Malice underscore his practical approach to tackling this problem. Furthermore, McCarty highlighted his role as the former top contributor to the OpenSSF's malicious packages repository and OSV.dev for six months. This contribution involved actively discovering, analyzing, and documenting malicious packages, effectively serving as a real-world, ongoing proof-of-concept of the threats he describes. His personal anecdotes throughout the talk, such as finding a malicious package in December that wasn't removed until May, or his friend in Web3 constantly receiving North Korean-attributed malicious packages, further illustrate the practical realities and impact of these vulnerabilities.

Defensive Implications

▶ Watch: Account takeover and slow removal of malicious packages (7:00)

Addressing the pervasive threat of malicious open-source packages requires a multi-pronged defensive strategy that goes beyond traditional security tooling. Paul McCarty outlined several critical implications and recommendations for defenders:

1. Enhance Security Tooling: Current SCA (Software Composition Analysis) and ASPM (Application Security Posture Management) tools are insufficient. They must evolve beyond identifying known vulnerabilities to actively detect malicious behavior, even within obfuscated or subtly destructive code. This requires deeper contextual analysis and understanding of interpreted language execution.
2. Implement Package Firewalls: Organizations should adopt package firewalls (e.g., Sonatype's product, or open-source alternatives). These act as proxies, wrapping around public registries like npm or PyPI, and preventing the download and installation of known malicious packages. Integrating these firewalls with existing network proxies provides an essential layer of defense, ensuring that only vetted and approved packages enter the development environment.
3. Cultivate Subject Matter Expertise: McCarty strongly emphasized that tools alone cannot solve this problem. Organizations need to hire individuals with deep subject matter expertise in open-source supply chain security and malware analysis for interpreted languages. These experts are crucial for understanding nuanced attack techniques, deciphering obfuscated code, and staying ahead of rapidly evolving threats.
4. Harden CI/CD Pipelines: Given that CI/CD pipelines are high-value targets, they must be rigorously secured. This involves implementing robust security scanning within the pipeline, ensuring adequate logging that persists beyond GitHub's 90-day free tier limit, and carefully managing access to sensitive API keys, AWS access tokens, and npm tokens. The principle of least privilege should be strictly enforced for any credentials used in these environments.
5. Educate Engineering Teams: Developers need to understand the unique risks associated with open-source dependencies. They should be trained to pull vetted packages from known, trusted registries and to be highly suspicious of lookalike packages, especially those targeting "hot" technologies like Vite, MCP, or Solana. Awareness of typo-squatting and dependency confusion is paramount.
6. Address Bug Bounty Program Impact: McCarty called for a dialogue with bug bounty platforms like Bugcrowd and HackerOne to reconsider their terms of service. The current practice of researchers publishing malicious proof-of-concept packages on public registries, while often well-intentioned, contributes significantly to the noise and makes it harder to distinguish genuine threats. Policies should encourage responsible disclosure without polluting public package ecosystems.
7. Rethink EDR Exclusions: The common practice of granting blanket EDR exclusions for developers creates a significant blind spot. While McCarty acknowledges EDR's limitations against interpreted malware, these exclusions still expose developers to other forms of attack and hinder any potential behavioral analytics. A more granular approach to EDR policy for developer workstations is needed.
8. Scrutinize Browser Extensions: As browser extensions become a growing vector for open-source malware, organizations must implement policies and tools to vet and manage extensions used by developers, especially those interacting with sensitive internal applications or crypto wallets.

By combining technological solutions with human expertise, process improvements, and developer education, organizations can begin to build a more resilient defense against the sophisticated and evasive open-source malware landscape.

Key Takeaways

• npm's design flaws are foundational to the problem: Built without security in mind, npm's pre/post-install scripts enable RCE by design, while low barriers to entry and faked metadata facilitate lookalike packages and account takeovers.
• Open-source malware is distinct and highly evasive: Unlike traditional binary malware, it's interpreted, rapidly iterative (changing C2s and payloads across versions), and often employs subtle data exfiltration via import statements rather than noisy install scripts.
• Traditional security tools are largely ineffective: SCA, SAST, EDR, and even traditional sandboxes are not designed to detect malicious behavior in interpreted languages or within developer/CI/CD contexts, leaving significant blind spots.
• Developers and CI/CD pipelines are prime targets: Attackers exploit the high access levels (IP, API keys, tokens), EDR exclusions, and lack of specialized security tooling in these environments to achieve widespread and persistent compromise.
• Obfuscation is a major analytical challenge: While legitimate, layered and complex obfuscation techniques (like control flow flattening) make manual analysis difficult and slow, although LLMs are emerging as a potential aid.
• A multi-faceted defense is essential: Effective protection requires a combination of improved security tooling (especially package firewalls), subject matter expertise, hardened CI/CD pipelines, developer education, and a reevaluation of bug bounty program impacts.

About the Speaker(s)

Paul McCarty is the Head of Research at Safety, a specialized supply chain security company based in Vancouver. With a career spanning both large enterprises and startups, McCarty has a deep understanding of the security challenges faced by organizations of all sizes. He is a prolific contributor to the open-source community, having authored numerous tools including "Gimme Pats," "super confused," and the upcoming "Malice," which is designed to identify malicious open-source packages in the npm and PyPI ecosystems. McCarty is also recognized for his significant contributions to the broader security community, notably serving as the top contributor for six months to the OpenSSF's malicious packages repository and OSV.dev, demonstrating his hands-on experience in identifying and cataloging real-world threats.