The Great Indonesian Tea Theft

In the world of open‑source, the npm registry is a double‑edged sword: it democratizes code sharing, but it also provides a fertile ground for attackers. Endor Labs’ recent deep dive into a spam campaign originating in Indonesia reveals a meticulously engineered operation that hijacked legitimate packages, injected malicious payloads, and then replicated itself across the ecosystem.

“The attack was not a one‑off hack; it was an automated, self‑propagating worm that leveraged npm’s own publishing mechanisms,” explains Dr. Maya Tan, a supply‑chain security researcher at Endor Labs.

How the Worm Works

The campaign began by targeting well‑known, widely used packages—think lodash, axios, or react. Once a package was compromised, the attacker would publish a new, slightly tweaked version that included malicious code. The key to bypassing npm’s duplicate‑version checks was a simple yet clever trick: randomly incrementing the patch number.

npm publish --access public

The attacker’s script would then pause for 7–10 seconds before repeating the cycle, ensuring that the new version was propagated quickly but not flagged as a duplicate.

The core of the attack is captured in the following functions, which the article illustrates with screenshots:

• checkAndRemovePrivate() – Sanitizes the package to ensure it’s not marked as private before publishing.
• changePackageVersion() – Generates a random patch number, such as 2.3.1 or 4.1.3, to bypass npm’s duplicate detection.
• publishWithDelay() – Executes npm publish --access public and waits before looping again.

Once the malicious package is on the registry, any project that lists it as a dependency will automatically pull the compromised code. The attacker further amplified the spread by creating a self‑replicating network of packages that reference each other as dependencies, effectively forming a worm that travels through the dependency graph.

Why This Matters

1. Supply‑Chain Attack Surface – Even a single compromised package can infect thousands of downstream projects, many of which are critical infrastructure.
2. Evasion of Detection – By randomizing the version number and delaying publishes, the attacker sidestepped npm’s rate‑limiting and duplicate‑version safeguards.
3. Legacy Code Risks – Projects that have not audited their dependencies or relied on outdated packages are especially vulnerable.

“This isn’t just a clever prank; it’s a textbook example of how attackers can weaponize open‑source ecosystems,” notes Tan.

Defensive Measures

• Audit Dependencies – Use tools like npm audit, snyk, or dependabot to scan for known vulnerabilities and anomalous package updates.
• Lockfile Integrity – Treat package-lock.json or yarn.lock as a source of truth; any deviation should trigger a review.
• Publish Controls – If you maintain a package, enforce private: true in package.json until you’re ready to publish, and consider using a registry like npmjs.com’s two‑factor authentication.
• Monitor Version History – Watch for sudden, unexplained version bumps, especially if the new version is only a patch increment.

The Takeaway

The Indonesian tea‑theft campaign is a stark reminder that the open‑source model relies on a shared sense of trust. When that trust is breached, the ripple effects can be global. Developers, security teams, and organizations must treat dependency management as a critical security perimeter, not just a convenience.

Source: Endor Labs – “The Great Indonesian Tea Theft: Analyzing a NPM Spam Campaign”