- Aikido Security argues that deleting a leaked secret, rewriting git history or deleting a repository leaves it reachable. Only revoking and replacing the credential protects the account.
- Aikido says LiteLLM's administrative key, committed in May, was still usable more than four months later, when an attacker used it. The excerpt does not say why.
- After rotating a key, check its usage logs, recent commits and CI changes. If misuse cannot be ruled out, treat it as an incident.
Cleaning up feels like fixing
When a developer leaks a key, the first instinct is to tidy up. Delete the file. Rewrite the history. Remove the repository. Each step feels like closing a door.
Aikido Security, a security vendor, argues that none of them closes anything. Its lesson is simple. A leaked secret is a copied key, and the only repair is to change the lock.
What happened at LiteLLM
Aikido's example is LiteLLM. In May, the company's developers accidentally pushed an administrative key into a public GitHub repository. Aikido says attackers used that credential months later to compromise LiteLLM's infrastructure. Aikido draws this from LiteLLM's own post-mortem.
The first response looked sensible. The post-mortem says a follow-up commit removed the file about three hours later. The same record says the team marked the keys for revocation. But the leaking commit stayed publicly visible until a history rewrite on October 22.
Here the record leaves a gap. The post-mortem excerpt Aikido quotes does not explain why the key stayed usable. It does not say whether the key was rotated, or whether the attacker used a different credential.
Aikido reads the episode as cleanup standing in for rotation. That is Aikido's inference. It puts the gap between the leak and the attacker's use of the key at more than four months. With the key, the attacker obtained a GitHub token and shipped a malicious release. Aikido says the leaking commit is still visible, though the key has now been replaced.
Why each cleanup step fails
Git stores every change as a numbered snapshot called a commit. Deleting a file adds a new snapshot. The old one, secret included, stays in the record. Aikido notes that secret scanners read git history and check deleted files.
Rewriting history is the next step. A developer rewrites the record and force-pushes it, so the old commits no longer belong to any branch. Aikido tested this. It found GitHub still serves those commits to anyone who has the commit's identifier.
That identifier is a 40-character hash, too long to guess. But GitHub's interface accepts a shortened form, which Aikido says can be as short as four characters. That makes the commits easier to find.
Deleting the whole repository does not work either. Aikido says you cannot see who cloned it. If anyone forked it, GitHub keeps the "deleted" commit until the last fork is deleted.
One caveat applies. Aikido calls its experiments a simple demo. It reset a test repository to its first commit and notes that history can be rewritten in other ways.
The gap is where the damage happens
Aikido says researchers, cloud platforms and threat actors scan for secrets constantly. Its advice is to assume someone has seen a key the moment it goes public.
The human cost sits in the gap between leak and discovery. A team fixes the visible problem and moves on. Months later, someone on call may face a compromised build pipeline. At LiteLLM, according to Aikido, that meant a malicious release.
The lesson here is that git history is a record, not an undo button. Hiding a leaked key from view does not change who already holds a copy.
What to do and ask
Aikido says rotation stops future misuse but does nothing about misuse that has already happened. Its checklist for after rotation has three parts. Read the old key's own usage and access logs. Check what has been committed lately to the main branch and to any protected branches. Look at changes to CI and workflow settings, plus recent pipeline runs. If you cannot rule out misuse, Aikido says, treat it as an incident.
Leaders can put four questions to their teams:
First, who can revoke a credential at once, without waiting for a clean-up plan? Second, can the team reach the issuing service quickly to replace the key? Third, do scans cover git history, or only current code? Aikido says its tool checks current code by default and offers full history checks as an option. Fourth, is there a routine for reviewing logs and pipelines after each rotation?
Aikido sells secrets detection and sponsors Betterleaks, a free open-source scanner under the MIT licence. Weigh its advice with that in mind. The rotation argument does not depend on any product.
A leaked key cannot be taken back. It can only be made worthless.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Aikido Security.
