editorially independent. We may make money when you click on links
to our partners.
Learn More
A newly uncovered large-scale spam campaign in the npm ecosystem has exposed significant weaknesses in package registry security, dependency hygiene, and open-source incentive protocols.
Security researcher Paul McCarty revealed that more than 43,000 malicious or spam packages — collectively dubbed the IndonesianFoods worm — were published across at least eleven npm accounts over a two-year period without detection.
Although these packages contained no active malware, they embedded dormant payloads and formed a self-replicating dependency network, representing over one-percent of the entire npm ecosystem.
Their existence underscores a growing need for stronger supply chain defenses, automated detection, and governance in open-source ecosystems.
Why Thousands of Spam Packages Looked Legitimate
The IndonesianFoods worm derives its name from its unique naming scheme.
Each package generates a name by combining randomly selected Indonesian first names (e.g., andi, budi, zul) with Indonesian food terms (e.g., sate, rendang, tapai) plus numeric and suffix variations.
This method produced tens of thousands of seemingly unrelated packages with patterned but plausible names.
Researchers at Endor Labs determined that the campaign was related to an attack first identified in 2024 in which adversaries attempted to abuse the TEA protocol — a blockchain-based reward system for open-source contributions.
Spam Packages That Multiply
Although the packages appear legitimate on the surface — often containing functional Next.js templates with real dependencies — the payload sits dormant.
Each package includes an unused JavaScript file, typically named auto.js or publishScript.js.
When manually executed, this script removes privacy protections, randomizes version numbers, generates a new randomized package name, and repeatedly publishes new packages to npm in an infinite loop.
A single execution can publish more than 17,000 packages per day, explaining how the campaign scaled to nearly 44,000 entries.
Compounding the problem, each spam package often includes eight to ten dependencies that reference other spam packages, creating a worm-like propagation mechanism.
When developers install one such package, npm automatically retrieves dozens more, multiplying the footprint of the campaign across the ecosystem.
Monetizing NPM Spam Through TEA Token Manipulation
Researchers also discovered tea.yaml files embedded in attacker-controlled packages, referencing specific TEA accounts and cryptocurrency wallet addresses.
These files appear designed to artificially inflate TEA impact scores and claim token rewards intended for legitimate open-source contributions.
Documentation in at least one package openly advertises these token earnings. This monetization layer indicates a coordinated effort to generate financial gain by abusing the TEA reward model, not an isolated or accidental misuse.
Why the Campaign Went Undetected
The campaign evaded detection for nearly two years due to weaknesses in current security scanning methods.
Most automated scanners focus on malicious code that executes during installation, such as postinstall hooks or suspicious file-system operations.
These packages contained no active malware and triggered no installation-time activity, making them appear benign.
Furthermore, the dormant payload files were not referenced by any code paths, causing scanners to treat them as unused artifacts.
The lack of npm rate-limiting, insufficient metadata analysis, and absence of pattern detection for bulk-published packages also contributed to the campaign’s longevity.
A Shift Toward Ecosystem-Wide Manipulation
The IndonesianFoods worm highlights several systemic issues in open-source ecosystems.
Large-scale, low-signal spam can degrade registry quality, inflate dependency trees, and erode developer trust.
The attack also demonstrates that adversaries are increasingly willing to exploit alternative revenue streams — such as TEA token mining — rather than deploying direct malware.
Combined with multiple coordinated accounts, evolving variants, and cross-dependency propagation, the campaign reflects a shift toward strategic, ecosystem-wide manipulation rather than traditional high-value package compromise.
Essential Defenses Against Large-Scale Package Abuse
Organizations evaluating their exposure to the IndonesianFoods npm spam campaign must take a proactive and methodical approach to safeguarding their software supply chains.
Because these packages operated at massive scale while remaining dormant and undetected for nearly two years, traditional installation-time scanners are not enough.
Strengthening access controls, enhancing dependency visibility, and tightening registry-level defenses are essential steps to preventing similar abuses in the future.
- Verify dependencies against the known list of compromised accounts and remove suspicious packages.
- Restrict npm publish rights to CI/CD systems and authorized maintainers, preventing accidental execution of malicious scripts.
- Enforce software composition analysis (SCA) capable of detecting dormant files, unusual naming patterns, or circular dependency structures.
- Monitor for anomalous publishing behavior and introduce rate limiting or CAPTCHA for high-volume package submissions.
- Require stronger identity verification for npm accounts engaged in large-scale publishing activity.
By strengthening access controls, improving dependency visibility, and enhancing registry safeguards, organizations and ecosystem stewards can reduce supply chain risk and build cyber resilience.
A New Era of Open-Source Supply Chain Abuse
The IndonesianFoods campaign demonstrates that volume, persistence, and clever abuse of open-source incentives can enable attackers to operate unnoticed for years.
While the packages lacked immediate malicious code, their scale, worm-like dependency structure, and monetization strategy reveal the growing sophistication of supply chain spam.
This kind of silent, large-scale manipulation underscores why modern software supply chain security must evolve just as quickly as the threats targeting it.
