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.
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.
Tags
- ops
- operations
- Splunk
- CVE-2026-20253
- pre-authentication
- arbitrary file write
- RCE
- security platform
- edge service
- PostgreSQL
- incident response
Why this matters
- The vulnerable surface is unauthenticated when reachable, and Splunk assigned the vulnerability a network, low-complexity, no-user-interaction CVSS vector.
- 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_restorebehavior 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
Authorizationheader as a vulnerable-access signal and 401 as not vulnerable for that check.
Backup endpoint file creation
- watchTowr traced
/backuphandling to apg_dumpcommand where attacker-controlled values influence the PostgreSQL user, database string, and backup output path. - By injecting PostgreSQL connection parameters such as
hostaddrand 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
/restoreendpoint,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.
- 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/backupand/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_gatewayscripts 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.
Related pages
- Ivanti Sentry CVE-2026-10520 exploitation
- Check Point VPN CVE-2026-50751 exploitation
- Cisco Catalyst SD-WAN Manager CVE-2026-20245 exploitation
- ServiceNow instance unauthenticated table-query exploitation
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