Exposed Data-Stores Radar
We continuously scan the public internet 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.
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 States1,553
- Germany947
- China853
- France419
- United Kingdom325
- Singapore273
- Indonesia247
- India226
- Brazil217
- Netherlands212
Are you exposed?
Check whether your infrastructure has an open data store or other exposure — a free read-only scan of your own 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 is a metadata command so the check is identifiable: on Redis it names our client, so our connection appears in your own CLIENT LIST rather than as an anonymous probe. 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 live count of databases — MongoDB, Elasticsearch, Redis, CouchDB, Memcached, Kibana and more — reachable on the public internet with no authentication. EchelonGraph finds candidates in public internet-scan banners, 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, 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. Every probe carries a signed receipt you can verify at /verify-scan. 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 (+echelongraph.io/responsible-disclosure; [email protected]) and a From: [email protected] header. It is a single, minimal check — we never log in, exploit, or read your data. Confirming an MCP endpoint or an exposed datastore needs a protocol-level exchange rather than a plain GET; on Redis our client names itself so the connection is identifiable in your own CLIENT LIST. Who we are, exactly what each check sends, and how to opt out → Genuine requests also carry a signed receipt you can validate at /verify-scan.