Is port 9200 (Elasticsearch) exposed to the internet without authentication?
Port 9200 is Elasticsearch's documented default HTTP port, the interface every search, aggregation and index-management request goes through. Before version 8.0, Elasticsearch's security features were opt-in and disabled out of the box, so a freshly started node would answer unauthenticated requests to read, modify or delete any index on whatever network interface it was bound to.
By AdminKit team, Netbase JSC · Updated October 24, 2026
Why a no-password Elasticsearch cluster used to be the default
Elasticsearch’s own networking settings documentation confirms 9200 as the default HTTP port for the REST API that every search, index and administrative request flows through. For years, the security features that gate that API behind authentication — user accounts, role-based access control, and TLS — were part of a paid tier and disabled by default; a cluster started with no extra configuration simply answered any request that reached it. Elastic’s own 8.0 release notes confirm this changed: as of version 8.0, security is enabled by default for self-managed clusters, with authentication, role-based access control, and encrypted communication switched on automatically rather than left for an administrator to opt into.
What keeps going wrong anyway
The problem now is mostly inherited exposure: clusters deployed on a pre-8.0 version that were never upgraded, or that had security manually disabled during setup “to get it working” and never turned back on. Researchers keep finding the result. SOCRadar reported finding a publicly reachable Elasticsearch server, requiring no authentication at all, that held approximately 544 million records in URL, email and plaintext-password format — one entry in a long-running pattern of researchers discovering large, completely open Elasticsearch indices simply by connecting to port 9200 with no credential whatsoever.
What an exposed cluster actually allows
An unauthenticated Elasticsearch REST API on port 9200 typically allows anyone to list every index on the cluster, read any document in any of them, and — depending on the specific API calls permitted — write new documents or delete indices outright. There’s no concept of a read-only guest account at that point; a connection either has no access (behind authentication) or has essentially the same access as an administrator (with security disabled).
How to check your own exposure
AdminKit’s planned open ports check is designed to test whether port 9200 and other commonly-exposed service ports on your own public IP respond from outside your network. Confirming this directly matters because “we’re on a recent version” doesn’t guarantee security is actually turned on if it was ever manually disabled along the way.
How to fix it
- If you’re on Elasticsearch 8.0 or later, make sure
xpack.security.enabledwas never turned off — Elastic ships it on by default, but a manual override during setup can disable it. - If you’re on an older version, upgrade and explicitly enable the security features rather than relying on network isolation alone.
- Bind Elasticsearch’s HTTP interface to a private network address instead of a public one, and put a firewall or authenticating reverse proxy in front of port 9200 so it’s never directly reachable from the internet.
- Audit existing indices for data that shouldn’t have been reachable, since researchers and automated scanners alike continuously probe for open 9200 instances.
Defensive use only
Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
Is 9200 an officially assigned port for Elasticsearch?
No — IANA has not assigned port 9200 to Elasticsearch; it's simply Elastic's own documented default for the HTTP API, configurable via the http.port setting. That matters because a scan showing 9200 open doesn't guarantee Elasticsearch is behind it, but Elasticsearch deployments overwhelmingly use the default rather than changing it.
Didn't Elastic fix the no-authentication-by-default problem?
Yes, as of version 8.0 — Elastic's own release notes confirm security features including authentication, role-based access control and encrypted communication are enabled by default for self-managed clusters. The risk now is almost entirely clusters that were deployed on an older version and never upgraded or had security manually re-enabled, or that disabled it for convenience during setup and never turned it back on.
How bad is it in practice if my cluster is actually exposed?
Severe — an unauthenticated Elasticsearch REST API lets anyone list every index, read every document, and in many cases write or delete data outright. Security researchers have repeatedly found exposed, unauthenticated clusters holding hundreds of millions of records, including one case researchers reported finding roughly 544 million plaintext credential records in a single open index.
What's the fastest fix if I find my own cluster's port 9200 open?
If you're on 8.0 or later and security was manually disabled, re-enable xpack.security.enabled; if you're on an older version, upgrade and enable the security features explicitly, then bind Elasticsearch to a private interface and put a firewall or reverse proxy in front of it rather than exposing 9200 directly.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.