Unauthenticated Elasticsearch Cluster Access for Hunters
Elasticsearch without authentication on a public port is a recurring breach headline. For bounty work, the pattern is the same: find 9200 (or a proxied /_cluster/health), confirm anonymity, prove data exposure, and leave the indices intact.
OpenSearch shares many endpoints. Fingerprint before you assume product names.
Minimal probes that establish the bug
Safe starting requests:
GET /GET /_cluster/healthGET /_cat/indices?vGET /_nodes(can be heavy—use sparingly)
If these succeed without credentials or API keys, you have unauthenticated cluster access. Capture cluster name, version, and index names. Redact customer PII in screenshots; prefer indices that look like logs or your own canary.
Write access is a separate claim. POST /bugflare-canary/_doc with a unique field proves writable clusters when creation is allowed by scope. Delete nothing. Do not run _shutdown or flood bulk inserts.
A yellow or red health status is operational context, not a vulnerability by itself. Still include it; operators recognize their cluster faster when you quote the name and status they see in their own monitors.
Timed-out searches on huge clusters are not proof of auth. Retry with filter_path and a tiny size. Keep traffic polite; Elasticsearch clusters in production already suffer enough from scrapers.
What hunters miss
Exposure is not always raw 9200. Look for:
- Kibana anonymously proxying Console
- nginx paths like
/elastic/,/es/ - Security disabled in
elasticsearch.ymlleftovers in public docker-compose - Cloud snapshots of "dev" clusters with real data
Sometimes GET / is open but indices require auth—or the reverse with odd plugin setups. Test both cluster meta and a single document GET on a non-sensitive index.
Cross-index search (/_search) can reveal more than _cat/indices. Use a tiny size and a query that matches your canary. Mass scraping private documents is how findings get you banned.
Kibana spaces and anonymous access settings deserve their own paragraph in the report when the data path goes through the UI rather than port 9200. Same impact class, different remediation owner.
Snapshot repositories listed via /_snapshot can expose bucket names. That is useful context for impact, not an invitation to restore or overwrite snapshots.
I still see teams confuse "security plugin installed" with "security enforced." If anonymous _cat works, the plugin is not doing its job for that listener—full stop.
Severity and narrative
Tie impact to data class: auth logs, PII, source code analysis, payment events. "Cluster health is yellow" is not impact. "Anonymous search returns password reset tokens in message fields" is.
If you only listed index names, argue reconnaissance value honestly—medium is fine when contents stay sealed. If documents contain secrets, show one redacted example and stop.
Scripting endpoints (/_scripts, painless elsewhere) raise severity when anonymous callers can run them. Prove with a canary script id you create and delete, or describe the capability if write tests are forbidden.
Recommend enabling native or SSO auth, TLS, network policies, disabling scripting where unused, and rotating any secrets that lived in indexed documents.
Elastic's security settings documentation explains the switch-on path. Operators who thought "VPN will cover it" need the public /_cat/indices output more than a lecture.