Current Cyber Threats

Over 67,000 Fake npm Packages Flood Registry in Worm-Like Spam Attack

Summary:
Cybersecurity researcher Paul McCarty recently uncovered a massive, financially motivated spam campaign targeting the npm registry with tens of thousands of fake packages since early 2024. This coordinated effort, dubbed the "IndonesianFoods Worm" due to its distinctive naming scheme using Indonesian food and names, has published up to 67,579 packages, primarily masquerading as Next.js projects. The unusual goal of the worm is to flood the npm registry with junk packages rather than conduct data theft. It employs a sophisticated, self-replicating, worm-like spreading mechanism. The malicious JavaScript file inside each package is dormant and does not execute automatically upon installation (evading automated security scanners). Instead, it requires a manual command like node auto.js to run, which threat actors likely induce through fake tutorials, etc.

When executed, the script begins an infinite loop, removing the <"private": true> setting and repeatedly generating, numbering, and publishing a new spam package to npm every 7 to 10 seconds. Researchers believe the primary motivation is monetary, specifically, abusing the TEA protocol by artificially inflating their impact scores to earn TEA tokens. The packages also reference each other as dependencies, creating a self-replicating network that strains the registry's bandwidth by forcing users to fetch an exponentially growing dependency tree. A second variant using random English words has also been flagged. GitHub has confirmed the removal of the packages.

Security Officer Comments:
This campaign highlights a significant shift in open-source software (OSS) supply chain attacks, moving from targeted, high-sophistication compromises to a volume and persistence-based strategy. The IndonesianFoods worm campaign effectively leverages the fundamental trust within the npm ecosystem, a factor often more critical to exploit than finding zero-day vulnerabilities. The attackers strategically leveraged a "sleeper" payload requiring manual execution to bypass standard security scanners that focus on installation-time hooks. While it may not steal credentials, the sheer volume and self-publishing aspect of the campaign can overwhelm security systems, pollute the registry, and validate a low-effort model for monetizing open-source ecosystems like npm through mechanisms such as the TEA protocol.

Suggested Corrections:
Threat actors employ different techniques to execute software supply chain attacks. Three common techniques are:
  • Hijacking updates
  • Undermining code signing
  • Compromising open-source code
Hijacking Updates
“Most modern software receives routine updates to address bugs and security issues. Software vendors typically distribute updates from centralized servers to customers as a routine part of product maintenance. Threat actors can hijack an update by infiltrating the vendor’s network and either inserting malware into the outgoing update or altering the update to grant the threat actor control over the software’s normal functionality. For example, the NotPetya attack occurred in 2017 when Russian hackers targeting Ukraine spread malware through tax accounting software popular in Ukraine. What would later be called the NotPetya malware spread well beyond Ukraine and caused major global disruptions in crucial industries, including international shipping, financial services, and healthcare” (CISA, 2022)

Undermining Codesigning
“Codesigning is used to validate the identity of the code’s author and the integrity of the code. Attackers undermine codesigning by self-signing certificates, breaking signing systems, or exploiting misconfigured account access controls. By undermining codesigning, threat actors are able to successfully hijack software updates by impersonating a trusted vendor and inserting malicious code into an update. For example, APT 41, a China-based threat actor, routinely undermines codesigning while conducting sophisticated software supply chain compromises against the United States and other countries” (CISA, 2022)

Compromising Open-Source Code
“Open-source code compromises occur when threat actors insert malicious code into publicly accessible code libraries, which unsuspecting developers—looking for free blocks of code to perform specific functions—then add into their own third-party code. For example, in 2018, researchers discovered 12 malicious Python libraries uploaded on the official Python Package Index (PyPI). The attacker used typosquatting tactics by creating libraries titled “diango,” “djago,” “dajngo,” etc., to lure developers seeking the popular “django” Python library. The malicious libraries contained the same code and functionality of those they impersonated; but they also contained additional functionality, including the ability to obtain boot persistence and open a reverse shell on remote workstations. Open-source code compromises can also affect privately owned software because developers of proprietary code routinely leverage blocks of open-source code in their products” (CISA, 2022)

“Network defenders are limited in their ability to quickly mitigate consequences after a threat actor has compromised a software supply chain. This is because organizations rarely control their entire software supply chain and lack authority to compel every organization in their supply chain to take prompt mitigation steps. Due to the difficulty of mitigating consequences after a software supply chain attack occurs, network defenders should observe industry best practices before an attack has occurred. Implementing best practices will bolster an organization’s ability to prevent, mitigate, and respond to such attacks” (CISA, 2022)

NIST suggests eight key practices for establishing a NIST C-SCRM (Cyber Supply Chain Risk Management) approach that can be applied to software.
  1. Integrate C-SCRM across the organization.
  2. Establish a formal C-SCRM program.
  3. Know and manage critical components and suppliers.
  4. Understand the organization’s supply chain. software for which a vulnerability is disclosed
  5. Closely collaborate with key suppliers.
  6. Include key suppliers in resilience and improvement activities.
  7. Assess and monitor throughout the supplier relationship.
  8. Plan for the full lifecycle.
These practices can assist in preventing, mitigating, and responding to software vulnerabilities that may be introduced through the cyber supply chain and exploited by malicious actors.

https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508_1.pdf

Link(s):
https://thehackernews.com/2025/11/over-46000-fake-npm-packages-flood.html

https://www.endorlabs.com/learn/the-great-indonesian-tea-theft-analyzing-a-npm-spam-campaign