14 Oct 2026 · Desmond Okafor-Hale (editorial persona) · Agent artifact supply chain · on threat.cafe

Popular isn't vetted: install counts, stars and 'official-looking' names are the signals attackers fake first

Popularity is the first thing an attacker manufactures, because it is the first thing a developer checks. The documented 2026 campaigns against the agent ecosystem faked a network of forks and contributors around a cloned MCP server, borrowed the names of real vendors and projects, and reached the top of an AI search answer without any manipulation at all. None of those signals says whether the code was reviewed. The defensible approval rule ranks signals by how expensive they are to forge: known-bad status and pinned provenance first, independent audit second, publisher identity third, and stars, installs and search rank last, as tie-breakers only.

The consensus, stated fairly

The popularity heuristic deserves a fair hearing, because it is not stupid. A package with a million weekly installs has more people who would notice if it misbehaved. A repository with many contributors has more eyes on each change. A server that appears first in search results has, presumably, satisfied someone's ranking model. Developers choosing among forty MCP servers for the same database cannot read forty codebases. They use the crowd as a proxy for review.

The heuristic also lines up with how scarce security attention is actually spent. The Skillselion census of 79,848 agent-skill listings found that audit coverage follows popularity: the median audited listing had about 1,700 installs, the median unaudited one had 7, and the 12.2% of listings with any audit held 83.3% of all installs (Skillselion, data as of 12 August 2026). "Auditors triage by popularity," the authors write. If auditors use popularity to decide where to look, a developer doing the same looks like a reasonable local optimum.

The cracked assumption

The heuristic assumes popularity is produced by users. In an open registry it is produced by whoever produces it, and the cheapest producer is the attacker, who has a direct incentive and a budget measured in throwaway accounts.

Three documented cases show the cost structure.

Forks and contributors. Straiker's STAR Labs traced a trojanised copy of a legitimate Oura Ring MCP server. The attackers "created at least 5 fake GitHub accounts to build a network of seemingly legitimate repository forks," added fake accounts as contributors, and submitted the result to MCP Market, where it sat next to genuine projects. The payload was the StealC infostealer. The tell was an omission: the original author was not listed as a contributor (Straiker, 5 February 2026). Straiker notes in general terms that stars, forks and contributor counts "can be manufactured"; its write-up documents the fake forks and contributors specifically.

Search rank. Huntress found that a fake openclaw-installer repository was "the top-rated suggestion" in Bing's AI answer for "OpenClaw Windows," and that simply hosting the malware on GitHub was enough to get there. The installers delivered Vidar, GhostSocks and a macOS stealer between 2 and 10 February 2026; GitHub took the repositories down within eight hours of Huntress's report (Huntress, 4 March 2026). The attacker did not fake the signal. The ranking system generated it for free.

Official-looking names. The postmark-mcp package copied the name of an official Postmark library. Postmark said it "didn't develop, authorize, or have any involvement" with it; version 1.0.16 BCC'd every email to an outside address (The Hacker News, 29 September 2025). The openclaw-installer GitHub organisation name, Huntress observed, gave the repository "a level of inherent trust."

A note on a figure that circulates widely: a June 2026 article republished on the Cloud Security Alliance blog states that "five of the top seven most-downloaded skills were confirmed malware" at peak (CSA blog, 25 June 2026). The article names no registry, dataset or researcher for it, and no primary source could be found. It is left out of the argument here. The case does not need it.

The alternative mechanism in one sentence

A trust signal is worth what it costs an attacker to forge, so the approval rule should weight signals by forgery cost, not by how visible they are.

The forgeability ranking

Ordered from cheapest to forge to most expensive. The cost column is a judgement based on the cases above and on how each signal is produced; it is not a measured price.

Signal                          Who produces it            Forgery cost   Documented abuse
------------------------------  -------------------------  -------------  -------------------------------------
AI search / search rank         Ranking system             Near zero      Fake OpenClaw installer (Huntress)
Name resembling a vendor        Anyone who registers it    Near zero      postmark-mcp; openclaw-installer org
Marketplace / directory listing Submitter                  Low            Oura MCP clone on MCP Market (Straiker)
Stars, forks, contributors      Any GitHub account         Low            Oura MCP clone: 5 fake accounts
Install / download counts       Anyone who installs        Low            Counts are install events, not users
                                                                          (Skillselion methodology note)
Namespace or domain verified    Registry checks DNS/OAuth  Medium         Proves namespace control, not intent
Independent audit verdict       Third-party scanner        Medium-high    Auditors disagree on 12.7% of
                                                                          multi-rated listings (Skillselion)
Publisher = the named vendor    Vendor's own channels      High           Confirm on the vendor's own site
Known-bad status checked,       Your check, at install     High           Catches what is already reported
exact version pinned + hashed

Two rows need a caveat. Install counts are cheap to inflate in principle; no case above documents inflated counts, so that row rests on how counts are produced. And audit verdicts are expensive to forge but not expensive to get wrong: in the Skillselion set, one auditor rated a listing HIGH or CRITICAL while another rated it LOW or SAFE on 1,233 listings, 12.7% of those with more than one rating.

The second-order effect

Popularity-based selection does more than admit the occasional fake. It creates a perverse incentive. If developers pick the top result, attackers compete for the top result, and every cheap signal in the upper rows of the table becomes a target. Meanwhile the defensive signal, independent audit, is allocated by the same popularity, so a freshly inflated listing can sit high in rankings before it has been audited. A popularity-weighted rule therefore systematically favours the window in which a fake is most dangerous: after it looks popular and before anyone has looked at it.

Where the consensus still wins

For long-established packages with years of organic history, popularity remains a useful prior. Inflating a decade of downloads and a real maintainer community is not cheap. And for choosing between two artifacts that both pass the expensive checks, popularity is a fine tie-breaker. The argument here is about order, not abolition.

Where this argument would be wrong, and the Monday-morning rule

This argument would be wrong if registries began binding popularity signals to verified identity, for example by counting installs only from authenticated organisations or weighting stars by account age, so that the cheap rows became expensive. It would also weaken if audit coverage stopped tracking popularity, closing the window described above.

Until then, write the rule down:

Block any artifact whose exact version is known bad.
Require an exact version and a recorded hash. No floating tags.
Prefer artifacts with an independent audit; where auditors disagree, treat the worst verdict as the verdict until a person decides.
Confirm publisher identity on the vendor's own channels, not on the listing.
Use stars, installs and search rank only to choose between artifacts that passed 1 to 4.

Step 1 needs a known-bad list that spans skills, MCP servers and packages; that is what the threat.cafe board is building in the open.

Sources

#trust-signals #mcp-servers #agent-skills #typosquatting #supply-chain

All posts