TCP Port 9200 – Elasticsearch

Port 9200 is the standard port for Elasticsearch, an open-source distributed search and analytics engine first released in 2010 by Shay Banon. Elasticsearch indexes JSON documents and provides fast full-text search, structured queries, and aggregations across very large datasets. It is one of the most widely deployed pieces of modern data infrastructure and is the underlying engine for many search features, log analysis platforms, and observability stacks.

The most common deployment context is the ELK stack (Elasticsearch, Logstash, Kibana) and its more modern variants (the Elastic Stack, Elastic Cloud, OpenSearch), where Elasticsearch stores log data, application metrics, and security events, with Logstash or Elastic Agent feeding data in and Kibana providing the visualization and search frontend. Many enterprise security operations centers run on this stack, ingesting and searching billions of events per day.

Port 9200 carries the HTTP-based REST API that clients use to index documents, run queries, and administer the cluster. A separate port, 9300, carries internal cluster communication between Elasticsearch nodes; in a multi-node deployment the two ports serve different purposes. The IANA registry actually lists port 9200 as “wap-wsp” (a Wireless Application Protocol service from the early 2000s), a legacy assignment that real-world usage has thoroughly displaced.

In 2017, the project forked under different governance, eventually leading to OpenSearch, an Apache-licensed fork maintained by Amazon. OpenSearch also uses port 9200 by default. From a network perspective, Elasticsearch traffic and OpenSearch traffic on port 9200 are interchangeable, and IDS rules referencing the port apply equally to both.

Inbound TCP/9200 from the public internet is unusual in 2026 and is treated as a serious exposure. Outbound TCP/9200 from end-user devices is uncommon and usually indicates an administrative tool or local development.

About TCP Port 9200

Port 9200 carries the IANA assignment for wap-wsp. The IANA description reads: ‘WAP connectionless session service’.

Security Considerations

Elasticsearch on port 9200 has a security history that combines two patterns familiar from the rest of the modern NoSQL data stores: severe vulnerabilities in older versions, and widespread exposure-by-default of unauthenticated instances on the public internet.

The two most consequential vulnerabilities of the mid-2010s era are both detected by IDS rules in our data. CVE-2014-3120 affected Elasticsearch versions 1.1 and earlier, where the dynamic scripting feature allowed any client sending a search query to include a Groovy or MVEL script that the server would execute. With Elasticsearch typically running with broad filesystem and network privileges, an unauthenticated attacker who could reach port 9200 could execute arbitrary code on the host. CVE-2015-1427 followed in early 2015: even after the project sandboxed dynamic scripting in response to the previous CVE, a sandbox escape was discovered that allowed the same outcome. Both vulnerabilities were widely exploited by opportunistic attackers and integrated into automated exploitation tools, and the IDS rules in our data continue to detect the exploitation patterns. Modern Elasticsearch versions disable dynamic scripting by default and run with stricter security defaults, but unpatched legacy instances remain vulnerable.

Beyond the named CVEs, the data shows the Win32/Recslurp.D malware family in 2 rules, reflecting a botnet that used compromised Elasticsearch hosts as command-and-control infrastructure during the same era.

The exposed-by-default story for Elasticsearch parallels MongoDB and Redis. Earlier Elasticsearch versions did not include authentication in the free open-source distribution; authentication was a feature of the paid X-Pack subscription. This meant that the typical install-from-package-manager-with-default-settings deployment had no authentication enabled. Combined with Elasticsearch’s default of binding to all network interfaces in some early versions and documentation that occasionally suggested binding to public IPs for cluster communication, the result was a large population of internet-reachable Elasticsearch clusters. The 2017 ransom wave that hit MongoDB and Redis also targeted Elasticsearch with the same pattern: dump the data, delete it, leave a ransom note.

Elastic responded by making authentication free in Elasticsearch 8.0 (released February 2022), with secure defaults requiring users to set up authentication during initial cluster bootstrap. OpenSearch ships with similar secure defaults.

Common practice today is to use the secure defaults that modern Elasticsearch and OpenSearch versions provide, require authentication for all access, restrict network access to specific application server IP addresses, never expose port 9200 directly to the public internet, and use TLS for all connections. For new deployments, managed services from major cloud providers are generally recommended because they handle network isolation and authentication by default.

IDS Rule References

3 IDS / security rules reference TCP port 9200. Presence in IDS rules does not mean traffic on this port is malicious. These are patterns security tools monitor.

Rule categories (top 2): command-and-control (2), attempted-admin (1).

Sample rule descriptions for TCP port 9200:

• ET MALWARE Win32/Recslurp.D C2 Request (no alert)
• ET MALWARE Win32/Recslurp.D C2 Response
• ET WEB_SERVER Possible CVE-2015-1427 Elastic Search Sandbox Escape Remote Code Execution Attempt

Malware Activity

Some malware indicators are observed on this port.

2 of 3 IDS rules for TCP port 9200 involve malware activity.

Families observed (top 1): Win32_Recslurp_D (2).

Data Sources

This information is compiled from: IANA Service Name and Transport Protocol Port Number Registry and Emerging Threats Open Ruleset (BSD 2-Clause / GPLv2 per SID range).