The Minutes-Long Window: How Attackers Exploit Leaked Keys
Security researchers who plant decoy keys in public repositories consistently report them being found and tried within minutes, sometimes faster. That isn't people watching GitHub; it's automated infrastructure. Here is how it works.
An illustrative timeline
The automation pipeline behind it
The speed of the exploit is a direct consequence of automation. The infrastructure running this pipeline is not sophisticated - it is simply always-on and highly parallel.
A typical credential-harvesting operation consists of:
- 1.Event stream consumers - persistent connections to the GitHub Events API and/or the public Firehose. These run 24/7 on cheap VPS instances in multiple regions for redundancy.
- 2.Pattern matching workers - apply regex patterns for known secret formats (OpenAI, AWS, Stripe, GitHub, etc.) to commit diffs in real time. Parallel processing across hundreds of worker threads.
- 3.Validation bots - submit candidate secrets to low-cost trial API requests to verify they are active. Invalid keys are discarded immediately.
- 4.Monetization layer - valid keys are either exploited directly (LLM inference, cloud resource spin-up) or resold.
How attackers monitor GitHub
GitHub exposes a public Events API at api.github.com/events that lists recent public activity across all repositories, and anyone can poll it.
Each PushEvent in the feed contains the commit SHA, repository, and author. The full diff is retrievable with one additional API call per commit. A single consumer can process the public feed in near-real-time with minimal infrastructure.
Private repositories are not exposed in this feed. The exposure comes from public open-source projects, public forks, repositories accidentally made public, and public CI build logs.
Why speed is the whole game
Every step on the attacker's side is automated and runs continuously. Every step on yours involves a person: seeing the alert, finding the key, revoking it, and shipping a replacement. Even a fast human response is measured in minutes, and the pipeline above can finish inside that.
Key insight: Rotate immediately, every time. But plan as if a leaked key will be tried before you can rotate it.
Why rotation after detection isn't enough
The instinctive response to “what do I do if I leak a key?” is “rotate it immediately.” This is correct but insufficient as a primary security strategy.
Rotation-based defence assumes you will detect the leak before exploitation. With automated scraping, that assumption often doesn't hold. Detection depends on GitHub's secret scanning or your own monitoring, both of which fire after the push, after the event feed is consumed, and after the validation bot has already confirmed the key is active.
Pre-commit scanning (Gitleaks, detect-secrets) is the correct tool for catching mistakes before they push. But pre-commit hooks can be bypassed, skipped on new machines, or simply not installed. They are a useful control, not a sufficient one.
Changing what a leak is worth
Detection and response can't reliably win this race. What changes the outcome is making sure the string in your code isn't the real credential.
A host-bound sanitized token only works from the origins you allowed. A scraper that tests it from its own infrastructure gets a 403 from the proxy, so the validation step fails. A determined attacker who forges an allowed origin from a server is the case host-binding alone doesn't cover; rate limits, cost caps and anomaly alerts are the backstop.
Meanwhile, your breach detection system fires a notification: an unauthorized origin attempted to use your token, with the attacker's IP and timestamp. Rotate it anyway; it costs nothing.
Make the next leak cheaper
KeyVault Edge swaps your real key for a host-bound token, so what leaks is refused from origins you haven't allowed.
Get started