Port reference
Port 9300 (TCP) – Elasticsearch transport
Default port for Elasticsearch's binary transport protocol used for node-to-node and cluster communication.
Default state
Older Elasticsearch exposed the transport protocol on 9300 with no authentication or TLS, so a host reaching 9300 could join or query the cluster. Modern versions enable security and bind privately.
Common attacks
- Unauthenticated transport access to query or exfiltrate cluster data
- Rogue nodes joining the cluster to read or manipulate indices
- Version-specific scripting RCE such as the CVE-2015-1427 Groovy era
- Information disclosure of cluster state and indexed documents
Hardening
- Bind transport to a private interface (transport.host); never expose 9300 to the internet
- Enable the security features (authentication and node-to-node TLS)
- Firewall 9300 to cluster members only
- Disable dynamic scripting on legacy versions and patch RCE bugs
- Keep Elasticsearch patched and audit cluster membership
nmap snippet
nmap -p9300 --script banner <target>Replace <target> with the host or range you're authorized to scan.
What runs on port 9300?
Port 9300 is the default for Elasticsearch's transport protocol, the binary channel nodes use to talk to each other for cluster formation, shard replication, and internal queries. It is distinct from the client-facing HTTP/REST API on 9200; 9300 is meant for intra-cluster traffic between Elasticsearch nodes.
Why it matters for security
The transport layer carries the full trust of the cluster. Older Elasticsearch exposed 9300 with no authentication or TLS, so any host that could reach it could query data or join the cluster as a node and manipulate indices. The same era of Elasticsearch also allowed dynamic scripting abuse, including the Groovy RCE (CVE-2015-1427), making transport exposure highly dangerous.
How it's attacked
Attackers scan for open 9300 and, without authentication, query or exfiltrate cluster data or attempt to join a rogue node that can read and manipulate indices. Against legacy versions they exploit dynamic scripting RCE such as CVE-2015-1427 to run code on a node. Leaked cluster state aids further enumeration alongside the HTTP API on 9200.
Hardening checklist
Bind transport to a private interface via transport.host and keep 9300 off
the public internet. Enable the built-in security features (authentication
and node-to-node TLS), and firewall 9300 to cluster members only. On
legacy versions disable dynamic scripting and patch RCE bugs, keep Elasticsearch
patched, and audit cluster membership. Use the nmap snippet above to check
exposure on hosts you are authorized to test.
Related ports
Frequently asked questions
- What is the difference between Elasticsearch ports 9200 and 9300?
- 9200 is the HTTP/REST API used by clients, while 9300 is the binary transport protocol used for node-to-node and cluster communication. Both should be bound privately, secured with TLS and authentication, and firewalled.
- Is it safe to expose Elasticsearch transport on port 9300?
- No. Without security, a host reaching 9300 can join the cluster or query data, and legacy versions allowed scripting RCE (CVE-2015-1427). Bind transport privately, enable node-to-node TLS, and firewall the port.