- Seven Adspect-cloaked npm packages used traffic filtering, fake CAPTCHAs, and anti-research tricks; one acted as a decoy.
- Large-scale spam dubbed “IndonesianFoods” leveraged dormant scripts, patterned naming, and dependency chaining to flood the registry.
- Scope expanded from tens of thousands to over 150,000 packages; Amazon Inspector and OpenSSF coordinated MAL-IDs and takedowns.
- Mitigations include dependency audits, restricted publish rights, SCA for dormant files, rate limiting, SBOMs, and stronger account verification.
As the JavaScript ecosystem’s busiest hub, the npm registry is dealing with two very different threats at once: a small set of packages that quietly redirect users via cloaking, and a sprawling campaign that mass-publishes junk to chase crypto rewards. Both issues, while distinct, reveal familiar gaps in supply-chain defenses.
Researchers from multiple teams report that attackers combined traffic cloaking, automation, and open-source distribution to either steer victims to shady destinations or flood the index with low-value packages at unprecedented scale. These cases highlight how incentives and tooling can be twisted against the community when guardrails lag behind attacker creativity.
Cloaking-based redirects turn npm packages into traffic gates
Investigators identified seven npm packages linked to a single actor that use the Adspect service to split real users from researchers and hide the true payload. The packages, attributed to a now-removed account named “dino_reborn,” appeared between September and November 2025 with download counts in the low hundreds.
Six of the packages carried a roughly 39 kB component that fingerprints the environment, blocks developer tooling in the browser (to hinder analysis), and immediately executes through JavaScript’s IIFE pattern once imported. A seventh package, “signals-embed,” stood out by delivering a harmless white page as a decoy rather than overtly malicious behavior.
When the implanted sites are loaded, traffic is sent through a proxy endpoint at association-googlexyz/adspect-proxyphp, which helps decide whether the visitor looks like a victim or a researcher. If tagged as a victim, the user sees a fake CAPTCHA that ultimately forwards to crypto-themed pages impersonating services (e.g., StandX). If flagged as a likely analyst, the page shows a plain decoy view and even includes boilerplate relating to a fictitious company dubbed Offlido.
Adspect markets itself as a cloud cloaking service for blocking “unwanted” traffic like bots or AV crawlers, offering tiered plans and promising “bulletproof cloaking.” Seeing this ad-tech style filtering embedded in npm packages remains unusual, and researchers note it effectively wraps traffic-gating logic into open-source distribution so the code decides in real time who gets a real payload.
Because the logic runs as soon as the asset loads, no user interaction is needed to trigger the behavior. That immediate execution flow—and the browser-level blocks on developer tools—complicate analysis and help keep the scheme out of sight for casual inspection.
A sprawling npm spam operation driven by token rewards
In a separate development, security teams uncovered an expansive set of spammy npm packages published in waves over roughly two years, initially appearing benign but designed for replication and financial gain. Collectively known as “IndonesianFoods,” the effort used a consistent naming scheme that pairs random Indonesian first names with food terms and various suffixes to generate thousands of plausible-sounding packages.
On the surface, many entries looked legitimate—some even shipped functional Next.js templates. But buried inside were unused files like auto.js or publishScript.js that, when run manually, cranked out new packages at high speed, tweaked versions, and removed privacy guardrails. It’s this easy-to-launch automation—rather than truly autonomous worm-like behavior—that fueled rapid scale.
The web of spam often referenced eight to ten other bogus dependencies, ballooning the impact through dependency chains. Install one, and npm might silently pull dozens more, amplifying registry clutter without any immediate, obvious harm to developers’ machines.
Monetization appears tied to the TEA protocol’s open-source rewards. Multiple packages included tea.yaml pointing to specific accounts and wallet addresses—suggesting an effort to inflate impact scores and extract token payouts. Documentation in some cases even called out these earnings, reinforcing the notion of a coordinated, profit-driven plan rather than random experimentation.
Different research groups measured the wave at various stages: findings ranged from roughly 43,000 spam uploads earlier in the campaign to more than 100,000 later, with Amazon Inspector ultimately reporting 150,000+ packages across multiple accounts by mid-November 2025. The growth exposed registry rate limits, metadata checks, and pattern detection as areas needing attention.
Why scanners missed it and what changed
A key reason the campaign lasted so long is that most automated tooling hunts for install-time malware—for example, suspicious postinstall hooks or file-system activity. Here, the payload was idle and unreferenced, so common heuristics labeled it harmless. Without active triggers, scanners frequently treated the extra files as benign clutter.
Another factor was the scale and cadence of publishing: scripts could push fresh packages every few seconds, creating overwhelming volume without tripping classic malware signatures. Reports note that several security data systems were flooded with advisories, including massive spikes in OSV-linked alerts.
By late October 2025, Amazon Inspector deployed a new detection rule paired with AI-driven patterning to spot telltale traits such as tea.yaml presence, cloned or minimal code, predictable naming, automated generation fingerprints, and circular dependency chains. After confirming the patterns in early November, the team coordinated with the Open Source Security Foundation (OpenSSF) to assign MAL-IDs quickly—the average turnaround was about 30 minutes.
One important nuance: some early commentary called the campaign a “worm.” Subsequent updates clarified that the replication logic is not self-propagating; it must be executed. That correction matters, but the outcome—fast, industrialized package flooding—still strained registry infrastructure and trust.
Practical steps to reduce exposure
Organizations should approach npm risk reduction as a continuous, layered process, mixing proactive dependency hygiene with policy and registry-aware controls. The following measures reflect what researchers and ecosystem stewards are advising.
- Verify dependencies against lists of known-bad publishers and remove suspicious or low-quality packages.
- Restrict npm publish permissions to CI/CD and vetted maintainers; prevent accidental execution of replication scripts.
- Adopt software composition analysis (SCA) capable of flagging dormant files, patterned naming, or circular dependency webs.
- Introduce rate limiting and behavioral monitoring for high-volume submissions; consider CAPTCHA and stricter account verification.
- Harden your pipeline with SBOMs, version pinning, and isolated CI/CD, plus rigorous signature and provenance checks.
When combined, these measures cut down on registry noise while making malicious or manipulative behavior easier to spot. They also reduce the blast radius if a bad package slips into the graph.
Across both incidents, the through line is simple: attackers follow incentives and blind spots. Whether it is cloaking logic that filters analysts from victims or automated token-farming that drowns out legitimate work, the answer lies in better visibility, faster collaboration, and policies that make abuse harder and costlier at scale.
