CVE-2026-20253

What it actually does

This is a network-exploitable missing-authentication vulnerability in Splunk Enterprise’s PostgreSQL sidecar service endpoint. In affected Splunk Enterprise 10.2 releases before 10.2.4 and 10.0 releases before 10.0.7, the sidecar endpoint allows a network-reachable unauthenticated user to invoke file creation or file truncation operations without credentials. Because the operation targets arbitrary files accessible to the service context, exploitation can result in destruction or alteration of Splunk-managed files, configuration tampering, data loss, service disruption, and potentially broader compromise depending on file permissions and deployment configuration. Splunk Enterprise 9.4 and earlier are not affected.

Why it matters to the business

Successful exploitation can let an external or internal attacker damage or manipulate files used by Splunk Enterprise without logging in, potentially causing monitoring outages, loss of indexed or operational data, broken dashboards and alerts, corrupted configurations, and interruption of security operations that depend on Splunk. The CVSS score is critical, EPSS is very high, the issue is in CISA KEV with active in-the-wild exploitation, and the remediation deadline is 2026-06-21, so exposed systems should be treated as urgent even though ransomware use has not been reported.

How an attack unfolds

An attacker first identifies a Splunk Enterprise deployment running an affected 10.x version with the PostgreSQL sidecar service endpoint reachable over the network. Because the endpoint lacks authentication, the attacker does not need valid Splunk credentials, user interaction, or prior access. The attacker sends crafted requests to the sidecar endpoint that instruct it to create or truncate chosen files. If the targeted files are important to Splunk operation, the attacker can corrupt configuration, delete file contents by truncation, disrupt service startup, break applications or searches, or destroy operational data. If the service has access to sensitive files, the attacker may also cause integrity and availability impacts beyond Splunk itself. Public reporting indicates active exploitation, so exposed instances should be investigated for evidence of unauthorized file operations and not only patched.

How to fix it

Upgrade affected Splunk Enterprise deployments to a fixed release: Splunk Enterprise 10.2.4 or later for the 10.2 branch, and Splunk Enterprise 10.0.7 or later for the 10.0 branch. Splunk Enterprise 9.4 and earlier are not affected by this vulnerability. If immediate upgrade is not possible, disable the PostgreSQL sidecar service as the vendor-recommended mitigation. Additionally, restrict network access to Splunk management and sidecar services to trusted administrative networks only, block unauthenticated access paths at firewalls or security groups, and confirm that no sidecar endpoint is exposed to the internet. Because this is KEV-listed and actively exploited, mitigation should be considered temporary; upgrade should remain the target state.

How to confirm the fix worked

Confirm the installed Splunk Enterprise version on every deployment and verify that affected 10.x systems have been upgraded to 10.2.4 or later, 10.0.7 or later, or that the PostgreSQL sidecar service has been disabled. Validate from an untrusted network segment that the sidecar endpoint is not reachable. Review service configuration to ensure only trusted administrative hosts can access Splunk management and sidecar ports. After patching or disabling the sidecar, restart services as required and verify normal Splunk indexing, search, alerting, and app functionality. For exposure validation, compare asset inventory, vulnerability scanner results, package versions, and externally observed network services; do not rely only on whether exploitation attempts are seen in logs.

Typical attack path

1. Scan for internet-facing or internally reachable Splunk Enterprise 10.x services and associated sidecar endpoints.
2. Fingerprint the deployment or infer that it is running an affected Splunk Enterprise 10.2 version below 10.2.4 or 10.0 version below 10.0.7.
3. Connect to the PostgreSQL sidecar service endpoint without credentials.
4. Submit unauthenticated requests that invoke file creation or file truncation operations against attacker-selected paths.
5. Target Splunk configuration, application, state, log, or data files to cause tampering, denial of service, or operational disruption.
6. Use resulting instability, destroyed files, or modified behavior to impair monitoring, hide activity, or support follow-on intrusion objectives.

How to detect it

Investigate both network access to the PostgreSQL sidecar service and host-level file activity on affected Splunk Enterprise systems. Review Splunk internal logs, operating system audit logs, EDR telemetry, firewall logs, load balancer logs, reverse proxy logs, and network flow records for unauthenticated or unexpected connections to sidecar-related services from non-administrative IP addresses. Look for file creation or truncation events performed by the Splunk service account or sidecar process, especially against configuration directories, app directories, state files, log files, and data paths. Correlate suspicious file truncation timestamps with inbound network connections to Splunk sidecar or management ports. Examine Splunk service restarts, crash loops, parsing failures, missing configuration stanzas, disabled apps, sudden drops in indexing volume, missing alerts, and unexpected zero-byte files. Because the vulnerability may be used for destructive tampering rather than conventional malware deployment, absence of malware indicators does not rule out exploitation. Preserve host artifacts before repair if compromise is suspected.

What your security team should do

• Immediately inventory Splunk Enterprise 10.x deployments and identify versions below 10.2.4 in the 10.2 branch and below 10.0.7 in the 10.0 branch.
• Prioritize any internet-facing or broadly reachable Splunk Enterprise systems for emergency upgrade or sidecar disablement.
• Meet or beat the CISA KEV remediation deadline of 2026-06-21 for covered systems; treat overdue systems as high-risk exceptions requiring compensating controls.
• If upgrade cannot be completed immediately, disable the PostgreSQL sidecar service and restrict network access to Splunk administrative and sidecar interfaces to trusted management networks.
• Hunt for signs of unauthorized file creation, truncation, configuration corruption, unexpected Splunk restarts, and abnormal sidecar service access during the period before remediation.
• Back up critical Splunk configuration, app, and state files before remediation and preserve forensic copies of logs from potentially exposed systems.
• Review firewall, proxy, EDR, and host logs for unknown sources connecting to Splunk sidecar-related services, especially before authentication events or from non-administrative networks.
• After remediation, perform functional validation of ingestion, search, alerting, dashboards, and apps to detect damage caused by prior file truncation.