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 / generic491
- Google384
- AWS84
- telegram80
- database34
- discord20
- GitHub14
- Google Cloud5
- openai4
- Slack3
- groq2
- huggingface2
- algolia2
- supabase1
- sendgrid1
By secret type
- JSON Web Token426
- Google API key384
- AWS access key ID83
- Telegram bot token80
- Private key (PEM)65
- Database connection string with embedded credentials33
- Discord webhook URL19
- GitHub token11
- GCP service-account private key (JSON)5
- OpenAI project key4
- Slack token3
- GitHub fine-grained PAT3
- Hugging Face token2
- Groq API key2
- Algolia admin key2
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.
Frequently asked questions
What is the Leaked Cloud-Credentials Radar?
A live count of cloud credentials — AWS, GCP, Azure, GitHub, Slack and Stripe keys — committed to public GitHub repositories, found by scanning the public push event stream. EchelonGraph publishes only aggregate counts, with the repository and secret redacted.
How do credentials end up in public GitHub repos?
A developer accidentally commits a .env file, config, or hardcoded key and pushes it to a public repository. Even if it is deleted seconds later, the secret remains in the git history — and automated bots have usually already captured it.
How fast are leaked keys abused?
Often within seconds to minutes. Bots watch the public GitHub event stream and test new keys the instant they appear — spinning up crypto-mining, draining cloud accounts, or exfiltrating data before a human even notices the commit.
I committed a secret to a public repo — what now?
Rotate or revoke the credential immediately and assume it is already compromised — deleting the commit is not enough because it stays in history. Then purge it from history, review for any abuse, and enable push-protection or secret-scanning to prevent a repeat.
EchelonGraph-<Radar>/1.0 (+echelongraph.io/responsible-disclosure; support@echelongraph.io) and a From: support@echelongraph.io header. It is a single, passive, read-only check — we never log in, exploit, write, or read your data. Who we are, how we confirm exposures read-only, and how to opt out → Genuine requests also carry a signed receipt you can validate at /verify-scan.