"Rotate your keys" is the standard advice after an incident. It assumes you know what all of your keys are. Usually you don't.
Zeabur's incident report is unusually candid about this. After an incident in August they rotated keys, and the August report said "all internal admin keys have been disabled or rotated." Their October report calls that statement incomplete, and says why: "The August rotation did not cover the cluster admin tokens and AWS keys stored in plaintext in the configuration repository..." Those admin tokens were created in January 2024 with no expiry, and in January 2026 one was written in plaintext to a private configuration repository. On October 14 the attacker used a Zeabur AWS key and then a cluster admin token. Among the exposed data: 3,218,965 service environment variable records.
The secrets you don't know about are the ones that stay valid.
Deleted Is Not Gone
The second place forgotten secrets live is Git history. GhostAction, a campaign first seen in September 2025, is back. It pushes a fake "security audit" workflow into repos, most likely using leaked maintainer tokens. Among other things it scans "the entire git history" to find, per StepSecurity as quoted by The Hacker News, "credentials that may have inadvertently committed to the repository and subsequently deleted." Socket counts more than 500 GitHub accounts pushing the workflow to tens of thousands of repositories since October 7.
So a key that someone committed, noticed, and removed in a follow-up commit is still in the repo. It's in every clone and every fork, and the attacker's script looks for it. You can see this with nothing but Git:
# every commit reachable from any ref that added or removed something shaped like an AWS access key ID
-G matches the regex against each commit's diff, so the commit that removed the key shows up next to the one that added it. A tool like gitleaks does the same across a large set of secret patterns, and it reads history by running git log -p under the hood.
When a secret has been in a commit, deleting it is not remediation -- revoking it is. Rewriting history is cleanup; it doesn't make the key invalid.
Build the List Before You Need It
I wrote about secret sprawl in 2021, in the Teller post: "Often secret sprawl happens without individuals realizing it, because it’s naturally hard to see the bigger picture..." That's still the problem. You can't fix sprawl in the hours after an incident, because that's when you're working from memory.
What works is boring, and it happens before the incident:
- Keep secrets in a store, not in files. Config repos,
.envfiles and CI variables get copied around, and every copy is one more place to search. A reference to a vault entry isn't the secret, and the vault knows every secret it holds. - Give everything an expiry. A token with no end date stays valid until someone remembers it, and a token that expires cleans up after the rotations you miss.
- Scan history, not just HEAD. Run the scan on full history once, and revoke whatever it finds, including keys that were removed years ago.
- Make rotation a script. If rotating everything takes a script, you can run it. If it takes a meeting, that's where things get missed.
The cost is real: a vault is one more service to run, expiring tokens break things at inconvenient times, and the first full-history scan of a big monorepo can take a while. That's still cheaper than learning about your inventory from an attacker.
Credit where it's due: Zeabur published a detailed timeline that includes what went wrong, and that's more useful to everyone else than a vague statement. Read it, then go find the tokens you forgot about.