How attackers used a security monitoring tool's own database service to blind an entire SOC

The Context

Splunk Enterprise is the dominant Security Information and Event Management (SIEM) platform in enterprise and government environments. A SIEM is the central nervous system of a security operations center: it collects logs from every other system in the organization, firewalls, laptops, servers, cloud services, authentication systems, and correlates them to detect threats. When something goes wrong anywhere in the network, the SIEM is where defenders look first.

That centrality is exactly what makes this vulnerability different from a typical software flaw. Compromising Splunk does not just give an attacker access to one system. It gives them access to the logs of every system, and the ability to control what the security team sees across all of them.

The Attack, Phase by Phase

Phase 1: Unauthenticated File Write via the Backup Endpoint

The PostgreSQL Sidecar Service exposes two recovery endpoints on the network: /v1/postgres/recovery/backup and /v1/postgres/recovery/restore. Neither requires authentication. Any attacker who can reach these endpoints over the network can invoke them freely.

The attacker starts with the backup endpoint. They send a crafted request that includes attacker-controlled database connection parameters, specifically the address of a PostgreSQL server they control, along with a chosen file path. Splunk's sidecar service obediently connects to the attacker's server, retrieves a malicious database dump, and writes it to the Splunk filesystem. The connection parameters are not properly validated, so the attacker can use path traversal techniques to place the dump file in a directory of their choosing rather than a safe, isolated location.

Phase 2: Script Injection via lo_export

The malicious database dump is not just data. It contains a crafted PostgreSQL function that uses lo_export, a standard database feature for writing content to the server's filesystem. When the attacker triggers the restore endpoint, Splunk's sidecar processes the dump and executes that function.

The lo_export call writes a malicious Python script over an existing Splunk internal script. The documented target path is /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. This is one of the scheduled scripts Splunk runs automatically. The original file is replaced. The attacker's payload is now sitting in its place, waiting for Splunk's scheduler to fire.

Phase 3: Code Execution and SOC Blindness

When Splunk's scheduler next runs the overwritten script, the attacker's payload executes with the privileges of the Splunk service account. No further interaction is needed. The attacker now has code running inside the SIEM.

From this position, the attacker can read every log Splunk has ingested: firewall events, authentication records, endpoint alerts, cloud activity. They can delete logs, disable detection rules, silence alerts, and alter dashboards. The security operations center continues operating, but it is watching a screen the attacker controls. Defenders see nothing unusual because the tool that would show them something unusual is the compromised system.

Phase 4: Lateral Movement Using Splunk's Own Integrations

Splunk sits at the center of the enterprise network by design. It holds API tokens, webhook secrets, service account credentials, and cloud integration keys used to pull data from dozens of other systems. With code execution on the Splunk server, all of those become pivot points.

The attacker can move from Splunk into Windows domain environments, Active Directory, connected cloud accounts, and any other system Splunk was configured to monitor. Every integration that made Splunk useful as a security tool now makes it useful as a launchpad.

What Made This Possible

1. A trusted internal component shipped without authentication. The PostgreSQL Sidecar Service was designed as an internal tool, assumed to be unreachable from untrusted networks. That assumption was treated as a substitute for actual authentication controls. When network segmentation was imperfect, or when the service was exposed by default on AWS deployments, the assumption collapsed and there was nothing beneath it.

2. A standard database feature weaponized without restriction. The lo_export function is legitimate PostgreSQL functionality. The sidecar service processed database dumps without validating their contents, so a standard feature became a file-write primitive with no additional exploitation required.

3. The target was the detection layer itself. Most vulnerabilities compromise a system that defenders can observe from the outside. This one compromised the observation system. The attacker's ability to operate invisibly was not a secondary benefit; it was a direct consequence of which system was targeted.

The eight-day window from public proof-of-concept to confirmed exploitation is not an anomaly. It is the new baseline for critical pre-authentication vulnerabilities in internet-facing enterprise software.

What Should Have Stopped This

No single defense here depends on the compromised component's own integrity to function. That shared trait is the principle: controls that live outside the attacked system survive its compromise.

• Network segmentation enforced at the infrastructure level. The sidecar service endpoints should never have been reachable from untrusted networks. A firewall rule or network access control that blocks external access to /v1/postgres/recovery/ paths does not rely on Splunk to enforce it. This is the single highest-impact control for unpatched instances.
• Web Application Firewall rules blocking the specific paths. A WAF sitting in front of Splunk can block requests to the recovery endpoints as a temporary measure while patching is completed. Splunk explicitly names this as an interim option.
• Principle of least privilege for the Splunk service account. If the Splunk service account runs with minimal permissions, the payload that executes in Phase 3 has a smaller blast radius. It cannot write to arbitrary system paths or access credentials outside Splunk's own directory.
• Patch applied. Versions 10.0.7 and 10.2.4 remove the vulnerability. There are no workarounds that fully substitute for patching. CISA's mandatory deadline for federal agencies was June 21, 2026.

The Takeaway

This attack is the same class of failure as the Stryker Intune wipe: a privileged management tool weaponized against the organization it was built to protect. In the Stryker case, the tool was a device management platform. Here, the tool is the detection platform itself. The difference is that compromising the detection platform does not just cause damage. It hides all subsequent damage from the people responsible for finding it.

The Axios supply chain attack blinded defenders by poisoning telemetry at the source. This attack blinded defenders by compromising the system that processes telemetry. The pattern across all three is identical: systems fail when they trust a boundary the attacker controls.

Pattern to remember: When the security tool is the target, the attacker gains not just access but invisibility, making compromise of the detection layer categorically different from compromise of any other system.

What changed: Defenders can no longer treat their SIEM as a trustworthy observer of the network once that SIEM exposes unauthenticated service endpoints, because the first system an attacker may choose to blind is the one watching everything else.

The Technical Mechanism

CVE-2026-20253 is classified under CWE-306 (Missing Authentication for Critical Function). The vulnerability exists in the PostgreSQL Sidecar Service introduced in Splunk Enterprise version 10, specifically in the REST endpoints /v1/postgres/recovery/backup and /v1/postgres/recovery/restore. These endpoints perform database dump and restore operations and expose no application-level authentication controls.

File-write primitive (Phase 1): The /backup endpoint accepts user-supplied PostgreSQL connection parameters including hostaddr=, dbname=, port=, and passfile=. These parameters are passed to pg_dump without sufficient validation. An attacker supplies the address of an attacker-controlled PostgreSQL server. Splunk's sidecar connects to that server, retrieves a dump, and writes it to the local filesystem. The passfile= parameter enables path traversal, allowing the dump to be placed outside the intended directory.

RCE chain via lo_export (Phase 2): The attacker's malicious dump contains a SQL function invoking lo_export, PostgreSQL's built-in Binary Large Object export function. When the /restore endpoint processes the dump, lo_export executes and writes attacker-controlled content to an arbitrary filesystem path. The documented target is /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, a Python modular input script executed by Splunk's internal scheduler.

Execution (Phase 3): Splunk's scheduler invokes the overwritten script on its normal cycle. The payload runs with the privileges of the Splunk service account (splunk on Linux, SYSTEM or a configured service account on Windows). No further attacker interaction is required after the restore is triggered.

AWS exposure: The official Splunk Enterprise Amazon Machine Image (AMI) ships with the PostgreSQL Sidecar Service pre-installed and active. AWS deployments using the AMI are immediately vulnerable without additional configuration. On-premises Windows deployments may require additional steps before the sidecar endpoint is network-reachable, but any deployment where the endpoint is accessible from an untrusted network is fully exploitable.

CVSS v3.1 base score: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Bug ID: VULN-67169.

CVE and Advisories

• CVE-2026-20253: Unauthenticated arbitrary file creation and truncation in PostgreSQL Sidecar Service. CVSS 9.8. CWE-306.
• SVD-2026-0603: Splunk vendor advisory, published June 10, 2026, updated June 18, 2026 to acknowledge limited in-the-wild exploitation.
• CISA KEV entry: Added June 18, 2026. Remediation deadline for FCEB agencies: June 21, 2026 under Binding Operational Directive BOD 26-04. First Splunk vulnerability ever added to the KEV catalog.

Disclosed alongside three additional high-severity Splunk flaws: CVE-2026-20258 (stored XSS, CVSS 7.1), CVE-2026-20252 (SSRF via Dashboard Studio PDF export, CVSS 7.6), and CVE-2026-20251 (Splunk Secure Gateway RCE).

MITRE ATT&CK Mapping

Indicators of Compromise

Detection is complicated by the attacker's ability to alter Splunk's own logs post-compromise. Organizations should look for indicators before the SIEM is fully under adversary control.

Network Indicators

• Outbound connections from the Splunk server to unknown external IP addresses on PostgreSQL port 5432 (TCP)
• Inbound HTTP POST requests to /v1/postgres/recovery/backup or /v1/postgres/recovery/restore from untrusted source IPs
• Requests containing path traversal sequences (../) in PostgreSQL connection parameters

Host Indicators

• Unexpected pg_dump or pg_restore process execution on the Splunk server
• Database dump files (.sql, .dump) appearing in unexpected filesystem locations outside standard Splunk data directories
• Modification timestamp changes on /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py or other modular input scripts
• Splunk service account initiating outbound network connections not consistent with normal data collection

Detection Limitation

CISA's BOD 26-04 requires FCEB agencies to apply Forensics Triage Requirements to assess whether systems were compromised prior to patching. This requirement exists because a fully compromised Splunk instance may have had its own logs altered. Organizations should correlate network-level logs (firewall, proxy, NetFlow) with Splunk internal logs rather than relying solely on Splunk's own records.

Horizon3.ai released a Rapid Response detection test on June 15, 2026, available at their CVE-2026-20253 research page. watchTowr Labs released a neutered proof-of-concept at their GitHub repository that checks whether the /v1/postgres/recovery/backup endpoint is accessible, usable for exposure verification without triggering exploitation.

Attribution

No specific threat actor, nation-state group, or ransomware gang has been publicly attributed to the confirmed in-the-wild exploitation as of June 20, 2026. Splunk PSIRT described exploitation as "limited" in its June 18 advisory update. Resecurity is actively tracking exploitation activity but has not named a specific actor. CISA has not confirmed attribution to specific ransomware campaigns, though the agency notes that missing authentication vulnerabilities in enterprise data platforms have historically served as initial access vectors in ransomware intrusion chains. The gap between public proof-of-concept publication (June 12) and confirmed exploitation (June 18) was under one week.

Primary Sources