I keep my code on a box in my house. Ten thousand trojan repos on GitHub just made that look less paranoid.
A researcher just found 10,000 GitHub repos serving Trojan malware, cloned from real projects and wearing their real commit history as a disguise. Why 'it's on GitHub' stopped meaning 'it's fine', why vigilance is the wrong fix, and why my code lives on a box in my office.
I have never been comfortable putting everything "somewhere." Not in any paranoid sense, and not because I have anything to hide. It is a smaller, older instinct. Anything you build on top of a platform you do not own can break underneath you, or quietly get used in a way you never agreed to, and you will be the last to find out. So my projects live on a Gitea server in the corner of my office. Not secret. Just mine.
Somewhere along the way the open-source world made a collective decision I do not remember signing. GitHub became the place. "It's on GitHub" turned into shorthand for "it's fine," a trust signal you could lean on without thinking about it. Last week a researcher handed me ten thousand reasons to think about it.
Ten thousand clones wearing real faces
On 18 June an independent researcher who goes by Orchid published a short, grim finding: ten thousand GitHub repositories serving Trojan malware. About a quarter of everything their search turned up, and roughly ninety times the scale a separate team had documented only two months earlier.
The method is the unsettling part. The attackers do not stand up a sketchy-looking repo. They clone a real, freshly created one, keep its actual commit history and contributor list intact, and add a single commit titled "Update README.md" that points at a ZIP. Inside the ZIP is a launcher, a LuaJIT-packed loader called SmartLoader that fetches its command server through a blockchain smart contract, and a StealC infostealer waiting at the end of the chain. Hand the download link to VirusTotal and it sees nothing. Hand it the actual zip and the Trojan shows up at once.
Everything a careful developer is taught to check, those clones pass. Commit history, real contributors, project age, a plausible README. Those signals exist so a human can glance at a repo and decide it is safe to use. Point them at an attacker and they become camouflage, which is the polite technical word for a disguise that works.
The activity that looks like maintenance
The detail that should bother anyone leaning on automated scanning is how these repos hide in plain sight. Every few hours they overwrite the latest commit, a force-push that does nothing except reset the clock. GitHub's anomaly detection is tuned to catch sudden suspicious bursts, the shape of a fresh intrusion. A repo that has been calmly re-pushing the same commit for a year does not look like an intrusion. It looks like someone tending a project. So it sailed through, for over a year, while quietly handing out an infostealer.
When Orchid reported two of the repos to GitHub, the answer was two weeks of silence, then another month before they came down. The takedowns only sped up once the story reached the front page of Hacker News. Reactive moderation at internet scale is a footrace you lose, and everyone running it knows it.
This is where it stops being a malware story and becomes a design story. GitHub already records the one thing that cannot be faked: the actual account that pushed each commit. It lives in the Events API, it is unforgeable, and GitHub chooses not to show it on the commit page a reviewer actually reads, then lets it expire from public view after about ninety days. Researchers at Deep Specter reported precisely this, the timestamp backdating and author impersonation that supply-chain worms like Shai-Hulud feed on, and GitHub closed both reports as ineligible, not a security risk.
I have written before about the npm supply-chain wave, and this is the same animal from a different angle. For years the answer to "can I trust this code" was "it has stars, it has history, it is on GitHub." A coordinated decade of attacks is patiently proving that the answer became the attack surface.
Stop telling people to be careful
The instinct after a story like this is to tell developers to be more careful. Check the repo. Read the commits. Verify before you clone. That instinct is wrong, and not by a little. The entire point of Orchid's ten thousand clones is that they are built to survive a careful read. Vigilance is the exact thing the camouflage is designed to defeat, and asking forty million developers to manually out-investigate a year-long automated campaign is not a security model. It is a way to assign blame after the breach.
So the answer is not more eyes on the code. It is provenance. GitHub is sitting on the one signal that cannot be forged and keeping it off the page. Put the real pusher on the commit, keep it there forever, make where a thing came from something a reviewer sees at a glance instead of something that quietly expires. That is a platform decision, and platform problems want platform fixes, not a sternly worded reminder aimed at the people least able to fix them.
The bigger thought, the one I keep circling back to, is that the whole open-source supply chain was built on a quiet assumption that a popular, well-dressed repository is a trustworthy one. The assumption held for a long time because nobody serious was attacking it. Now everybody is, and it needs rebuilding from the floor, not patching at the edges.
Meanwhile my code stays on the box in the corner, where the only account that can push a commit is mine, and the only thing underneath it that can break is something I put there myself. I would rather own the small risk I can see than rent the large one I cannot.
Od tego autora
Buy Me a Coffee
Fuel my creativity with a coffee — every sip keeps this blog running!
Support This Blog — Because Heroes Deserve Recognition!
Whether it's a one-time tip or a subscription, your support keeps this blog alive and kicking. Thank you for being awesome!
Tip OnceYou read this far.
I write up the boring infrastructure decisions that turn out to matter, once a week, by hand. Subscribe if owning your own stack is your kind of hobby.
SubscribeDOGE: DSYxsbfWKAX8wWED9aWeqLEVXU7KihKk6h
Canary: pro-it.rocks-canary-031ac598
