Skip to content

Splunk Enterprise CVE-2026-20253 pre-auth file write / RCE

Summary

Splunk disclosed CVE-2026-20253 on 2026-06-10: an unauthenticated arbitrary file creation and truncation vulnerability in the PostgreSQL Sidecar Service endpoint in Splunk Enterprise. Splunk rates it CVSS 9.8 critical and says Splunk Enterprise versions below 10.2.4 and 10.0.7 are affected.

CISA added CVE-2026-20253 to the Known Exploited Vulnerabilities catalog on 2026-06-18, confirming known in-the-wild exploitation and setting a U.S. federal remediation due date of 2026-07-09. Treat exposed Splunk Enterprise management / web surfaces as emergency containment targets, not only routine patch candidates.

watchTowr Labs published a 2026-06-12 technical analysis showing how the exposed sidecar endpoints can be reached through Splunk Web, how attacker-controlled PostgreSQL backup / restore parameters can become arbitrary file writes, and how those writes can be turned into remote code execution by overwriting a Splunk-executed Python script. Track this as edge / security-platform exposure because Splunk often sits near privileged logs, credentials, and incident-response workflows.

CISA KEV update

  • Date added: 2026-06-18.
  • Known exploitation: CISA lists CVE-2026-20253 as exploited in the wild.
  • Due date: 2026-07-09 for U.S. federal civilian agencies; use a shorter window for internet-facing Splunk Enterprise.
  • Defender read: prioritize reachability reduction, upgrade validation, and review for backup / restore endpoint access before treating the instance as a trusted source of incident telemetry.

Tags

Why this matters

  • The vulnerable surface is unauthenticated when reachable, and Splunk assigned the vulnerability a network, low-complexity, no-user-interaction CVSS vector.
  • CISA KEV status means exploitation is no longer only a plausible outcome from public exploit analysis; defenders should assume internet-reachable vulnerable instances may have been touched.
  • watchTowr reports Splunk Enterprise on AWS had the PostgreSQL Sidecar Service installed and enabled by default in their testing; manually installed on-prem Windows deployments differed depending on whether the sidecar service was installed and enabled.
  • The immediate primitive is arbitrary file creation / truncation, but watchTowr demonstrated a path from file write to code execution by abusing PostgreSQL pg_dump / pg_restore behavior and a Splunk-executed Python script.
  • Splunk Cloud is not affected according to Splunk's 2026-06-12 advisory update because Splunk Cloud does not use PostgreSQL sidecars.

Reported chain

Unauthenticated sidecar access

  • Splunk's advisory describes the root issue as missing authentication controls on a PostgreSQL Sidecar Service endpoint.
  • watchTowr identified Splunk Web proxy access to sidecar paths such as /en-US/splunkd/__raw/v1/postgres/recovery/backup.
  • watchTowr's detection artifact treats a 400 response with any supplied Authorization header as a vulnerable-access signal and 401 as not vulnerable for that check.

Backup endpoint file creation

  • watchTowr traced /backup handling to a pg_dump command where attacker-controlled values influence the PostgreSQL user, database string, and backup output path.
  • By injecting PostgreSQL connection parameters such as hostaddr and controlling a remote PostgreSQL server, an attacker can cause Splunk to dump attacker-supplied database content to a chosen local file path.

Restore endpoint and code execution path

  • watchTowr then used the /restore endpoint, pg_restore, the local PostgreSQL passfile, and PostgreSQL large-object export behavior to write attacker-controlled content into Splunk's filesystem.
  • Their proof path overwrote /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, a Python script Splunk executes, turning arbitrary file write into command execution.
  • The public article includes detection code and enough request shape detail for defenders to validate exposure; treat vulnerable internet-facing Splunk Enterprise instances as high-priority emergency patch targets.

Exposure and triage

Affected / fixed versions

  • Splunk Enterprise 10.2.0 through 10.2.3: upgrade to 10.2.4 or later.
  • Splunk Enterprise 10.0.0 through 10.0.6: upgrade to 10.0.7 or later.
  • Splunk Enterprise 10.4: Splunk marks 10.4.0 as not affected.
  • Splunk Cloud: Splunk's 2026-06-12 advisory update says Splunk Cloud is not affected because PostgreSQL sidecars are not used.

Immediate defender actions

  • Patch or isolate internet- and partner-facing Splunk Web / management interfaces before relying on log review.
  • For KEV-driven programs, meet or beat CISA's 2026-07-09 due date; for public-facing instances, isolate or upgrade immediately.
  • Check whether the PostgreSQL Sidecar Service endpoint is installed, enabled, and reachable from untrusted networks.
  • Review web, Splunk management, and reverse-proxy logs for requests to /splunkd/__raw/v1/postgres/, especially /v1/postgres/recovery/backup and /v1/postgres/recovery/restore.
  • Preserve filesystem metadata before cleanup if exploitation is suspected; arbitrary file write can overwrite scripts, app files, or other operational artifacts.
  • Review recently modified Splunk app scripts and executable paths, including splunk_secure_gateway scripts if present.
  • Rotate credentials exposed to the Splunk host or logs only after containment and forensic preservation, because Splunk systems often store operational secrets, tokens, and incident data.

Sources

  • Splunk advisory SVD-2026-0603: https://advisory.splunk.com/advisories/SVD-2026-0603
  • watchTowr Labs: https://labs.watchtowr.com/why-use-app-level-auth-when-every-database-has-auth-splunk-enterprise-cve-2026-20253-pre-auth-rce/
  • watchTowr detection artifact repository: https://github.com/watchtowrlabs/watchTowr-vs-Splunk-CVE-2026-20253
  • CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog