Port 8089 – Splunkd (Splunk Management / REST API)

Port 8089 is the default port for splunkd, the management daemon behind Splunk Enterprise and the Splunk Universal Forwarder. It speaks HTTPS (with a self-signed certificate out of the box) and exposes Splunk’s full REST API under /services/... — the same interface the web UI, forwarders, and deployment servers use to run searches, read and write configuration, and administer the instance. It is distinct from the two other Splunk ports people confuse it with: the Splunk Web UI on port 8000 and the HTTP Event Collector (HEC) on 8088. An exposed 8089 matters because it is the management plane: reach it with admin credentials and, by Splunk’s own design, you can run code on the server.

Why It’s Open

Splunk uses 8089 for everything that isn’t a human clicking around the web UI. Universal Forwarders phone home to it, search heads talk to indexers over it, deployment servers push apps through it, and any script or integration built on Splunk’s REST API hits it directly. Because it is load-bearing infrastructure for distributed Splunk deployments, it is almost always listening on every Splunk host — indexers, search heads, and forwarders alike.

The problem is that it frequently listens on 0.0.0.0 rather than being bound to an internal management range. A forwarder or indexer stood up quickly, moved to the cloud, or fronted by a permissive security group ends up answering splunkd on 8089 from the internet. Since Splunk sits on top of an organization’s logs — often spanning many network segments — an exposed management API is a high-value target well out of proportion to how mundane the port number looks.

Common Risks

• Default or weak credentials. Splunk historically shipped with admin:changeme, and plenty of older installs and forwarders still use it. (Splunk 7.1 removed the built-in default and forces an admin password at install, but that only helps hosts installed or reset since.) A working admin login over 8089 is game over.
• Admin equals remote code execution — by design. A Splunk admin can upload a custom app and invoke scripted/custom search commands that run arbitrary Perl or Python on the server. This is a legitimate Splunk feature, which is exactly why exposed splunkd with valid admin creds is treated as RCE (see the Metasploit path below).
• Full configuration and search access. The REST API lets an authenticated user run searches over every indexed log, read and rewrite inputs/outputs, add users, and reconfigure the instance. That is data exfiltration, tampering, and persistence in one interface.
• Information disclosure. Endpoints like /services/server/info reveal the exact Splunk version, build, OS, and licensing details — a clean fingerprint for picking the right exploit, and historically leaky on older builds.
• A long CVE history. Splunk Enterprise has shipped path-traversal, XSLT-based RCE, and info-disclosure bugs (below). An unpatched, internet-facing instance is a direct target.
• Lateral movement. Splunk deployments commonly have credentialed reach into many systems and network zones; compromising the Splunk plane often opens doors well beyond it.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

splunkd speaks HTTPS with a self-signed cert, so every request needs -k/--insecure. Start by confirming it really is Splunk, then check credentials and version.

Detect the service and version

nmap -sV -p 8089 <target>

Nmap fingerprints splunkd and usually reports “Splunk httpd” along with a version hint.

Confirm it’s the splunkd REST API and read server info

curl -k https://<target>:8089/services/server/info

On older/misconfigured builds this can leak the version and build unauthenticated; on patched instances it returns 401 and you’ll need credentials. Either way, an XML/Atom feed under /services/ confirms splunkd.

Test authentication and grab a session key

curl -k https://<target>:8089/services/auth/login \
  -d username=admin -d password=changeme

A <sessionKey> in the response means the credentials work — try the historical admin:changeme and any org-standard passwords first.

Check the TLS certificate

openssl s_client -connect <target>:8089 </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Metasploit — credential check and the admin-to-RCE path

msfconsole -q
use auxiliary/scanner/http/splunk_web_login
set RHOSTS <target>
run

use exploit/multi/http/splunk_upload_app_exec
set RHOSTS <target>
set USERNAME admin
set PASSWORD changeme
run

auxiliary/scanner/http/splunk_web_login brute-forces the Splunk login (it targets the web login on port 8000 by default), and exploit/multi/http/splunk_upload_app_exec turns valid admin credentials into code execution by uploading a custom app and calling its scripted search command — using admin:changeme by default.

Log every open port 8089, the version you fingerprinted, and any credential that works as you go, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The most important “exploit” on 8089 isn’t a CVE at all: a valid admin login is remote code execution because Splunk lets admins upload apps and run scripted search commands (weaponized as Metasploit exploit/multi/http/splunk_upload_app_exec, defaulting to admin:changeme). On top of that, Splunk Enterprise has real, verified vulnerabilities:

• CVE-2024-36991 — Path traversal on the /modules/messaging/ endpoint in Splunk Enterprise on Windows below 9.2.2, 9.1.5, and 9.0.10. Unauthenticated arbitrary file read (e.g. .../etc/passwd, and Splunk’s own hashed-credential files). CVSS 7.5. Public proof-of-concept exploits and a Nuclei template appeared within days of disclosure.
• CVE-2023-46214 — Splunk Enterprise below 9.0.7 and 9.1.2 fails to sanitize user-supplied XSLT, so an attacker can upload a malicious XSLT stylesheet that yields remote code execution. CVSS 8.8 (requires a low-privileged authenticated session and a user interaction).
• CVE-2018-11409 — Splunk through 7.0.1 discloses sensitive information (including the license key) via __raw/services/server/info/server-info?output_mode=json — the same server/info endpoint you fingerprint on 8089. CVSS 5.3.
• CVE-2011-4642 — Splunk Web 4.2.x before 4.2.5: mappy.py lets an authenticated admin execute arbitrary code through the mappy search command (exploitable via CSRF). CVSS 4.6. A clean historical illustration of the “Splunk admin can run code” design that still underpins the RCE risk today.

The previous version of this page listed three CVEs that have nothing to do with Splunk or port 8089, and they have been removed after checking each against NVD: CVE-2020-8318 is a Lenovo System Interface Foundation privilege-escalation bug, CVE-2018-7419 is a Wireshark NBAP-dissector crash, and CVE-2020-1938 (“Ghostcat”) is an Apache Tomcat AJP flaw — a genuine vulnerability, but not a splunkd issue, despite the old stub claiming it “affects Splunk deployments.” Always verify a CVE’s product on NVD before trusting a port page’s list.

Mitigation

• Never expose 8089 to untrusted networks. Bind splunkd’s management interface to an internal address or firewall TCP/8089 to the forwarders, indexers, and search peers that actually need it — not 0.0.0.0. Audit cloud security groups and container port mappings for an accidental public 8089.
• Kill default and weak credentials. Set a strong, unique admin password (Splunk 7.1+ forces this at install; older installs and forwarders must be checked by hand), and prefer token-based REST auth over storing the admin password in scripts.
• Patch to a current release. The path-traversal, XSLT-RCE, and info-disclosure bugs above are all fixed in maintained Splunk builds — keep indexers, search heads, and forwarders current.
• Replace the self-signed certificate with a properly issued one, enforce TLS, and restrict the management interface so its traffic can be monitored rather than ignored.
• Enforce least privilege. Because the admin role effectively grants code execution, limit who holds it, disable or tightly control custom-app upload and scripted commands where you can, and review role capabilities regularly.
• Front management with a bastion. Reach splunkd over a VPN or an SSH-tunneled admin path rather than opening 8089 to the world, and terminate any public web tier behind TLS on 443.

Real-World Example

The canonical port-8089 compromise needs no zero-day. An attacker mass-scans for TCP/8089, confirms splunkd from the /services/ REST feed, and tries admin:changeme against /services/auth/login. On any host installed before Splunk 7.1 — or a forwarder nobody re-passworded — that login often just works. From there the built-in feature set is the exploit: upload a small custom app, register a scripted search command, and invoke it to run Perl or Python as the Splunk service account. This is precisely what Metasploit’s exploit/multi/http/splunk_upload_app_exec automates, and it’s why exposed splunkd with default creds is scored as full remote code execution rather than “just” an info leak.

The pattern recurs with fresh bugs, too: when CVE-2024-36991 (unauthenticated arbitrary file read on Windows) was disclosed in July 2024, working proof-of-concept exploits were public within days, and exposed Splunk instances — easy to enumerate on 8089 and 8000 — became immediate targets for reading credential material straight off disk. The lesson is consistent: an internet-facing Splunk management plane is one weak password or one missed patch away from handing over the logging system that watches everything else.

FAQ

What is port 8089 used for?

Port 8089 is Splunk’s management port — the splunkd daemon’s REST API, served over HTTPS. Splunk components (forwarders, indexers, search heads, deployment servers) and any REST integration use it to run searches, read and write configuration, and administer the instance. It is separate from the Splunk Web UI on port 8000 and the HTTP Event Collector on 8088.

Is port 8089 the same as the Splunk web interface?

No. The Splunk Web UI that people log into with a browser runs on port 8000. Port 8089 is the underlying management/REST API (splunkd) that the UI, forwarders, and scripts talk to. They’re related faces of the same product, but 8089 is the machine-to-machine management plane.

Why is port 8089 dangerous if it’s exposed?

Because it’s the management interface. A valid admin login over 8089 lets you run searches across all indexed data, rewrite configuration, and — by Splunk’s design — upload apps and scripted search commands that execute arbitrary code on the server. Combined with the historical admin:changeme default and a self-signed cert nobody monitors, an internet-facing 8089 is a high-severity finding.

What are the default Splunk credentials on 8089?

Historically admin:changeme. Splunk 7.1 removed the built-in default and requires an admin password to be set at install (minimum 8 characters), but instances installed before that, and Universal Forwarders that were never re-passworded, still frequently accept it. Always test it — and then change it.

How do I check what’s running on port 8089?

Run nmap -sV -p 8089 <target> to fingerprint splunkd, then curl -k https://<target>:8089/services/server/info (the -k is needed for the self-signed cert). An Atom/XML feed under /services/ confirms the Splunk management API and may reveal the version you need for CVE checks.

How do I secure port 8089?

Firewall TCP/8089 to the Splunk peers that require it (not the public internet), set a strong unique admin password, patch to a maintained Splunk release, replace the self-signed certificate and enforce TLS, and limit the admin role since it effectively grants code execution. Reach the management API over a VPN or SSH tunnel rather than exposing it directly.

TL;DR

• Service: splunkd — Splunk’s management / REST API (HTTPS, self-signed), distinct from Splunk Web on 8000 and HEC on 8088
• Default port: 8089/TCP
• Biggest risk: an exposed management API with default/weak admin creds (admin:changeme) — a valid admin login is effectively remote code execution via custom-app upload, plus real path-traversal (CVE-2024-36991) and XSLT-RCE (CVE-2023-46214) bugs on unpatched builds
• Mitigation: firewall 8089 to Splunk peers only, set a strong admin password, patch to a current release, enforce real TLS, and enforce least privilege on the admin role