Elasticsearch Unrestricted Access Information Disclosure

This finding is not a neat version-bounded code bug; it is an exposure condition. Any self-managed Elasticsearch node or cluster that is remotely reachable and has security disabled can leak cluster metadata and, in many deployments, the indexed data itself over the HTTP API. The risk is concentrated in older operational patterns: versions before 8.0 did not auto-enable security, and versions before 6.8.0 / 7.1.0 did not include core security features in the free tier, so insecure deployments were historically common. Even on 8.x, you can still end up exposed if security auto-configuration was skipped or explicitly disabled.

Tenable calling this MEDIUM underrates what actually happens on a reachable host. The exploit is not sophisticated at all: if the service answers unauthenticated requests, the attacker can enumerate indices and often dump sensitive data with curl or standard Elasticsearch tooling. The real friction is reachability—you must be on a network path to the node—but once that condition is met, this behaves more like a ready-made data breach than a garden-variety informational finding.

Why this verdict

• Upgrade from MEDIUM: once reachable, the attacker often needs nothing more than unauthenticated HTTP requests to enumerate and read data
• Real-world amplifier: Elasticsearch frequently contains logs, telemetry, PII, tokens, internal hostnames, and other high-value material that accelerates lateral movement
• Internet-exposed population is non-trivial: Shadowserver actively reports open Elasticsearch and Shodan has historically shown enormous exposure volume
• Exploit chain is short: no memory corruption, gadget chain, or auth bypass research is needed; this is direct API abuse
• Active abuse history matters: exposed Elasticsearch has been hit by automated wipe and extortion campaigns, so this is not a theoretical red-team-only condition
• Downward pressure applied: the attacker still needs network position to the API, which means private VPC placement, VPN gating, and firewalling materially reduce exposure

Why not higher?

This is not a universal unauthenticated internet RCE. The attacker needs a route to the Elasticsearch HTTP interface, and well-run enterprises usually keep clusters off the public internet or behind access controls. Also, some exposed nodes leak metadata more readily than full document contents, so the blast radius is deployment-dependent.

Why not lower?

Scoring this as MEDIUM treats it like a mild informational leak, which is not how these incidents play out. On a reachable cluster, the path from detection to bulk data theft is short, cheap, and historically abused at scale.

1. Block direct access to the HTTP API — Put Elasticsearch behind private networking, security groups, or an allowlist-only reverse proxy and remove broad reachability to port 9200. Because there is active exploitation history against exposed Elasticsearch, do this immediately, within hours, not on the normal HIGH timeline.
2. Enforce authentication — Enable xpack.security and require authenticated access for all API calls unless a narrowly defined anonymous profile is absolutely required. Treat this as the primary compensating control and deploy immediately, within hours.
3. Require TLS and authenticated proxies — Terminate only through a controlled proxy or load balancer that enforces auth, source restrictions, and logging before traffic reaches Elasticsearch. Deploy within hours as a fast containment layer if native security cannot be turned on the same day.
4. Audit for data exposure and destructive APIs — Review HTTP/API logs for unauthenticated /_cat/*, _search, scroll, snapshot, and DELETE activity, and alert on unknown source IPs. Start the hunt immediately because prior exposure may already have resulted in silent reads.
5. Snapshot and harden backups — Create verified snapshots and ensure backup storage is separately protected so a wipe or ransom event does not become an outage crisis. For a HIGH verdict this should be completed within 30 days, but exposure containment still comes first within hours.

Run this on an auditor workstation or scanner host that has the same network path an attacker would have; that matters more than local shell access. Invoke it as bash check_es_open.sh http://es-node.example.com:9200 or against https:// if applicable. No root is required; the script performs only unauthenticated read-only HTTP checks and prints VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# check_es_open.sh
# Read-only exposure check for unauthenticated Elasticsearch access.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE

set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <http[s]://host:port>"
  exit 3
fi

CURL_OPTS=(--silent --show-error --location --max-time 10 --connect-timeout 5)
TMP_BODY="$(mktemp)"
trap 'rm -f "$TMP_BODY"' EXIT

request() {
  local url="$1"
  local code
  code=$(curl "${CURL_OPTS[@]}" -o "$TMP_BODY" -w '%{http_code}' "$url" 2>/dev/null) || return 99
  echo "$code"
  return 0
}

looks_like_es_root() {
  grep -Eq 'cluster_name|cluster_uuid|version|tagline' "$TMP_BODY"
}

# 1) Root endpoint: tells us whether the API is exposed and if auth is enforced.
code=$(request "$TARGET/")
rc=$?
if [[ $rc -ne 0 ]]; then
  echo "UNKNOWN - could not connect to $TARGET/"
  exit 2
fi

if [[ "$code" == "401" || "$code" == "403" ]]; then
  echo "PATCHED - root endpoint requires authentication or is blocked ($code)"
  exit 0
fi

if [[ "$code" == "200" ]] && looks_like_es_root; then
  # 2) Try a common read endpoint to confirm unauthenticated data/metadata access.
  code2=$(request "$TARGET/_cat/indices?format=json")
  rc2=$?
  if [[ $rc2 -eq 0 && "$code2" == "200" ]]; then
    echo "VULNERABLE - unauthenticated Elasticsearch API access confirmed; _cat/indices returned 200"
    exit 1
  fi

  code3=$(request "$TARGET/_cluster/health")
  rc3=$?
  if [[ $rc3 -eq 0 && "$code3" == "200" ]]; then
    echo "VULNERABLE - unauthenticated cluster metadata access confirmed; _cluster/health returned 200"
    exit 1
  fi

  # Root exposed but deeper reads blocked: still an exposure condition, but impact may be reduced.
  echo "VULNERABLE - Elasticsearch root endpoint is accessible without authentication; deeper read endpoints were not confirmed"
  exit 1
fi

if [[ "$code" == "301" || "$code" == "302" || "$code" == "307" || "$code" == "308" ]]; then
  echo "UNKNOWN - request redirected; retest the final URL or proxy target"
  exit 2
fi

if [[ "$code" == "000" ]]; then
  echo "UNKNOWN - no HTTP response received"
  exit 2
fi

echo "UNKNOWN - unexpected response code $code from $TARGET/"
exit 2

Sources

1. Tenable Plugin 101025
2. Elastic Docs - Minimal security setup
3. Elastic Docs - Networking settings
4. Elastic Blog - Security for Elasticsearch is now free
5. Elastic Docs - Automatic security setup
6. Shadowserver - Open Elasticsearch Report
7. Censys - How to Make Sure Your Elasticsearch Databases Aren’t Exposed
8. CERT-EU Threat Memo - Attacks on Elasticsearch databases