The Morning My GitHub Went Empty
It started with something small: I logged into my GitHub account and noticed my repository list looked... off. Where there used to be years of work — personal projects, client codebases, internal tools for the companies I run — there was exactly one repository. It wasn't mine. It was a spam repo with a name pointing to a Telegram account, "waiting" for me to reach out.
At first I assumed it was a display bug, a filter I'd accidentally applied, maybe the wrong account. It wasn't. My personal account and every organization I had access to — seven of them, spanning multiple businesses — had been wiped clean. Not just a few repos. All of them.
What Actually Happened
Once I pulled my GitHub security audit log, the picture became clear fast. Every deletion event was tagged the same way: authenticated via a classic Personal Access Token, executed through the API, using an automated script. Not a person clicking "delete" repeatedly — a script, tearing through account after account.
The numbers tell the story better than I can: over 60 repositories, across every organization I belonged to, deleted within roughly 52 seconds. No human does that by hand. This was a script running with a token that had far more access than it should have — scopes covering full repo control, organization administration, workflows, and more.
Right after the deletion, the same token was used to create a single new repository — a placeholder pointing to a Telegram handle. That was the hook. Within minutes of finding my account empty, I was in a chat with someone demanding 1.2 BTC to "share back" what they claimed to have backed up.
The Extortion Attempt
The person on the other end tried to project legitimacy — claiming they'd "found serious security issues" on my infrastructure and were owed a "bounty" for finding them. When I asked directly where the breach occurred — GitHub or my own servers, and if servers, which one — they never answered. That's usually the tell: real security researchers lead with specifics. Extortionists lead with vague threats and a price tag.
They sent a scan output as "proof" — the result of running a secret-scanning tool against the git history of the repos they'd already cloned before deleting them. It did contain some real exposed credentials from old commits (a lesson in itself — more on that below), but on closer inspection, the actual blast radius was limited: internal-only network dependencies, a service account scoped to a throwaway test environment, and API keys that weren't even in active use anymore.
I didn't negotiate, didn't confirm any technical details back to them, and didn't pay. I documented everything — the audit log, the chat transcript, the "proof" file — reported the compromise and the extortion attempt to GitHub Support and to my country's cybercrime unit, then closed the conversation for good.
How This Actually Happened
The root cause wasn't some sophisticated zero-day. It was a leaked personal access token — almost certainly one with far broader scopes than it ever needed, sitting somewhere it shouldn't have (a config file, a script, a machine that got compromised, or simply copy-pasted somewhere insecure at some point). Once someone had that token, GitHub's API did exactly what it was designed to do: whatever the token's scopes allowed. Broad scopes meant broad damage.
The secondary lesson came from the "proof" file itself: old commits in my repositories contained hardcoded credentials — database passwords, API keys, a cloud service account key — sitting in git history going back months, sometimes years. None of that caused the breach, but it turned a bad day into a scarier one, and it's exactly the kind of thing that turns "we deleted your repos" into "we also have your secrets."
Where I Think GitHub Should Share Some of the Blame
I want to be fair here: the root cause was a leaked token, and that's on me. But I don't think that's the whole story, and I don't think GitHub gets a free pass either.
A script authenticated with a single token deleted over 60 repositories across seven different organizations in about 52 seconds. That is not normal user behavior by any reasonable definition. No legitimate workflow looks like that — not a CI pipeline, not a migration script, not a bulk cleanup job. And yet nothing stopped it, throttled it, paused it, or even flagged it for review. No email alert asking "did you really mean to delete 60 repos just now?" No temporary lock pending confirmation. No step-up authentication requirement for a sudden burst of destructive, irreversible actions.
Compare that to how seriously other high-stakes platforms treat bulk destructive actions or logins from unfamiliar devices — banks freeze suspicious transaction patterns, email providers challenge logins from new locations, and plenty of SaaS platforms require re-authentication before anything irreversible happens at scale. GitHub, hosting the literal source code of businesses and livelihoods, let a token — used the way it appeared to be used here, from what looked like unfamiliar automated tooling — tear through everything I had access to without a single circuit breaker in place.
It gets worse when I went looking for answers in my own audit log. The very fields that should have told me where this happened from — IP address, location — were simply blank for every one of these API-driven events. I couldn't tell you what country the request came from, let alone flag it as unfamiliar, because GitHub's own audit trail didn't capture it for me. If the platform isn't recording that basic signal, it's hard to imagine it's using it to detect anomalies in real time either.
A leaked token is a mistake. Letting that token annihilate seven organizations in under a minute, with zero friction and zero visibility into the origin of the request, feels like a gap in the platform itself — not just bad luck on my end.
What I'd Tell Anyone Using GitHub (or Any Git Host)
- Stop using classic personal access tokens with broad scopes. Use fine-grained tokens, scoped to exactly the repo and permission you need, with an expiration date. A token that can do everything is a single point of catastrophic failure.
- Enable 2FA everywhere — on your account and, if you manage an organization, enforce it for every member.
- Never hardcode secrets in your code, even in "private" repos. Use environment variables, a secrets manager, or at minimum a
.gitignore'd config file that never gets committed. Old commits don't disappear just because you delete the file later — the history remains. - Run a secret scanner on your own repos regularly — the same tool an attacker used against me is free and open-source. Better you find your own exposed credentials than someone else does.
- Back up outside the platform you're building on. If your only copy of your code lives on GitHub, a compromised account can end your entire codebase in under a minute — which is exactly what happened to me.
- If you're ever targeted for extortion: don't pay, don't negotiate, don't confirm details. Document everything, report it, and walk away. Paying doesn't guarantee recovery, and it confirms you're a payer to whoever is watching.
Why I Moved to Gitea
After going through this, relying entirely on a third-party platform — no matter how reputable — for the sole copy of critical business code felt like an unnecessary risk. I've since set up Gitea, self-hosted on my own subdomain, as my primary version control system going forward.
What this gives me that I didn't have before:
- Full control over access and tokens — I decide exactly what scopes exist, and there's no platform-wide account to compromise that spans every project I have.
- Backups on my terms — automated, offline, and stored separately from the live server, so a server compromise can't wipe both the working copy and the backup in the same stroke.
- No single account compromise can cascade across every organization I'm part of — because there's no single external account tying it all together.
- Full audit visibility — I control the logs, the retention, and the security policies, rather than depending on a third party's incident response timeline.
GitHub (or any hosted platform) still has its place — visibility, collaboration, community, integrations — and I may still use it for select public projects. But the core, critical codebase now lives somewhere I control end-to-end, with backups I own and access policies I set.
The Real Lesson
This wasn't really a GitHub problem. GitHub's platform worked exactly as designed — a token with certain permissions was used to do exactly what those permissions allowed. The failure was upstream: a token that had too much power, sitting somewhere it shouldn't have been, for who knows how long before someone found it.
If there's one thing I'd want another developer or founder to take from this, it's not "don't use GitHub." It's: know exactly what every credential in your life can do, minimize that power wherever possible, and never assume your only copy of anything critical is safe just because it's on a big, trusted platform.
