Why Use App-Level Auth When Every Database Has Auth? (Splunk Enterprise CVE-2026-20253 Pre-Auth RCE)

What Happened

Security researchers have detailed a critical vulnerability in Splunk Enterprise, a popular data analysis platform. The flaw allows attackers to bypass authentication and remotely execute malicious code on the server. This is achieved by tricking a background database service into connecting to an attacker-controlled server and downloading malicious files. Organizations using affected versions of Splunk, especially those hosted on AWS where the vulnerable service is enabled by default, are at high risk. Administrators should immediately apply the patches provided by Splunk to secure their systems.

Key Takeaways

• CVE-2026-20253 is a critical (CVSS 9.8) pre-authentication Remote Code Execution (RCE) vulnerability in Splunk Enterprise's PostgreSQL Sidecar Service.
• The vulnerability is exploitable by default on Splunk Enterprise on AWS, but requires specific configurations to be enabled on Windows on-premise installations.
• Attackers can bypass loopback-only network restrictions by proxying requests through the main Splunk web application on port 8000.
• Exploitation involves injecting connection string parameters into the 'database' argument to force the Splunk server to connect to an attacker-controlled database.
• RCE is achieved by restoring a malicious database dump that uses the 'lo_export' function to overwrite legitimate Splunk Python scripts.

Affected Systems

• Splunk Enterprise versions 10.0.0 to 10.0.6
• Splunk Enterprise versions 10.2.0 to 10.2.3
• Splunk Cloud Platform below 10.4.2604.3
• Splunk Cloud Platform below 10.2.2510.14
• Splunk Enterprise on AWS (vulnerable by default)

Vulnerabilities (CVEs)

• CVE-2026-20253

Attack Chain

The attacker sends an unauthenticated HTTP POST request to the Splunk web application, which proxies it to the local PostgreSQL Sidecar Service backup endpoint. By injecting connection string parameters into the 'database' argument, the attacker forces the service to connect to an external, attacker-controlled database and dump its contents to the local filesystem. The attacker then uses the restore endpoint, injecting the path to the local Splunk '.pgpass' file to authenticate, and restores the malicious database dump. This dump contains a malicious SQL function utilizing 'lo_export' to overwrite a legitimate Splunk Python script, which is subsequently executed by the system, resulting in Remote Code Execution.

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No
• Platforms: watchTowr Detection Artefact Generator

The article provides a custom Python script (Detection Artefact Generator) to test if a Splunk instance is vulnerable by checking HTTP response codes, but does not provide standard SIEM or IDS rules.

Detection Engineering Assessment

EDR Visibility: High — EDR solutions can monitor file modifications to legitimate Splunk scripts and detect anomalous child processes spawned by Splunk or Python. Network Visibility: Medium — Network sensors can detect inbound requests to the vulnerable proxy endpoints, but the traffic might be encrypted. Outbound PostgreSQL connections from the Splunk server to unknown external IPs are highly anomalous and visible. Detection Difficulty: Moderate — While the initial exploit payload is delivered via web requests, the subsequent outbound database connection and file overwrite behaviors are distinct and relatively easy to detect with proper baseline monitoring.

Required Log Sources

• Web Server Access Logs
• Process Creation Logs
• File System Monitoring Logs
• Network Flow Logs

Hunting Hypotheses

Control Gaps

• Lack of authentication on internal microservices (Sidecar)
• Insufficient input validation on database connection strings
• Lack of file integrity monitoring on critical application scripts

Key Behavioral Indicators

• Splunk web application proxying requests to local port 5435
• pg_dump or pg_restore executing with unexpected hostaddr parameters
• Modification of ssg_enable_modular_input.py by the splunk user

False Positive Assessment

• Low. The specific combination of accessing the PostgreSQL Sidecar recovery endpoints and injecting connection string parameters is highly indicative of exploitation and unlikely to occur during normal administrative operations.

Recommendations

Immediate Mitigation

• Verify against your organization's incident response runbook and team escalation paths before acting.
• Apply the latest security patches provided by Splunk for CVE-2026-20253 immediately.
• If patching is not immediately possible, evaluate whether access to the Splunk web interface can be restricted to trusted IP addresses or VPNs.

Infrastructure Hardening

• Consider implementing strict egress filtering on the Splunk server to block unexpected outbound connections, such as outbound PostgreSQL (port 5432) traffic.
• Evaluate whether File Integrity Monitoring (FIM) can be deployed to alert on modifications to critical Splunk application files and scripts.

User Protection

• N/A

Security Awareness

• Consider incorporating lessons on the risks of unauthenticated internal microservices and SSRF-like proxy behaviors into secure coding and architecture training.

MITRE ATT&CK Mapping

• T1190 - Exploit Public-Facing Application
• T1105 - Ingress Tool Transfer
• T1574.001 - Hijack Execution Flow: DLL Search Order Hijacking
• T1059.006 - Command and Scripting Interpreter: Python

Additional IOCs

• File Paths:
  • /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py - Legitimate Splunk Python script targeted for overwrite to achieve RCE.
  • /opt/splunk/share/splunk/search_mrsparkle/exposed/watchTowr.txt - PoC text file dropped in the Splunk webroot to prove execution.
• Command Lines:
  • Purpose: Malicious database function using lo_export to write arbitrary files to disk during database restore. | Tools: PostgreSQL, lo_export | Stage: Execution