RECONINTEL
◄ ALL POSTS
JUNE 10, 2026CVSS 9.8 · CRITICAL5 MIN READ

CVE-2026-20253: Splunk Enterprise Unauthenticated File Access via PostgreSQL Sidecar — How to Find Exposed Instances

Splunk Enterprise ships a PostgreSQL sidecar service that lacks authentication controls. Any network-reachable attacker can create or truncate arbitrary files on the Splunk server — no credentials required. CVSS 9.8 Critical, part of a 12-advisory batch that includes a separate RCE via deserialization. Here's how to find Splunk instances on your network and verify they're patched.

The Vulnerability

CVE-2026-20253 (CWE-306: Missing Authentication for Critical Function) is a critical vulnerability in Splunk Enterprise's Storage sidecar — a PostgreSQL-based backing service introduced in the 10.x architecture. The sidecar exposes a service endpoint that performs file operations (create and truncate) but has no authentication controls whatsoever. Any user who can reach the endpoint over the network can invoke these operations without credentials.

  • CVSS: 9.8 Critical (v3.1) — AV:N/AC:L/PR:N/UI:N — SVD-2026-0603
  • CWE: CWE-306 (Missing Authentication for Critical Function)
  • AFFECTED: Splunk Enterprise 10.2.0–10.2.3, 10.0.0–10.0.6; Splunk Cloud Platform below 10.4.2604.3 and 10.2.2510.14
  • FIXED: Splunk Enterprise 10.4.0, 10.2.4, 10.0.7; Splunk Cloud Platform 10.4.2604.3, 10.2.2510.14
  • EXPLOITED: No known exploitation in the wild (not in CISA KEV)
  • CREDIT: Alex Hordijk (hordalex)

The impact is severe: arbitrary file creation enables potential remote code execution by placing malicious content in web-accessible directories or overwriting configuration files. File truncation enables denial of service by wiping index data, logs, or critical configuration. The maximum exploitability score (3.9) reflects the trivial attack requirements — network-reachable, no authentication, no user interaction.

The PostgreSQL Storage Sidecar

The Storage sidecar is a relatively new component in Splunk Enterprise 10.x. It runs alongside splunkd as a managed subprocess and provides a full PostgreSQL cluster stack including PostgreSQL instances (ports 5432–5435), PgBouncer connection pooler (6432), Patroni HA manager (8008), and etcd consensus (2379–2380). An IPC Broker on port 8194 coordinates inter-sidecar communication. The vulnerability exists because one of these service endpoints lacks authentication, allowing any network-reachable user to invoke file operations directly.

Related: CVE-2026-20251 (RCE via Deserialization)

The same advisory batch includes CVE-2026-20251 (CVSS 8.8 High) — remote code execution through unsafe deserialization in Splunk Secure Gateway. A low-privileged user (no admin role needed) can inject malicious Python objects via the KV Store, which are deserialized by the jsonpickle library without validation. This affects a broader range of Splunk versions including 9.3.x and 9.4.x. The mitigation is disabling the Splunk Secure Gateway app, but this breaks Splunk Mobile, Spacebridge, and Mission Control.

Investigation Workflow

Splunk is one of the most widely deployed SIEM platforms in enterprise environments. If your organization runs Splunk Enterprise 10.x, you need to identify every instance and verify it's patched. Here's how to find Splunk servers on your network using RECON.

1. Port Scan: Find Splunk Services

Splunk Enterprise exposes several well-known ports. Scan your network for the primary Splunk services:

  • 8000 — Splunk Web (UI)
  • 8089 — splunkd management REST API
  • 8088 — HTTP Event Collector (HEC)
  • 8191 — KV Store
  • 9997 — Forwarder receiving port

For this specific CVE, also scan for the PostgreSQL sidecar ports: 5432, 6432 (PgBouncer), 8008 (Patroni), and 8194 (IPC Broker). If any of these ports are reachable from outside the Splunk server, the sidecar may be directly exposed to CVE-2026-20253.

2. TLS Inspect: Identify Splunk Certificates

Splunk generates self-signed certificates for its management API and web interface during installation. Pull the TLS certificate chain on ports 8089 and 8000. Look for:

  • • Issuer or subject fields containing Splunk, SplunkServerDefaultCert, or SplunkCommonCA
  • • The default CN SplunkServerDefaultCert — very common in deployments that haven't replaced the default TLS configuration
  • • Self-signed certificates on the management port 8089

3. HTTP Headers: Fingerprint Splunk Web

Splunk Web on port 8000 returns distinctive HTTP response headers and page content. Look for:

  • X-Frame-Options: SAMEORIGIN and Server headers characteristic of Splunk
  • • Login page redirects to /en-US/account/login — the default Splunk login path
  • • Response body containing Splunk branding, version strings, or build numbers

The management API on port 8089 responds to unauthenticated requests with XML containing the Splunk version, build number, and server name — use this to determine the exact version and whether it falls in the affected range.

4. DNS: Discover Splunk Infrastructure

Query internal DNS for common Splunk naming patterns: splunk-*, siem-*, idx-* (indexers), sh-* (search heads), hf-* (heavy forwarders), cm-* (cluster managers), ds-* (deployment servers). Reverse DNS on server subnets can reveal Splunk instances that aren't in your CMDB.

5. CVE Lookup: Confirm the Advisory

Use RECON's CVE Lookup to pull the full NVD entry for CVE-2026-20253. Cross-reference the affected version ranges (Enterprise 10.2.0–10.2.3 and 10.0.0–10.0.6) against the version numbers you retrieved from the management API to determine which instances need immediate patching.

The Full Advisory Batch

Splunk published 12 security advisories on June 10, 2026, covering the Enterprise platform, Splunk Cloud, and Splunk SOAR. Beyond CVE-2026-20253 and CVE-2026-20251, notable entries include:

  • CVE-2026-20252 (CVSS 7.6) — SSRF via Dashboard Studio PDF Export
  • CVE-2026-20258 (CVSS 7.1) — Stored XSS via Classic Dashboard HTML panels
  • CVE-2026-20254 through 20257 — Four input validation bypasses in Classic Dashboards (CSS injection, protocol-relative URL bypass, external content restriction bypass)

The volume of Classic Dashboard vulnerabilities (5 CVEs in one component) suggests systematic input validation weaknesses. Organizations using Classic Dashboards should treat the entire batch as a priority update.

Cross-Reference with External Data

  • SHODAN: Search "Splunk" port:8089 or product:"Splunk" to find internet-exposed instances
  • CVE LOOKUP: Check CVE-2026-20253 and CVE-2026-20251 in NVD for updated scoring
  • SPLUNK ADVISORY: SVD-2026-0603 — official advisory with version matrix

Remediation

  1. Patch immediately. Upgrade Splunk Enterprise to 10.4.0, 10.2.4, or 10.0.7. Splunk Cloud Platform customers should verify they're on 10.4.2604.3 or 10.2.2510.14.
  2. Verify sidecar port exposure. Check whether PostgreSQL sidecar ports (5432, 6432, 8008, 8194) are accessible from outside the Splunk server. These should be bound to localhost only — if they're reachable over the network, the attack surface is directly exposed.
  3. Network segment Splunk infrastructure. Ensure Splunk servers are in a dedicated management VLAN with strict firewall rules. Only allow necessary ports (8000, 8089, 9997) from authorized subnets.
  4. Address CVE-2026-20251 in parallel. The RCE via jsonpickle deserialization (CVSS 8.8) affects a broader version range including 9.3.x and 9.4.x. If you can't patch immediately, consider disabling the Splunk Secure Gateway app as a temporary mitigation.
  5. Audit the full advisory batch. Review all 12 SVD advisories from the June 2026 release. The Classic Dashboard vulnerabilities (CVE-2026-20254 through 20258) represent a systematic input validation weakness worth addressing.
  6. Monitor for exploitation. Watch for unexpected file creation or truncation on Splunk servers. Check filesystem integrity monitoring alerts, unusual PostgreSQL sidecar activity, and unexpected processes spawned by the sidecar service.

Every tool used in this investigation — port scan, TLS inspect, HTTP headers, DNS, CVE lookup — runs from your phone in RECON. Get it on the App Store.

Follow @hellorecon for new CVE investigations.

Sources

By Vladimir Slavin · Founder, RECON · [email protected]