Leaked Cloud-Credentials Radar
Cloud credentials — AWS, GCP, Azure, GitHub, Slack, Stripe keys — accidentally committed to public GitHub repositories, found by continuously scanning the public push stream. Automated bots scrape new commits for keys within seconds — this is an early-warning signal to rotate before they’re abused.
Why this is a risk
A live cloud key in a public repo is one of the fastest paths to compromise — no exploit required:
- • Bots harvest new public commits in seconds — leaked keys are often used minutes after the push.
- • Direct account access — data exfiltration, resource hijacking (crypto-mining racks up huge bills), and lateral movement.
- • Git history is immutable — deleting the file later doesn’t help; the secret must be rotated.
By cloud / provider
- Other / generic7
- Google3
By secret type
- JSON Web Token6
- Google API key3
- Private key (PEM)1
Are your secrets exposed?
EchelonGraph scans your own code, IaC, and cloud surface for hard-coded and exposed secrets. Run a free check of your internet-facing exposure to get started.
Check your exposure →How it works
How do you detect these?
We continuously sample GitHub’s public push stream and scan the committed diffs with a curated set of high-confidence patterns (provider-specific key formats + entropy checks), suppressing placeholders and example values. Every match is redacted and fingerprinted before storage.
Do you verify the keys are live?
No — and deliberately. Authenticating with someone else’s key would be unauthorized access. A match means a credential-shaped string in a public commit, not a confirmed live key. The repository owner validates and rotates (they’re authorized); the evidence is the public commit itself.
Why don't you show the repos or secrets?
Publishing the repo, commit, or even a partial secret would point attackers straight at it. We publish only aggregate counts; host/repo detail is kept private for responsible disclosure to the owner.