The editorial argues that while the bulk of victims remain game cheaters and crypto shortcut-seekers, the meaningful shift over the last 18 months is that agentic IDEs like Cursor, Claude Code, Cline, and Aider can autonomously resolve dependencies and pull binaries from these poisoned repos. This widens the threat surface to professional developers who never personally evaluate the repo's legitimacy.
The researcher catalogued ~10,000 repos where the published release binary does not match the source code in the repo. They emphasize the mechanical simplicity: sockpuppet stars, forked commit history, copied READMEs, and SEO-targeted release tags are enough to manufacture trust, and GitHub takedowns are outpaced by template-driven respawning.
The catalogue clusters payloads into four functional buckets — infostealers (Lumma, RedLine, Raccoon), clipboard hijackers, RATs (AsyncRAT, Quasar), and droppers that fetch second-stage payloads from C2 servers. The dropper pattern in particular shows operators can swap malware families without re-uploading to GitHub, indicating an industrialized supply chain rather than one-off attacks.
A researcher at orchidfiles.com published a catalogue of roughly 10,000 GitHub repositories whose published release binaries do not match the source code in the repo. The pattern is mechanical and boring: a repo claims to be a Roblox executor, a Minecraft cheat, a crypto wallet recovery tool, a cracked copy of some commercial IDE, a node module, or a Python package. The source looks fine — sometimes it's even a fork of a legitimate project. The `Releases` tab ships a different binary entirely.
The payloads cluster into four buckets. Infostealers (Lumma, RedLine, Raccoon variants) that scrape browser-saved credentials, cookies, crypto wallet files, and Discord tokens. Clipboard hijackers that swap pasted crypto addresses mid-transaction. Remote-access trojans (AsyncRAT, Quasar) for persistent access. And a long tail of droppers that exist only to pull a second-stage payload from a C2 server, which lets the attacker swap malware families without re-uploading anything to GitHub.
The interesting part isn't the volume — it's the distribution mechanic. The repos farm legitimacy with the cheapest possible signals: a few hundred stars from sockpuppet accounts, a forked commit history, a README copied verbatim from a real project, and a release tag with a `.zip` or `.exe` that SEO-targets a search query like "free fortnite spoofer 2026" or "solana wallet recovery tool." GitHub's abuse team takes them down in waves; the operators spin up the next batch from the same templates within hours.
The demographic getting hit used to be narrow: kids looking for game cheats, crypto holders looking for shortcuts, people pirating software. That's still the bulk of victims. But the threat surface has quietly widened in the last 18 months, and the new mark is the one nobody is talking about: AI coding agents.
Think about how Cursor, Claude Code, Cline, Aider, or any agentic IDE actually resolves a request like "add a Discord bot library" or "pull in a Solana RPC helper." The agent searches, picks a repo, and — depending on how aggressively it's been configured — clones it, runs `npm install`, or in the worst case downloads a release artifact and executes it. The agent doesn't read the binary. It doesn't diff the release against the source. It trusts the star count, the recency of commits, and the plausibility of the README — exactly the three signals the malware operators are optimizing for.
This is a structural mismatch. Humans had weak defenses against this attack (we click "download" too); agents have effectively none. A junior dev might at least pause when an installer asks for admin rights. An agent running in a YOLO loop inside a dev container with the user's `~/.aws/credentials`, `~/.ssh/`, and a logged-in `gh` CLI mounted will happily execute whatever the release tarball contains. The blast radius is the entire developer environment.
The community reaction to the orchidfiles post on HN (755 points) was split along a predictable line. One camp argued GitHub is fundamentally not a distribution platform and treating releases as trusted is the bug. The other camp pointed out that 90% of real-world software supply chains *do* treat GitHub releases as canonical — Homebrew formulas, `go install`, `pip install git+https`, every CI pipeline that curls a release tarball. Both camps are right, which is the problem: the ecosystem grew a distribution mechanism without growing the verification primitives to match.
Sigstore exists. SLSA exists. Reproducible builds exist. They are not the default on GitHub, and adoption outside of a handful of paranoid projects (Kubernetes, Python core, a few Rust crates) is rounding-error small. The 10,000 number is not a ceiling — it's what one researcher found with one detection heuristic. The real number is larger and the cost of producing the next 10,000 is, charitably, a weekend.
The practical mitigations are unglamorous and you already know them; the question is whether you've actually wired them up.
Pin by commit SHA, not tag. Tags are mutable, releases are mutable, commit SHAs are not. If your `package.json`, `go.mod`, `requirements.txt`, or GitHub Actions workflow references a version tag instead of a SHA, you are trusting that the maintainer's account is not compromised and that GitHub itself hasn't been pwned at the abuse-team level. `dependabot` and `renovate` both support SHA pinning; turn it on.
Build from source in CI when you can. For binary dependencies you actually need (CLI tools, language servers, linters), prefer `cargo install`, `go install`, or a `Dockerfile` that compiles from a pinned commit over `curl | sh` from a release URL. It's slower. It's also the difference between "my CI runner got owned" and "my CI runner is fine."
Audit your agent's tool permissions. If you're running Claude Code, Cursor agents, or anything similar, the default `Bash` permission is a footgun. Restrict it to an allowlist. Disable auto-execution of downloaded binaries. Run the agent in a container with no host credential mounts. Your AI coding agent should have less filesystem and network authority than a junior contractor on day one, not more. Most teams have this backwards.
Stop using star count as a trust signal. It was never a good one. It is now actively adversarial — stars are the cheapest input to the attack. Look at commit history depth, contributor diversity, downstream dependents (GitHub's "Used by" count is harder to fake), and whether the project ships signed releases.
The medium-term fix is structural: GitHub needs to make Sigstore signing and SLSA provenance the default for releases, not an opt-in for the top 1% of projects. The short-term fix is cultural: stop treating "it's on GitHub" as a trust statement. The supply-chain attackers figured out a year ago that the new high-value target isn't the human developer — it's the agent acting on the human's behalf, with the human's credentials, at 3am. Until verification primitives catch up, every release binary is untrusted input. Act accordingly.
This is happening to me as well. I have a few moderately popular open source projects and I have found my name attached to new projects that I have nothing to do with or they are derivatives of my projects with redirection to unknown sites.Legitimate projects:https://github.com/jimmc4
> Why do they delete a commit and push a new one every few hours?May be to make it appear on the top of the "Last Updated" repositories in case someone searches for the repo or a keyword. So instead of the author's actual repo, the users endup cloning the trojan infected one.
I uploaded a sample found here (https://github.com/alexct142010-cell/McBackuper ) to Genus Codes (need an account): https://genuscodes.com/results/7ad4b911d05a12f91ab27ba3baa35... Seems to be related to the disco trojan family, by way of normalized function ma
Being reminded of this anecdote from NYMag's recent cover story (which had previously been reported in a WSJ story[0]) about a Disney engineer who downloaded an AI-gen tool from Github and "checked the code himself, it had looked legitimate":https://archive.is/yAUNy>
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> Why do they only clone new repositories, rather than popular ones? > Why do they delete a commit and push a new one every few hours?Because this is not targetted to humans. It's targetted to agents. They just need to appear on a fraction of the searches agents do to add dependencies and