Automated Package-Publication Incident IndonesianFoods in the NPM Ecosystem Linked to Crypto Reward-Farming Scam

TL;DR

In November 2025, security researchers identified a large-scale surge of package publications on the NPM registry with similar structures and naming patterns. While initial reports speculated that this was a worm, this activity is likely the remnant of a long-dormant automation script tied to a cryptocurrency-reward scheme. 

Note: no active exploit in the wild has been verified, and the affected packages currently pose minimal risk. 

It appears that a developer wrote a spammer script and then uploaded it as part of the spam; the remnants of an automated publication script, originally tied to an outdated cryptocurrency reward-farming project. There are five distinct packages in total (copied across thousands of copies with slightly different names), wherein the only malicious functionality is the continuous publication of packages. Each package containing the publication script averages only 18 monthly downloads. 

That said, the event highlights the ongoing need for meticulous dependency hygiene and trustworthy registry practices.

Component & ecosystem involved

The incident involves a group of NPM packages published under multiple closely named accounts, using consistent code templates (often a Next.js base) and minor structural differences across versions and names (e.g., suffixes such as -wekto, -riris, -z3n). The packages appear to have been published en masse over time, likely via script automation, rather than installed and exploited in active systems. They reference an older crypto-reward campaign (tea.xyz) but do not exhibit confirmed malicious execution or self-propagation once installed.

Incident timeline

• Late 2023: Several base packages are published (for example: vointea, voinzaril), initially containing benign‐looking web app code.

• Shortly thereafter, Bulk publication activity appears, involving hundreds or thousands of derivative packages that use similar code templates with renamed suffixes.

• Gap of months: Activity pauses.

• Two months later: Additional bulk publication of further series (suffix patterns change).

• November 11, 2025: Community discussions emerge, suggesting that up to ~44,000 packages may be involved (although the actual bulk count may be lower).

• November 12, 2025: Analysis indicates that the packages are benign remnants of an old campaign, not active malware.

Impacted NPM packages

• Around five distinct “root” packages are identifiable (vointea, voinzaril, and variants with wekto, riris, and z3n suffixes).

• Estimated volume of copies: likely in the thousands (e.g., ~4,000-5,000 packages) rather than tens of thousands; the larger figures come from taking into account additional minor versions within packages.

• Average download volumes for these packages are extremely low (usually under 20 downloads/month).

• No confirmed downstream dependency compromise has been reported, and no known exploit chain has been observed.

• Because code execution requires manual invocation and no hidden remote payload has been identified, the risk to typical users remains low.

How the IndonesianFoods malware campaign happened

Rather than a classic worm or remote-exploit event, the activity appears to be an automated publication process: a script generating and publishing variants of a base web-app code template, likely for incentive or experiment purposes (e.g., tied to a “tea.xyz” cryptocurrency promotion).

Analysis revealed that the packages did not contain harmful payloads; instead, many simply included boilerplate or stubbed code. The publishing process lacked an automated exit condition and appeared to be manually triggered on specific days, rather than spreading autonomously through infected systems.

Key factors enabling the malware activity

• Use of one or more NPM accounts with elevated publication rights.

• A code template reused across hundreds or thousands of variants.

• Low-download packages with minimal usage

• No complex stealth or polymorphic payloads, but rather, noisy bulk publication.

Why wasn’t it flagged sooner?

• Because the packages had minimal downloads and no obvious runtime effects, they remained under the radar.

• Registry heuristics have historically focused on exploits or malicious post-install behavior rather than publication volume alone.

• The campaign appears semi-abandoned; no active exploitation has been observed.

Detection & scanning strategy

What developers and organizations can do

Developers can utilize tools like the Snyk Vulnerability Database to assess new dependencies based on their popularity, maintenance, security, and community metrics. 

It’s also important to ensure that automated scans cover both dependency health and code risk with tools like:

• Snyk Open Source (Software Composition Analysis) scans third-party libraries for known vulnerabilities and license issues. 

• Snyk Code (Static Application Security Testing) analyses custom code for vulnerabilities.

• Snyk Container and Snyk IaC scan container images and infrastructure-as-code configurations, respectively.

In the context of this incident, you can flag packages with extremely low download counts or repetitive content across many versions. It’s also beneficial to monitor for sudden large-scale uploads from a single account or template reuse across packages. Finally, leverage metadata heuristics such as last-published date, version history, number of maintainers, and community activity.

How Registry teams might improve monitoring

Monitoring can be improved by tracking bulk publishing patterns, specifically the volume and time of publication per account. It’s also important to implement spike detection for publication count, version churn, and the reuse of name patterns. Registry teams should incorporate checks for template reuse, which can be done by comparing file hashes across different packages. Finally, they should evaluate metadata “health” metrics early in the process, such as downloads, repository stars, and maintainer activity.

Mitigation and next steps

For end-users and organisations:

1. No immediate remediation is required if you have not referenced or installed any of the suspicious packages.

2. Review your dependency graph to detect unused or low-risk packages and remove or isolate rarely used dependencies.

3. Use Snyk Advisor pre-install: check package health and risk indicators before adding a new dependency.

4. Use npq: npq is an open source tool that prevents these kinds of packages from being installed, using heuristics such as download counts. 

5. Set policy gates in your CI/CD: e.g., block the addition of packages with download counts under a threshold or with no recent commits.

Final words

While this publication's appearance on the NPM registry raised headlines about a “worm” or supply-chain exploit, our investigation confirms that the event is not an active malware outbreak, but rather an artifact of past automation tied to a crypto campaign. The immediate risk to most users is low. 

Nonetheless, the incident is a timely reminder: even benign-looking packages can introduce supply-chain risk if they are unmanaged, poorly maintained, or obscure. Using tools like Snyk Advisor and Snyk for JavaScript, enforcing robust dependency policies, and maintaining strong registry monitoring practices helps maintain supply-chain hygiene across ecosystems.