InfoSecBulletin Cybersecurity for mankind
A serious pre-authentication remote code execution (RCE) flaw in Splunk Enterprise has been revealed, earning a very high CVSS score of 9.8. Tracked as CVE-2026-20253, Splunk shared the flaw on June 10, 2026. It impacts the PostgreSQL Sidecar Service that came with Splunk version 10.
The root cause of CVE-2026-20253 lies in the PostgreSQL Sidecar Service’s HTTP API endpoints specifically /v1/postgres/recovery/backup and /v1/postgres/recovery/restore which lack any authentication controls.
DoNot (APT-C-35) Targeting Bangladesh Military Personnel
McDonald’s, Vodafone Affected by Azure Theft Campaign Exposing Millions of Records
NIST to Modernize NVD in the Age of Artificial Intelligence
ALERT
Multiple TP-Link Flaws Allow to Bypass Auth and Escalate Privileges
LiteLLM supply chain attack reveals 153GB of stolen credentials online
PATCHCORD Backdoor Targets Telecom and CII In South Asia
Fortinet Fixes Multiple Flaws in FortiWeb, FortiManager, and FortiClient
“City-Forum” Campaign
“City-Forum” Campaign Attacks Salesforce and ServiceNow Instances Worldwide
Palo Alto Patches 11 New flaws Across PAN-OS, GlobalProtect, and Prisma Access
CVE-2026-20349, CVE-2026-68820
Cisco and Windows patched zero days exploited in attack
Splunk Enterprise Pre-Auth RCE
Anyone on the network can access these internal endpoints through Splunk’s main web app using a proxy. This means that attackers can call them without needing valid login details.
The biggest risk is with Splunk Enterprise on AWS, where the PostgreSQL Sidecar Service is turned on by default, making those setups easy targets.
On-site Windows setups are less quickly impacted because the service is either not installed or turned off by default.
WatchTowr found that the /backup endpoint sends attacker-controlled inputs straight to pg_dump, such as the backupFile path and database name.
Path traversal in the backupFile parameter allows anyone to create or delete files anywhere on the system.
The more important finding was about PostgreSQL’s design: the database setting can take a full libpq connection string, and any settings in it will replace fixed command-line options.
This allowed researchers to inject hostaddr and redirect pg_dump to connect to an attacker-controlled PostgreSQL server instead of localhost. With the ability to redirect pg_dump to an external host, researchers then turned to the /restore endpoint, which passes input to pg_restore.
A plaintext .pgpass file discovered at /opt/splunk/var/packages/data/postgres/.pgpass exposed the local postgres_admin credentials.
Injecting a passfile connection string that leads to this file allows attackers to log in to Splunk’s local PostgreSQL. They can then restore a database dump they control and run any SQL they want.
The harmful dump uses PostgreSQL’s lo_export function to place attacker-controlled data anywhere on the filesystem. This allows complete control over file writing as the splunk user.
With an arbitrary file write in hand, reaching RCE required only one final step. Researchers identified that Splunk regularly executes the Python script /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py.
This file was replaced with a harmful payload using the lo_export write method. This caused the code to run as the splunk user when Splunk ran the script again, finishing the pre-authentication RCE process.
Affected Versions and Mitigation
CVE-2026-20253 affects Splunk Enterprise versions 10.x and higher because the PostgreSQL Sidecar component was added in version 10.
Organizations using Splunk Enterprise, especially those on AWS, should update Splunk right away and check the filesystem access to the PostgreSQL Sidecar service folder.
Security teams need to check the .pgpass file and make sure the Splunk service ports are separate from outside connections.
South Korea fines Coupang Record $409 mln fine for data leak
