Splunk Urges Immediate Patching of Critical Flaw Enabling Arbitrary File Operations

A newly disclosed security vulnerability in Splunk Enterprise has prompted urgent patching efforts after researchers revealed that the flaw could allow unauthenticated attackers to perform arbitrary file operations and potentially achieve remote code execution. The issue, identified as CVE-2026-20253, affects certain versions of Splunk Enterprise and carries a critical CVSS score of 9.8. 

The vulnerability stems from weaknesses in a PostgreSQL sidecar service used within affected deployments. While Splunk Cloud remains unaffected, organizations running vulnerable on-premises versions of Splunk Enterprise are being urged to install security updates as soon as possible. 

CVE-2026-20253 Affects Multiple Splunk Enterprise Versions

According to a security advisory issued by Splunk, the flaw exists in Splunk Enterprise versions below 10.2.4 and 10.0.7. 

The company explained the issue in the following statement: 

“In Splunk Enterprise versions below 10.2.4 and 10.0.7, an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint.” 

Splunk further noted: 

“The vulnerability exists because the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-reachable user to invoke file operations without credentials.” 

Because the affected PostgreSQL endpoint does not enforce authentication requirements, attackers with network access can interact with it without providing valid credentials, creating a security risk for exposed systems. 

Patched Versions and Affected Releases

Splunk has released updates to address CVE-2026-20253 across affected product lines. 

The impacted and fixed versions are: 

• Splunk Enterprise 10.0.0 through 10.0.6 — fixed in 10.0.7
• Splunk Enterprise 10.2.0 through 10.2.3 — fixed in 10.2.4
• Splunk Enterprise 10.4 — not affected

The company also clarified that Splunk Cloud is not vulnerable to this issue because the platform does not utilize the PostgreSQL sidecars associated with the flaw. 

How Attackers Could Exploit the PostgreSQL Weakness

Security researchers explained that threat actors could exploit CVE-2026-20253 by abusing PostgreSQL functionality to write attacker-controlled files onto a target system. 

One key component of the attack involves lo_export, a PostgreSQL function capable of extracting a BLOB (Binary Large Object) from a database and saving it as a file on the underlying filesystem. By creating a malicious function that leverages lo_export, an attacker could write arbitrary content to files on the Splunk server. 

The attack becomes more dangerous when the malicious function is executed during a database restoration process. This allows the attacker-controlled content to be written directly to the filesystem, opening a pathway to further compromise. 

From Arbitrary File Write to Remote Code Execution

Researchers noted that obtaining arbitrary file-write capabilities within Splunk Enterprise can serve as a stepping stone toward full remote code execution. 

An attacker could overwrite Python scripts that are routinely executed by Splunk services. One example highlighted is: 

/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py 

By replacing or modifying such scripts with malicious code, an attacker could cause the payload to execute automatically when the script runs, effectively granting remote code execution on the affected system. 

Attack Chain Associated With CVE-2026-20253

The disclosed exploitation sequence involves several steps: 

1. Create a database and configure it to allow user authentication without a password while granting permissions required to execute functions such as lo_export.
2. Use the /backup endpoint to place a dump of the remote database onto the Splunk filesystem.
3. Use the /restore endpoint to import the malicious database dump, triggering execution of the attacker-created function during restoration and writing a malicious Python script to the filesystem.

Through this process, attackers can leverage the vulnerable PostgreSQL sidecar service to transform a file-write capability into a mechanism for executing arbitrary code.