Exposed Data-Stores Radar
When it runs, every 12 hours we search public internet-scan data for databases — MongoDB, Elasticsearch, Redis, CouchDB, Memcached, Kibana and more — that are open with no password. No exploit is needed: anyone who finds one can read, copy, or delete everything in it. We find candidates in public internet-scan banners, then connect once ourselves to confirm it — the smallest handshake that asks the server nothing but “do you answer without a password?”. Every probe is signed, so you can prove in your own logs that it was us.
The candidates counted here come from Shodan data, or from LeakIX data when Shodan query credits run low. Shodan data is owned by Shodan, which holds its copyright (© Shodan). EchelonGraph claims no ownership of it or copyright in it.
PII/PCI likelihood is inferred from schema only — exposed index/table/field names such as ssn, passport_number, or cardholder. We never read, store, or display the underlying records.
Why this is a risk
An open, unauthenticated database is an open door — not a vulnerability that needs an exploit, just data sitting exposed:
- • Anyone can read, copy, or delete the data — customers, criminals, or automated bots.
- • Ransomware crews scan for exactly this: they connect, exfiltrate, wipe the data, and leave a ransom note. The “Meow” attacks destroyed thousands of open databases this way.
- • It is one of the most common root causes of mass data breaches — no zero-day required.
By engine — and what's at stake
By country
- United States774
- China459
- Germany389
- France160
- United Kingdom149
- Singapore124
- Netherlands105
- India98
- Brazil97
- Indonesia85
Are you exposed?
Check whether your infrastructure has an open data store or other exposure — a free external scan of your internet-facing surface, no signup.
Check your exposure →How it works
How do you know it's actually unauthenticated?
Because we check, rather than assume. A public banner is a candidate, not proof — it can be stale (the IP was re-purposed and now fronts a login page) or mis-parsed, and trusting it produced false “open MongoDB” reports. So we open one connection ourselves and send the smallest command the server only answers when no password is enforced — for the stores we reach over HTTP we try http and https in turn, so you may see two attempts rather than one: listDatabases on MongoDB, INFO on Redis, stats on Memcached, a protocol handshake on Cassandra. A locked Redis replies NOAUTH; a locked Mongo demands SASL. The check is fail-closed — any auth challenge, timeout, or reply we cannot parse cleanly means not open, and it is never reported.
So you DO connect. What exactly do you touch?
Yes — and we would rather say so plainly than hide behind the word “passive”. What we run is a metadata handshake and nothing else. We read database and schema names, one Kibana index-pattern definition, server version and server statistics. We do not read keys, documents, rows, or cached values; we never authenticate, never submit credentials, never read your records, never delete anything, and never exploit anything. The one thing we do send beyond that is our name, so the check is identifiable. On Redis the connection sends exactly three commands: HELLO 2 and CLIENT SETNAME carry our client name, then INFO asks for server statistics. So our connection appears in your own CLIENT LIST rather than as an anonymous probe. A Redis older than 6.0 rejects HELLO as an unknown command; a password-protected one refuses the handshake with NOAUTH and never receives INFO. If a store is password-protected, our probe fails at the door — which is the entire point of running it.
How can I prove a connection in my logs was really you?
Every probe carries our identity in whatever field the protocol gives a client — MongoDB driver.version, the Redis client name, Cassandra DRIVER_VERSION — together with a signed, single-use receipt. Paste that value into /verify-scan and we echo back the signed target, port and timestamp for you to match against your log line. An attacker can put our name in a packet; they cannot forge the signature. One exception, stated because it matters: Memcached’s text protocol has no client-identity field at all, and embedding a receipt there would require a write — which we do not do. For that one engine the source IP and this page are the only identification we can offer.
Why don't you list the IPs?
Publishing open-database IPs would be a target list for attackers. We keep host details private for responsible disclosure to affected organisations and publish only aggregate counts. (Use the scanner above to check your own exposure.)
Frequently asked questions
What is the Exposed Databases Radar?
A count of databases — MongoDB, Elasticsearch, Redis, CouchDB, Memcached, Kibana and more — reachable on the public internet with no authentication. When the radar runs, EchelonGraph searches public internet-scan banners for candidates every 12 hours (Shodan, or LeakIX when Shodan query credits run low), then confirms each one with its own minimal handshake before counting it, and publishes only aggregate, host-redacted counts.
Why is an unauthenticated database dangerous?
Anyone on the internet can read, copy, ransom or wipe the data — no exploit required. Open databases are a leading cause of data breaches and automated wipe-for-ransom attacks; ransomware crews and scrapers actively hunt for them.
How does EchelonGraph detect open databases?
In two steps. Public internet-scan banners identify candidate hosts. Then EchelonGraph connects once itself and sends the smallest metadata command the server only answers when no password is enforced — on some engines that is two commands, and for the stores we reach over HTTP we try http and https in turn — listDatabases on MongoDB, INFO on Redis, stats on Memcached, a handshake on Cassandra — because a banner alone can be stale or mis-parsed and produces false reports. The probe is detect-only: it reads database names, one Kibana index-pattern definition, server version and server statistics, and never reads keys, documents, rows or cached values, and never authenticates. It is not a pure read, and we would rather say so than have you find it in your own logs: identifying ourselves sets a client name on Redis that appears in your CLIENT LIST, where the connection sends exactly three commands (HELLO 2 and CLIENT SETNAME carry our client name, then INFO asks for server statistics; a password-protected Redis refuses the handshake and never receives INFO), and on ClickHouse the check runs a trivial SELECT your query log will record. It is fail-closed, so any auth challenge or unparseable reply counts as not open. A probe carries a signed receipt you can verify at /verify-scan on every engine but Memcached, whose protocol has no field to put one in. Results are aggregate and host-redacted.
How do I secure an exposed database?
Require authentication, bind the service to a private network or VPC instead of 0.0.0.0, place it behind a firewall or security group, and rotate any credentials that may have been exposed. A database should never be reachable directly from the public internet.
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.