Splunk Shipped an Unauthenticated Database Sidecar: CVE-2026-20253

The thing about your security and observability tools is that they run with a lot of access. They read your logs, reach into your hosts, and sit on a trusted part of the network. So when one of them quietly ships a service you did not know about, and that service answers the network with no authentication, the blast radius is exactly as bad as it sounds.

That is CVE-2026-20253, a critical flaw in Splunk Enterprise. Splunk 10 bundles a PostgreSQL sidecar to back some of its newer features, and in affected versions the endpoint that talks to that sidecar did not check who was calling it. Anyone who could reach it over the network could invoke file operations without credentials, which is a pre-auth foothold on a box that, being a SIEM, sees everything. It is rated CVSS 9.8, it is patched, and CISA added it to the Known Exploited Vulnerabilities catalog on June 18, 2026, upgrading it from proof-of-concept to active exploitation the next day.

Here is what the bug is, what to do about it today, and the more useful point hiding underneath it.

What the bug is

The vulnerable component is the PostgreSQL sidecar service that ships with Splunk Enterprise 10. Splunk runs it as a companion process to support functionality added in the 10 line. The problem is classic and is captured exactly by its weakness class, CWE-306: Missing Authentication for Critical Function: the sidecar's endpoint exposed file operations and never verified the caller.

In practice that means an unauthenticated, network-reachable attacker can create or truncate arbitrary files on the host, running as the Splunk user. Arbitrary file write as a service account is not the end state an attacker wants, it is the stepping stone: write to a location the platform later executes, clobber a config, or drop a script, and file-write becomes remote code execution. That escalation is why the industry reporting calls this an unauthenticated RCE and why it is being exploited in the wild rather than sitting as a theoretical write primitive.

Who is affected

Per the advisory, the affected and fixed versions are:

• Splunk Enterprise 10.2, below 10.2.4 (fixed in 10.2.4)
• Splunk Enterprise 10.0, below 10.0.7 (fixed in 10.0.7)
• 9.4 and earlier are not affected, because they predate the PostgreSQL sidecar, which is the whole reason the exposure exists in the 10 line and not before.

If you run Splunk Cloud, Splunk manages that patching; the urgent action is for self-managed Enterprise installs. The vulnerability was published on June 10, 2026 and the exploitation status moved to active by June 19.

What to do now

The fix is an upgrade, and there is a real mitigation if you cannot upgrade immediately.

1. Upgrade to 10.2.4 or 10.0.7 (or later). This is the actual remediation.

2. If you cannot upgrade today, disable the PostgreSQL sidecar service. The advisory calls this out as the mitigation. You lose the features that depend on it, but you close the hole.

3. Check whether the sidecar is even reachable. A missing-auth bug only matters if an attacker can reach the port. On each Splunk host, see what is listening and from where:

# What is listening, and is the Postgres sidecar bound to all interfaces?
sudo ss -tlnp | grep -i postgres
# or, more broadly, anything exposed beyond localhost
sudo ss -tlnp | awk '$4 !~ /127.0.0.1|::1/'

If that sidecar is bound to 0.0.0.0 and your Splunk hosts are reachable from anything other than a tightly controlled management network, you are in the exposed group. Firewall it to localhost or a management subnet regardless of patch state.

4. Hunt for the file-write footprint. Because the primitive is arbitrary file create/truncate as the Splunk user, look for what that leaves behind: recently created or zero-length files under Splunk's directories and writable paths, unexpected changes to startup or config files, and anomalous processes spawned by the Splunk service account.

The part that outlives this CVE

Patch the bug and the headline is over. The pattern is not.

Modern "appliance" software (SIEMs, observability suites, internal developer platforms, self-hosted SaaS) increasingly ships with helper services baked in. A bundled PostgreSQL for metadata. A Redis for caching. A message broker for events. An embedded object store. These are convenient: the product works out of the box because its dependencies come with it. They are also attack surface you inherited without choosing it, and they have three uncomfortable properties.

They are invisible. Nobody filed a ticket to stand up that Postgres, so it is not in your inventory, your CMDB, or your threat model. You cannot defend a service you do not know is running.

They are on someone else's patch cadence. The bundled database is versioned and updated by the vendor, inside the product, on the vendor's schedule. You do not get to apply a Postgres CVE fix to it directly; you wait for the appliance update. Splunk's sidecar is exactly this: a database you do not administer, patched only when Splunk ships a new build.

They are assumed to be internal, which quietly gets read as "safe." The sidecar talks to the main process over the loopback or the local network, so it was built as if only trusted callers would ever reach it. Missing authentication looks acceptable right up until the host is multi-homed, the port binds to 0.0.0.0, or someone is already on the segment.

So the durable takeaway is an inventory and segmentation habit, not a one-time patch:

• Inventory what your tools spawn. For the platforms that matter, actually look: ss -tlnp on the hosts, the container or pod list for the deployment, the process tree under the service account. Write down every helper service and what port it listens on.
• Segment internal sidecars by default. Bind helper services to localhost or a dedicated management network, and firewall them there. "It is only for internal use" should be enforced by the network, not assumed by the code.
• Do not equate internal with authenticated. Treat an unauthenticated internal endpoint as a finding in its own right, before someone else finds it for you.
• Watch vendor changelogs for new bundled dependencies. "Now includes an embedded PostgreSQL" in release notes is a security event, not just a feature. It means your attack surface changed and your inventory is now out of date.

CVE-2026-20253 is a clean, fixable bug, and if you run Splunk Enterprise 10 you should go fix it now. But the reason it is worth more than a line in a patch log is that almost every team is running some tool that quietly brought its own database along, and almost nobody has it written down.