Leaked Cloud-Credentials Radar
Cloud credentials — AWS, GCP, Azure, GitHub, Slack, Stripe keys — accidentally committed to public GitHub repositories, found, when the radar runs, by sampling the public push stream every 10 minutes. 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
- Google220
- Other / generic149
- database108
- telegram40
- AWS16
- discord4
- GitHub3
- cloudflare3
- groq3
- Azure2
- Stripe2
- openai2
- openrouter2
- Slack2
- docker1
By secret type
- Google API key220
- Database connection string with embedded credentials108
- JSON Web Token94
- Private key (PEM)55
- Telegram bot token40
- AWS access key ID15
- Discord webhook URL4
- Groq API key3
- Cloudflare API token3
- GitHub token3
- OpenAI project key2
- Azure storage account key2
- Slack token2
- Stripe secret key2
- OpenRouter API 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?
When the radar runs, every 10 minutes we 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 count of cloud credentials — AWS, GCP, Azure, GitHub, Slack and Stripe keys — committed to public GitHub repositories, found, when the radar runs, by sampling the public push event stream every 10 minutes. 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 (+https://echelongraph.io/surface-scanner; opt-out https://echelongraph.io/responsible-disclosure; [email protected]) or, from our radar prober, EchelonGraphBot/1.0 (+https://echelongraph.io/bot), and their HTTP requests to the hosts they check also carry a From: [email protected] header. Some checks are a single identified GET; others send several requests to one host. Confirming an MCP endpoint sends a POST asking the server which protocol versions it supports, a second POST with the older handshake only if the first is refused without a 2026-07-28 error, a DELETE to close any session a POST opened and, if a POST is refused with HTTP 401 or 403, up to two GETs of the server's OAuth protected-resource metadata on the same host; where neither POST finds an MCP endpoint, the older SSE transport's stream is requested with GET, only its first event is read, and the connection is closed. A server that answers the first POST with a DiscoverResult, or with an error the 2026-07-28 revision defines, opens no session and is sent no further POST, so it is not written to; if the POST is refused with HTTP 401 or 403, the metadata GETs above still follow. Confirming an exposed datastore needs a protocol-level exchange, and on Redis our client names itself so the connection is identifiable in your own CLIENT LIST. We never log in, submit credentials or exploit what we find. Who we are, exactly what each check sends, and how to opt out → A radar's HTTP requests to the host it checks also carry a signed receipt you can validate at /verify-scan.