someone outside our GitHub org deleted one of our private repos.
no membership or invite or role. nothing in our org or enterprise audit logs gave them access. just one repo.destroy from the gh CLI.
and it's not in deleted repositories, so no restore.
@github how is this possible, what sorcery is this?
Oct 27, 2026 · 6:39 PM UTC
finally the mystery is solved
xitter-newx.xyz-mikolabs.workers.dev/ayushagarwal/status/21…
ok update on the deleted repo thing, since it kind of blew up
first, some context on why i posted it like that. there have been so many security incidents lately that my brain is basically stuck in alert mode. so when i saw a stranger in our audit log deleting a private repo, i assumed the worst.
we figured out what happened. nobody hacked us, and it wasn't a github bug.
that repo was a private fork of a repo owned by @StainlessAPI, the company that generated our SDKs. our entire SDK pipeline ran on it.
Stainless got acquired by @AnthropicAI back in may. and on october 27, with zero heads-up to us, someone there deleted their copy of the repo.
turns out when you delete a private repo on github, every private fork of it gets deleted too. same request, under two seconds. and our audit log shows the person who deleted *their* repo as the one who deleted *ours*. that's why it looked like a random outsider walked into our org and nuked something.
no email. no "hey, we're cleaning these up, grab a copy." just gone, along with the production repo behind every one of our SDKs.
github support walked us through all of it within a day, which, genuinely, thank you.
one ask though @github: put this in the audit log. right now the event for our repo just says "repo.destroy" by an outside user. if it said "deleted because upstream fork parent X was deleted", we'd have understood it in two minutes instead of spending a night thinking we'd been breached.
we had a local clone, so we pushed it back up as a standalone repo and the SDKs are running again.
if you were a Stainless customer and you've got anything living as a private fork of one of their repos, go detach it today. it takes ten minutes. their delete is your delete.
Holy shit, how is this possible...it might be a stolen token but still this is very shocking 😳
@madebygps @cassidoo
@martinwoodward @acolombiadev
guys can you pls make this issue reach the GitHub team so they can solve it 👍
3
2,181
GitHub has archives of everything... In fact when you delete something intentionally (like a checked-in private key) and you think it's gone forever by forced push, it's still there, hanging out in the GitHub cache, which they have to manually purge via GC (and they never respond to customer service requests even for important things like running a GC to purge the cache). So probably your data is still there somewhere, but good luck getting GitHub's attention to get it back.
259
this usually points to one of 3 architectural failure modes in GitHub's authorization and soft-delete model:
1. fine-grained PAT or GitHub App token delegation bypass:
if a former employee or integration created a Fine-Grained Personal Access Token with `administration:write` or `delete_repo` scope, GitHub's audit log often attributes the API call to the token's bearer identity rather than an active org member event. if that token was leaked or used via `gh auth login --with-token`, it executes with full deletion authority even if the creator's org membership was revoked.
2. lineage metadata & cross-namespace fork cascades:
if the private repo was originally forked from or transferred between personal and org namespaces, internal upstream parentage metadata can persist in GitHub's backend. an API deletion on a lingering upstream stub or detached fork pointer can trigger a cascading hard purge that bypasses the org's web UI "Deleted Repositories" soft-delete graveyard.
3. the hard-delete API boundary:
while UI deletions almost always land in the 90-day soft-delete restoration window, certain direct REST/GraphQL deletion endpoints (or deletions of empty/recently transferred repos) bypass the soft-delete queue entirely, executing an unrecoverable hard wipe on the underlying git bare repo.
relying on a SaaS git platform's internal trash bin is not a backup strategy: critical repos need automated out-of-band `git bundle --all` mirrors written to append-only, object-locked cloud storage (S3 with Glacier Vault Lock).
3
1,413
