Another Round of TEA Protocol Spam Floods npm, But It’s Not a Worm

You may have seen recent reports calling the latest npm spam campaign a “worm.” In reality, this is the same TEA Protocol spam activity Socket has been tracking for nearly two years, a long-running pattern of registry abuse tied to the tea[.]xyz crypto reward scheme. The goal of these spam campaigns is to artificially inflate the number of dependents for spammers' projects.

As with previous waves, these packages use random naming patterns and include tea.yaml files to farm TEA tokens by inflating fake dependency networks. The current batch appears to reuse the same kind of scripts, accounts, and publishing patterns we have observed and described in our earlier coverage.

Paul McCarty at Source Code Red did excellent work uncovering the latest wave and ensuring that the packages were taken down. Efforts like his protect the integrity of the package registries and thus provide a valuable service for developers and the open-source community as a whole. OpenSSF reacted quickly and assigned malicious package identifiers (MAL-IDs) to the detected packages and the up to 150,000 identified packages from this campaign have meanwhile been taken down from npm.

Why It's Not a Worm#

Two characteristics of this campaign have led to the "worm" label, but neither represents true worm behavior.

1. The Dependency Chain "Spreading"

Some of the coverage has pointed to the fact that these spam packages reference each other as dependencies, creating a worm-like spreading mechanism. When you install one of these packages, npm automatically fetches its dependency tree, and with each spam package including several other spam packages as dependencies, the number of installed packages can become massive.

However, this is fundamentally different from a worm's self-replication. What's being described here is normal npm dependency resolution behavior, not autonomous malicious code execution. Every legitimate package that has dependencies exhibits this same "spreading" behavior when installed.

Dependency resolution is not code execution. Worms propagate through running code; these packages propagate because npm is doing exactly what it’s designed to do.

2. The Publishing Script's Replication Intent

The more substantial reason for the "worm" label is the publish script itself that is included in the packages. When executed, the script runs in an infinite loop, continuously generating random package names, modifying package.json files, and publishing new packages to npm. This creates a replicating pattern that superficially resembles worm behavior.

However, there are several critical differences: Worms, by definition, are malicious programs that self-replicate automatically by executing code without user intervention. A true worm would execute malicious code during package installation (via postinstall hooks or other lifecycle scripts) and autonomously spread to other systems through that code execution. This is not happening here.

The publish script sits completely inert in the package structure with no automatic execution mechanism. Installing these packages or loading them performs no malicious actions whatsoever: the script only runs if a developer manually executes either the auto.js or publishScript.js files with Node, which would require deliberate action on a file that serves no apparent purpose.

Assuming it was run as a postinstall script, it still wouldn't self-replicate. Instead, it would crash. Why? The current working directory is set to that package's directory inside node_modules during a lifecycle script's execution. The script attempts to read package-lock.json, which doesn't exist in this location, causing it to fail with an ENOENT error.

This is a poorly written spam publishing script that someone manually runs from a few controlled accounts, not a self-replicating worm that propagates across the ecosystem. The fact that these scripts ended up in the published packages, easily excludable via .npmignore, reveals a sloppy spam operation, not a sophisticated malware campaign.

But even assuming the script would run successfully, it would still fail for the vast majority of developers, as they aren't authenticated with npm (since most users only run npm install to download packages and never publish packages themselves). More importantly, developers are unlikely to install these packages in the first place since they use random Indonesian food names rather than typosquatting popular packages.

There's no evidence of account takeovers or the script spreading to victim machines and publishing packages from their accounts: the large number of uncovered spam packages trace back to the same dozen or so npm accounts created specifically for this campaign.

Operationally Annoying But Not Technically Dangerous#

The architectural failings of the TEA protocol's attempt to incentivize open source developers have become the scourge of multiple open source package registries. While these packages don’t contain malicious code or pose a security threat to developers, they still create operational friction across the ecosystem:

• They consume registry and scanning bandwidth, potentially impacting tools that rely on npm metadata.
• They pollute dependency graphs, which can slightly degrade developer experience and visibility for legitimate packages.
• At scale, they create noise that complicates automated malware detection and incident response (signal-to-noise problem).

At Socket, we’re well aware of this campaign. Because we continuously ingest and analyze every new package published to npm, we see this spam as it happens, and it generates a remarkable amount of junk. These automated bursts of garbage packages don’t pose a threat, but they do highlight how large-scale abuse can pollute the ecosystem and waste registry resources.

Despite this operational impact, there is no evidence of malicious payloads, account compromises, or self-propagating behavior. The result is a massive nuisance that affects registry maintainers more than developers.

Previous Coverage

• tea.xyz Spam Plagues npm and RubyGems Package Registries — April 26, 2024
• Massive Automated Spam Campaign Abuses GitHub to Flood npm Registry with Thousands of Garbage Tea[.]xyz Packages — July 11, 2024