IndonesianFoods Spam Campaign: What Security Teams Need To Know

A large-scale campaign known as IndonesianFoods has recently gained attention for its unusual impact on the npm ecosystem. For nearly 2 years, the threat actor behind this activity relied on full automation to push new packages into the registry every few seconds, creating a continuous stream of junk uploads that grew beyond 150,000 packages. These packages did not behave like typical malware because they did not steal data or compromise systems. This activity raised major supply chain concerns and prompted closer investigation from security researchers and the npm and GitHub teams.

What Is the IndonesianFoods Spam Campaign?

The IndonesianFoods campaign is a large-scale spam activity inside the npm ecosystem. The threat actor relied on automation to push thousands of packages into the registry at very short intervals. The campaign became fully visible by mid November 2025, when it started to receive broad attention from the security community. Researcher Paul McCarty was one of the first to highlight the problem after identifying 86,000 spam packages linked to at least 11 fake accounts. His findings triggered a wider investigation, and both security researchers and npm maintainers began working to understand the scope of the campaign and limit its impact

npm profile page displaying more than 12,850 spam packages. Source: GitHub

The threat actor used an unusual naming pattern that combined random Indonesian personal names with traditional food terms, which produced package names such as bella-tempe53-sumpek or zul-tapai9-kyuki. This internal dictionary of Indonesian themed words gave the campaign its recognizable identity and helped researchers link thousands of suspicious uploads to the same activity cluster.

Across the campaign, the threat actor created tens of thousands of packages that provided no real functionality. These uploads did not try to steal credentials, deploy malware or hide malicious code. The threat actor focused on volume. By pushing an extreme number of empty projects into npm, they aimed to pollute the registry and distort normal trust signals across the ecosystem.

By late 2025, the campaign had already released more than 150,000 spam packages on npm, and the number continued to rise. This represented nearly 1% of the entire registry and almost doubled the known pool of malicious or unwanted npm packages at the time. Each upload came from fabricated maintainer accounts and included no meaningful source code. The persistence, scale and formulaic structure of these uploads made the campaign stand out from previous isolated malicious package events.

Why Does the Threat Actor Create So Many Packages?

The threat actor wants to exploit reward systems that give economic value to package activity. TEA Protocol rewards new packages, version updates and download counts. By creating extreme volume, the threat actor multiplies these signals and collects more rewards.

Automation enables the threat actor to publish packages every few seconds. This creates artificial engagement and boosts visibility inside npm.

How Do These Packages Operate on a Technical Level?

Each package includes a basic Next.js template. This template acts as a decoy and makes the package look legitimate. The core logic hides in an auto publish script that creates new packages, updates metadata and publishes them automatically. Each new package links back to previous ones and builds a self expanding chain.

This pattern works like a worm. Once the threat actor triggers the process, it grows without manual intervention and generates continuous noise inside npm.

What Is the Threat Actor’s Main Objective?

The main objective is financial gain. The threat actor tries to farm TEA Protocol tokens by abusing reward logic. They simulate project activity and inflate package metrics without real development.

The operation focuses on economic manipulation at this stage. Yet the ecosystem-wide impact increases long term supply chain risk.

Do These Packages Carry Malicious Payloads?

Current samples do not contain classic malware such as credential theft, remote code execution or data exfiltration. Most packages act like automated spam units, built to publish new packages, inflate activity or link to other spam components.

A package.json file showing several IndonesianFoods spam packages added as dependencies. Source: SourceCodeRed

The campaign still carries real risk. As Paul McCarty highlights in his analysis, the payload already includes several behaviors that could support malicious activity later:

• Worm-like scripts (auto.js / publishScript.js) can create new npm packages in an infinite loop. This shows that the threat actor can automate large-scale actions and change direction at any time.
• Dependency-chain packages link to many other spam packages, which means a future malicious update could spread quickly through these chains.
• tea.yaml packages show clear intent to exploit the Tea Protocol for monetization. This financial motive increases the likelihood of future escalation.
• The payload already modifies package.json, forces packages to be public and assigns random versions. These abilities can easily be repurposed to inject harmful code or execute secondary actions.

So while the current wave does not deliver direct malicious behavior, the framework is already in place for harmful updates, stealthy payload insertion or ecosystem manipulation.
This makes the campaign a latent supply chain threat, not just harmless spam.

Why Is This a Supply Chain Risk?

The threat actor’s activity creates three main dangers.

1. Trust Erosion
   npm becomes filled with artificial activity. Real projects lose visibility and developers may select unsafe dependencies.
2. Ecosystem Pollution
   Security tools must process an unusual amount of versions and releases. This slows detection and increases overhead.
3. Payload Injection Potential
   Large noisy clusters help the threat actor hide harmful modules inside long chains.

How Does It Affect Search And Visibility Inside npm?

The constant release cycle pushes these packages into trending lists, recent updates and search results. This manipulates ranking signals and hides legitimate development activity.

Search systems that depend on recency or popularity give misleading results when the threat actor runs this type of spam operation.

What Should Developers Watch For?

Developers should check each dependency for red flags before installing.

• Unrealistic release speed
• Identical templates across many packages
• Repetitive or auto generated naming
• New publisher accounts with no history
• Dependency chains that do not fit normal logic
• Large upload bursts within minutes

Reading embedded scripts is important. Auto publish logic often hides inside build or helper files.

How Can Organizations Reduce Exposure?

Organizations can protect themselves with strong supply chain controls.

• Keep allow lists for approved packages
• Scan dependencies for abnormal version behavior
• Monitor sudden update spikes
• Block publisher accounts that show automated spam patterns
• Enforce security checks inside CI workflows
• Review dependency trees on a scheduled basis
• These steps help block suspicious packages before they enter production.

This incident shows how fast a simple script can disrupt an entire ecosystem. Organizations that maintain strong visibility over their dependencies and react quickly to abnormal activity stay far safer. A disciplined supply chain strategy is now a core part of modern cybersecurity, not an optional layer.