LiteLLM Admin API Key Leaked on GitHub for Months, Exploited to Push Malicious Release
LiteLLM developers accidentally committed an administrative API key to a public GitHub repository in May 2026. Although the leak was detected within three hours, the team's initial remediation only deleted the offending file and later (October 22) rewrote git history to remove the commit — neither action actually removed the secret from public visibility. Attackers eventually used the still-valid credential months later to compromise LiteLLM infrastructure, pull a GitHub token, and ship a malicious release. The article, published by Aikido, uses this incident to demonstrate that deleting files, rewriting git history, or even deleting a repository does not protect against a leaked secret, since GitHub continues to serve commits by SHA-1 hash and forks retain copies indefinitely.
Detalhes técnicos
The post walks through three common but ineffective remediation attempts: (1) deleting the file containing the secret, which secret scanners like Betterleaks can still detect in git history; (2) rewriting git history via force-push, which leaves commits accessible on GitHub via their SHA-1 hash even though they are unreachable from any branch; and (3) deleting the entire repository, which does not remove copies held by forks or clones made before deletion. In the LiteLLM case, the leaked administrative key remained live for over four months before an attacker used it to retrieve a GitHub token and publish a malicious release, demonstrating real-world exploitation of a long-lived leaked credential.
Remediação
The only effective fix for a leaked secret is immediate credential rotation/revocation with the issuing service, followed by updating the credential everywhere it is used. After rotation, defenders should review the key's own usage/access logs, recent commits to main and protected branches, and CI/CD workflow changes to detect prior misuse, treating any ambiguous findings as a full incident. The article recommends tools such as Aikido Secrets Detection, Betterleaks (open-source, MIT licensed), and Aikido Device Protection to proactively detect leaked credentials in repositories, git history, IDEs, CI/CD pipelines, and developer machines before and after exposure.
Linha do tempo
-
LiteLLM Admin API Key Leaked on GitHub for Months, Exploited to Push Malicious Release
ler a análise desta fonte ocultar
LiteLLM developers accidentally committed an administrative API key to a public GitHub repository in May 2026. Although the leak was detected within three hours, the team's initial remediation only deleted the offending file and later (October 22) rewrote git history to remove the commit — neither action actually removed the secret from public visibility. Attackers eventually used the still-valid credential months later to compromise LiteLLM infrastructure, pull a GitHub token, and ship a malicious release. The article, published by Aikido, uses this incident to demonstrate that deleting files, rewriting git history, or even deleting a repository does not protect against a leaked secret, since GitHub continues to serve commits by SHA-1 hash and forks retain copies indefinitely.
Technical Details
The post walks through three common but ineffective remediation attempts: (1) deleting the file containing the secret, which secret scanners like Betterleaks can still detect in git history; (2) rewriting git history via force-push, which leaves commits accessible on GitHub via their SHA-1 hash even though they are unreachable from any branch; and (3) deleting the entire repository, which does not remove copies held by forks or clones made before deletion. In the LiteLLM case, the leaked administrative key remained live for over four months before an attacker used it to retrieve a GitHub token and publish a malicious release, demonstrating real-world exploitation of a long-lived leaked credential.
Remediation
The only effective fix for a leaked secret is immediate credential rotation/revocation with the issuing service, followed by updating the credential everywhere it is used. After rotation, defenders should review the key's own usage/access logs, recent commits to main and protected branches, and CI/CD workflow changes to detect prior misuse, treating any ambiguous findings as a full incident. The article recommends tools such as Aikido Secrets Detection, Betterleaks (open-source, MIT licensed), and Aikido Device Protection to proactively detect leaked credentials in repositories, git history, IDEs, CI/CD pipelines, and developer machines before and after exposure.