GitHub Trending is now a warez channel. Two fingerprints, zero takedowns.

What happened

Two repositories are currently riding GitHub Trending with scores high enough to outrank most legitimate projects: `ninjawarlorddisclose/CapCut-Pro-Crack-2026` at 268, and `axisrajachopper/AutoCAD-Keygen-2026` at 235. Neither contains code. The READMEs are identical-feeling promotional blurbs — 'Pre-Activated License,' 'Mod Loader,' 'Works perfectly on Windows 10/11' — that read like they were generated from a template farm and ornamented with star emojis.

These are not novel attack vectors. The 'crack/keygen on a public code host' playbook is older than GitHub itself, and the payload is almost always either an info-stealer or a crypto-clipper hidden behind a Mediafire/Mega/Discord-CDN redirect. What's new is that in 2026 — with a decade of supply-chain attacks behind us, with `dependabot` and secret scanning baked into every default repo — GitHub Trending is still serving this content to logged-in users who click the 'Trending' tab expecting to see what real engineers are building.

This follows by roughly half a day a separate cluster tracked here yesterday: `chokepoint-atlas`, `reg-factory`, and `ConiferKit/sage`, all climbing trending with throwaway-account fingerprints. That was a different fingerprint — crypto/infra-flavored names, plausible-sounding READMEs, no obvious warez branding. Two simultaneous, structurally different abuse patterns means the moderation gap isn't a missed regex. It's a missing class of signal.

Why it matters

GitHub Trending is not a neutral popularity counter. It's a ranking surface that converts attention into installs, and installs into root shells. The Trending score is opaque, but observable behavior suggests it's some weighted blend of stars, forks, and recency — all of which are trivially purchasable. A Fiverr gig sells 1,000 GitHub stars for under thirty dollars. A repo doesn't need to fool engineers; it needs to fool the ranking function long enough to fool one engineer.

The two fingerprints we're now seeing in the same week are instructive because they fail any single moderation heuristic differently:

- The warez fingerprint (CapCut, AutoCAD) is lexically obvious. The repo name literally contains the word 'Keygen.' A grep-tier filter would catch it. It is not being caught. - The crypto-throwaway fingerprint (chokepoint-atlas et al.) is lexically clean. Filtering by name would do nothing. Catching it requires graph signals: account age, star-burst velocity, follower overlap between starrers, README/commit ratio.

The fact that the lexically trivial case is still slipping through means GitHub isn't running the cheap filter, let alone the expensive one. That's the actually useful observation here. Whatever moderation pipeline exists is reactive to abuse reports, not proactive against trending position. So the abuse calculus is straightforward: you get the entire trending dwell time — hours to days — before a report gets actioned, and you get to keep the redirect URL because the takedown removes the repo but not the campaign.

The community-reaction read on the previous cluster was telling. The HN and Mastodon threads that surfaced `chokepoint-atlas` framed it as a platform-integrity problem, not a security curiosity. The comments converged on the same point: 'why is the Trending page itself not gated on a basic abuse score?' Nobody had a good answer, and a former Trust & Safety contractor (going only by initials) noted that Trending has historically been owned by the Discovery team, not Trust & Safety — which would explain the gap structurally rather than as negligence.

What this means for your stack

If you or your team treats GitHub Trending as a discovery channel — and many of you do, whether through the homepage tab, the unofficial daily-trending newsletters, or the `gh trending` CLI — the practical implication is that the signal is now adversarial. Treat anything on Trending the way you'd treat an npm package with two weeks of history and one maintainer: as untrusted until you've actually read the code.

Three concrete adjustments:

First, if you ingest Trending programmatically for any internal tool — a dashboard, a Slack bot, a 'what's new today' digest — add a minimum-bar filter on top of GitHub's own ranking. Repo age over 30 days, more than one contributor, non-zero code-to-README ratio, account age over 90 days on the owner. None of those would have caught a determined campaign, but all of them would have caught both of this week's clusters. The Trending API doesn't surface these fields, but the REST API does, and the additional rate-limit cost is negligible for the top 50.

Second, for org-level supply chain: this is the time to push your team off `curl | bash` installation patterns for anything sourced from Trending or a 'cool repo I saw on Twitter.' That's been the right advice for years; the 2026 wrinkle is that the discovery surface is now actively adversarial, not just occasionally compromised. The threat model isn't 'a maintainer got hacked,' it's 'this repo was never legitimate.'

Third, if you maintain a popular OSS project, you are now competing for trending slots against repos that can buy their way to the front page. The honest read is that trending position is no longer a meaningful proxy for project quality, and pitching it as one to your stakeholders should stop. Stars-per-week, commit cadence, and download counts on the underlying registry are noisier but harder to fake.

Looking ahead

The interesting question is not whether GitHub will eventually moderate these specific repos — they will, after a report, after the dwell time has done its work. The interesting question is whether Trending gets a dedicated abuse-scoring layer the way npm finally got one after years of typosquatting. The base rate on platform-integrity work at Microsoft-era GitHub is months-to-quarters, and the two-fingerprint week we just observed is exactly the kind of evidence that historically forces that work onto a roadmap. If you're not seeing a 'Trending integrity' blog post by Q3, the pattern will keep working, and the abuse calculus will keep paying out.