Reputation Radar #5: Popular Is Not the Same as Safe
Threat IntelligenceInfrastructure ReputationSOCWeekly Report

Reputation Radar #5: Popular Is Not the Same as Safe

Reput.io Team
6 min read

Our weekly read on the infosec landscape through an infrastructure-reputation lens. This week: a self-replicating worm rode the trust of hundreds of hugely popular npm packages, Unit 42 turned AI loose and found 14,000 unreported bugs in mature open source, plus the Cisco ASA zero-days, an Azure Cosmos DB cross-tenant escape, and a coordinated OT campaign against Minnesota water systems.

There's a reflex almost everyone in tech shares: a package with tens of millions of weekly downloads, or an open source project that's been around for a decade, must be safe. Too many eyes on it. Too widely used to be dangerous. This week handed us two clean reminders that popularity and maturity are reputation signals, not verdicts — one from an attacker, one from a research team, both pointing at the same blind spot.

The worm rode the download counts

On August 4, someone compromised the maintainer account behind keyv and cacheable, two caching libraries that sit deep in the JavaScript dependency tree. If you've never heard of them, that's the point: they're the kind of quiet, foundational package you pull in through something else. ESLint reaches keyv through file-entry-cache. Socket notes the affected packages "collectively account for tens of millions of weekly downloads" (Socket).

What made this one spread wasn't the initial compromise, it was the self-replication. The malicious version ran a preinstall hook that pulled down a standalone Bun runtime to dodge Node process monitoring, then harvested everything it could reach: cloud instance metadata, AWS/GCP/Azure keys, HashiCorp Vault, Kubernetes service-account tokens, GitHub Actions OIDC, and npm tokens. Then it did the clever, ugly thing: it used those stolen npm tokens to repackage other packages the victim could publish, injected the same hook, bumped the version, and republished. JFrog and Expel tracked the wave past 400 packages across 1,700+ versions as the credentials cascaded from one maintainer to the next (JFrog, Expel).

The reputation angle is the whole story here. A package's popularity is exactly what the worm converts into reach. The more downloads, the deeper it's buried in dependency trees, the more machines run its install hooks without a second look. And the registry it comes from is the definition of trusted infrastructure. We run it against our own API and it lands where it should:

{ "indicator": "registry.npmjs.org",
  "status": "whitelisted",
  "verdict": "investigate" }

Whitelisted, and ranked in the top 10,000 domains on earth, because it genuinely is the npm registry. But investigate, not benign, because being the real registry tells you nothing about the specific package version being pulled through it right now. The trust belongs to the pipe. It was never transferable to the water.

Fourteen thousand bugs nobody had found

The other half of the week came from Palo Alto's Unit 42, and it's the same lesson from the defender's side. They built an agentic system called NOVA and pointed it at open source: 3,915 projects in two months, 14,090 confirmed vulnerabilities, and 99.4% of them previously unreported (Unit 42). Forty percent rated high or critical.

Sit with that number. These aren't obscure abandoned repos, they're the projects real software depends on, and the overwhelming majority of what an AI found in two months had never been reported by anyone. The "too many eyes on it" assumption was doing a lot of quiet work in our threat models, and it turns out the eyes were mostly not looking. Unit 42's blunt framing is that "the patch window has collapsed" — if a model can autonomously find, prove, and even patch a semantic bug like an SSRF or an access-control bypass, so can the other side, at the same scale.

We're not in the vulnerability-scanning business, so why does this land in a reputation report? Because it's the identical fallacy the npm worm exploited, just aimed at code instead of packages. Mature and widely-used is a statement about adoption, not about safety. A ten-year-old dependency with a million installs has the reputation of being battle-tested. This week says the battle mostly hadn't happened yet, it was just waiting for someone with the patience to look at all of it at once.

The through-line for a SOC

Both stories rhyme. An attacker turned package popularity into worm propagation; a research team turned the myth of "well-audited because widely-used" into fourteen thousand open bugs. The connective tissue is a habit worth breaking: treating a reputation signal as if it settled the question.

It's the same argument we keep making about infrastructure. Top-10K ranking, a real registry, a decade-old dependency, a legitimate cloud provider: these all tell you a thing is what it claims to be. None of them tell you it's safe to wave through today. That gap between "real" and "safe" is where the whole week lived, and it's exactly why we keep trusted, popular infrastructure at investigate rather than benign. The alternative is letting reputation answer a question it was never able to answer.

Also on the radar

  • Cisco ASA and FTD zero-days are under active exploitation (CVE-2025-20333, CVE-2025-20362), tracked to UAT4356/Storm-1849 (Tenable). If you run ASA in the path, this is the week's priority patch.
  • Wiz disclosed "CosmosEscape," an Azure Cosmos DB flaw that let a Gremlin-API query escape its sandbox and reach the platform master key, a cross-tenant risk touching systems behind Entra ID, Teams, and Copilot (CSO Online). Microsoft patched it within 48 hours and reports no customer action is required.
  • A coordinated OT campaign hit 30+ Minnesota water and wastewater systems, attributed in part to CyberAv3ngers (BleepingComputer, LevelBlue's July review). OT and ICS teams, this one's for you.
  • Cisco Talos flagged attackers splitting malicious tasks across prompts to bypass AI safety controls (Infosecurity Magazine). A small, practical note for anyone standing up LLM-backed tooling.

If you want the longer version of why we clear the known-good first instead of trusting it outright, we made that case in why clearing the known-good first is the right triage order.

See you next week.

Sources are linked inline; credit to the original researchers and reporters. If we got a detail wrong, tell us, we'll fix it.

About Reputation Radar: This is written by the small team building Reput.io, not a marketing department. It's our weekly read on the infosec landscape, with a bias toward the thing we care most about: how attackers borrow the reputation of legitimate infrastructure so their traffic looks normal. Every item links the original reporting, and any claim about our own API is run against it live and labelled.

Ready to Try Reput.io?

Start reducing false positives today with our free plan.