My Elasticsearch index got exposed without authentication. What should I do?
Elasticsearch clusters left open on port 9200 expose everything you’ve indexed — application logs, user records, and whatever you search over — to anyone with a browser. Open clusters are routinely scraped and hit with ransom sweeps that delete indices and leave a note. Here’s how to lock it down and assess the damage.
First: don’t panic — close 9200, then see what was indexed.
A single GET request can dump an entire index, so treat all indexed data as already read. Firewall the port now; recovering deleted indices depends on snapshots, not on any ransom demand.
// the 60-second version
- Firewall ports 9200/9300 and bind Elasticsearch to localhost/private.
- Enable security (auth + TLS) and set passwords for built-in users.
- Check
_cat/indicesfor deleted data or a ransom-note index. - Treat all indexed data (logs, PII) as exfiltrated; restore from snapshots.
01Understand what’s at risk
Elasticsearch speaks plain HTTP. With security disabled, anyone who can reach :9200 can query, export or delete:
- Everything indexed — application and access logs, user profiles, search data. Logs in particular often contain tokens, emails, IPs and even passwords.
- Cluster control — list, read and delete any index with simple HTTP calls.
- Ransom — sweeps delete your indices and create one named like
read_me/recoverydemanding payment. - Kibana — if exposed too, it’s a full UI onto all of the above.
Open Elasticsearch has leaked billions of records in well-known breaches and is a standing ransomware target. Because logs frequently carry secrets and personal data, an exposed cluster is often a reportable data breach in its own right.
02Stop the bleeding — take it off the internet
ufw deny 9200 ufw deny 9300
network.host: 127.0.0.1 # or a private IP http.port: 9200
Restart Elasticsearch. Front any legitimate remote access with a VPN or an authenticating reverse proxy — never expose 9200 directly.
03Enable security — auth and TLS
Modern Elasticsearch ships with security features; turn them on in elasticsearch.yml:
xpack.security.enabled: true xpack.security.transport.ssl.enabled: true
Then set passwords for the built-in users:
# older versions bin/elasticsearch-setup-passwords interactive # newer versions bin/elasticsearch-reset-password -u elastic
- Create least-privilege roles per app — don’t let services use the
elasticsuperuser. - Rotate any credentials that appeared in indexed logs or data.
04Read the logs — what was touched?
List indices to spot deletions or a ransom note, and check access for the exposure window:
curl localhost:9200/_cat/indices?v
- A missing index or a new
read_me/recoveryindex confirms a ransom sweep. - Check your reverse-proxy/firewall logs for who hit
:9200and when. - Assume any index that existed while open was read in full.
05Recover from snapshots — don’t pay
- Restore deleted indices from your Elasticsearch snapshot repository to a now-secured cluster.
- Document the ransom index before deleting it.
- As with other open-data ransoms, paying rarely recovers anything.
Indexed logs and user data usually mean breach-notification duties apply. Involve legal/compliance.
06Make sure it can’t happen again
- Bind to localhost/private and firewall 9200/9300; never expose the HTTP API directly.
- Always run with security enabled (auth + TLS) and least-privilege roles.
- Schedule snapshots and test restores.
- Scrub secrets/PII out of logs before indexing them.
- Monitor and alert on index deletions.
Was this guide useful?
These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.