VULNpocalypse
InformationalSupply chainMonitoring

Aikido reports deleting a leaked key from a repo does not protect you

Aikido says deleting a file, rewriting history or deleting a repo leaves leaked keys reachable; rotate the credential first.

Published
Exploitation
Not confirmed independently. Aikido reports that attackers used a leaked LiteLLM key, citing LiteLLM’s post-mortem, which was not reviewed here.

What happened

Aikido, a security vendor, says in a blog post that deleting a leaked key from a repository does not protect you, and that the only real fix is to rotate the credential Aikido. This is one vendor’s guidance, not an official advisory, and no independent outlet is carrying it. Aikido also sells secrets-detection products and sponsors the Betterleaks scanner it recommends.

Aikido reports that LiteLLM developers accidentally committed an administrative key to a public GitHub repository in May (the year is not stated in the source). Aikido says attackers used that credential to compromise LiteLLM’s infrastructure months later, and cites LiteLLM’s post-mortem for the timeline. We did not review the post-mortem, so those details are not confirmed here. Per Aikido, the leak was caught within about three hours, and a follow-up commit deleted the file. Aikido quotes the post-mortem as saying the original commit stayed in the public history until October 22, when LiteLLM rewrote git history. Aikido adds that the commit is still visible today and that the key has since been rotated. It also says the key was live for over four months before an attacker used it to pull a GitHub token and ship a malicious release Aikido.

Aikido describes three experiments, each of which it says fails to remove the exposure:

  • Delete the file in a new commit. Aikido says secret scanners read git history, including deleted files, and that Betterleaks detects the secret.
  • Rewrite history and force push. Aikido says GitHub still serves the “deleted” commit to anyone who has its SHA-1 hash, and that short hashes of as few as 4 characters resolve in the GitHub UI.
  • Delete the repository. Aikido says you cannot know who cloned it, and that if anyone forked it, GitHub keeps the commit until the last fork is deleted.

Aikido also says researchers, platforms and threat actors constantly scan for secrets, and advises assuming that a public secret has been seen. That is Aikido’s claim, and the source gives no figures for it here.

Am I affected?

You are potentially affected if you ever pushed a credential (API key, token, password) to a public repository, even briefly, and did not revoke it. Aikido’s position is that removing the secret from the latest commit, from history, or by deleting the repo does not change this Aikido.

Not confirmed: whether any specific key was abused, how widespread such leaks are, and the details of the LiteLLM incident beyond what Aikido relays.

What to do now

  1. Revoke the leaked credential with the service that issued it, issue a new one, and update every place the old one was used. This is Aikido’s central recommendation.
  2. After rotating, check for signs of earlier misuse, per Aikido: the key or token’s own usage and access logs, recent commits to main and any protected branches, and CI and workflow config changes and recent pipeline runs.
  3. If you cannot rule out misuse, treat it as an incident, as Aikido advises.
  4. Optionally, scan repositories (including full git history) and developer machines for other leaked secrets. Aikido names its own Secrets Detection and Device Protection products and the free, MIT-licensed Betterleaks scanner. Whichever tool you use, rotate whatever it finds.

Sources