Elasticsearch exposed to the internet

For most of the last decade, Elasticsearch was the single most common source of mass data breaches. Not because it was uniquely insecure, but because of a combination that turned out to be catastrophic at scale: it shipped with no authentication, it was easy to bind to a routable address, and it held precisely the data that makes headlines — aggregated logs, user records, entire application datasets.

The numbers were staggering. Individual exposed clusters leaked hundreds of millions of records at a time; in aggregate, billions. None of it required an exploit. Scanners found port 9200, made a GET request, and got everything.

Version 8.0 (2022) closed the default — security is now on out of the box. But three populations remain exposed: 7.x clusters (security off by default), modern clusters where someone turned security off to fix a connection error, and clusters bound to 0.0.0.0 behind a misconfigured firewall.

What an open cluster gives away

With security off, a single unauthenticated request does it:

curl http://your.es:9200/_cat/indices?v          # every index, and its size
curl http://your.es:9200/_search?size=10000      # the documents
curl -X DELETE http://your.es:9200/_all           # all of it, gone

No credential, no exploit, no privilege escalation. Read everything, or delete everything, in one line. The _cat/indices endpoint is a table of contents for the breach.

And like the MongoDB wave, open Elasticsearch attracted ransom crews: databases wiped and replaced with a single index demanding payment. As with MongoDB, paying is pointless — much of the time the data was never copied, only deleted, and there is nothing to return.

It used to be worse than a data breach

Worth knowing, because it explains why some old advice is so insistent about scripting.

Before the modern sandboxed scripting engine, Elasticsearch executed dynamic scripts in languages (MVEL, then Groovy) that could reach out of the sandbox. CVE-2014-3120 and CVE-2015-1427 turned an open cluster into remote code execution — a search query that ran shell commands on the host. Those were headline RCEs in their day.

Modern Elasticsearch uses Painless, a purpose-built sandboxed language, and the dangerous dynamic-scripting engines are gone. So a current open cluster is usually a total data compromise rather than host code execution — which is the same shape as MongoDB: the data is the loss, not the machine. That’s still catastrophic; it’s just not a shell.

Do not let that reassure you into leaving scripting-era versions running. A 7.x or older cluster that’s both open and outdated may still be exposed to the historic RCE paths, on top of everything else unpatched.

The shortest path from exposed to closed

1. Enable security — the wall that should have been there. On 8.x/9.x it’s a setting that was flipped off; put it back.
2. Bind to a private interface — off 0.0.0.0, onto the one interface your clients use.
3. Firewall 9200 and 9300 — an unreachable cluster needs no login, and 9300 should never be reachable from outside your node network.
4. Give apps scoped credentials — so a leak later isn’t the whole cluster.

Steps 1 and 2 are settings plus a restart. Do them before you finish reading.

Verify it worked

Is it open? From another host — not the cluster:

curl -s --connect-timeout 5 http://your.es:9200/_cat/indices -o /dev/null -w '%{http_code}\n'

200 with a plaintext HTTP request means security is off and the cluster is readable right now. Firewall the port before doing anything else. A timeout is what you want; 401 means it’s secured.

Were you hit? Check for the ransom pattern and for missing data:

curl -sk -u elastic https://localhost:9200/_cat/indices?v

Look for indices you didn’t create — names like read_me, recovery, warning, or a single tiny index where a large one used to be. Then check the size of what should be large:

curl -sk -u elastic https://localhost:9200/_cat/indices?v\&s=store.size

An index that’s suddenly empty or gone is the signature.

Check for signs of scripting-era exploitation on old clusters:

sudo journalctl -u elasticsearch | grep -iE 'script|groovy|painless.*exception' | tail
sudo cat /var/lib/elasticsearch/.ssh/authorized_keys 2>/dev/null

And review who has been authenticating, if you have any log:

sudo grep -iE 'authentication|_authenticate' /var/log/elasticsearch/*.log 2>/dev/null | tail

Before you apply this

If it was reachable and unauthenticated, assume the data is disclosed — whether or not it was deleted. You cannot distinguish “read then wiped” from “wiped”, and _search over an open cluster is trivial and quiet.

Response:

1. Firewall the port first. Don’t restart Elasticsearch — a restart clears the in-memory task list and any transient evidence of what’s connected.
2. Enumerate the damage with _cat/indices and note what’s missing or added before changing anything.
3. Restore from a snapshot taken before the earliest sign of access. Treat the entire dataset as leaked regardless of what you find.
4. Rotate every credential the data contained — application user hashes, tokens, API keys, anything indexed. Elasticsearch often holds logs, which means it may contain other systems’ secrets that were logged; rotate those too.
5. On an old, scripting-era cluster that was open, also check the host for persistence (SSH keys, cron, unexpected processes) — those versions could run code, so the host may be compromised, not just the data.

Do not pay a ransom. As with MongoDB, the data is usually gone rather than held, and payment funds the next sweep.

The durable fix is the checklist, in order: security on, bound tight, firewalled, and apps scoped. The clusters that had those in the breach years were the ones reading about it rather than in it — and since 8.0, that’s the default you have to work to undo.

Related

• Hardening Elasticsearch — the full checklist.
• Enable security — the control that makes this impossible.