Vulnerabilities

Splunk published advisory SVD-2026-1001 on October 7 for CVE-2026-76268, a missing authentication flaw rated CVSS 9.8 in Splunk Enterprise. Patroni, the tool that keeps the PostgreSQL database inside Splunk's storage sidecar highly available, exposes a REST API on search head cluster members. Splunk says that API does not require authentication for critical configuration operations, so anyone with network access to it can run operating system commands of their choosing, without credentials or user interaction.

Splunk Enterprise 10.4.0 to 10.4.2 and 10.2.0 to 10.2.6 are affected, and 10.4.3 and 10.2.7 fix it. Splunk has not reported exploitation, there is no public proof of concept, and the flaw is not in the CISA Known Exploited Vulnerabilities (KEV) catalog. The same sidecar gave attackers a way in earlier this year, though: CVE-2026-20253, another unauthenticated sidecar flaw rated 9.8, went into KEV on June 18. Treat search head clusters on 10.2 or 10.4 as an emergency patch.

How it works

From release 10 onwards, Splunk Enterprise runs helper processes called sidecars next to splunkd. The Storage sidecar, set up by the [postgres] stanza in server.conf, runs PostgreSQL for features such as the Edge Processor control plane, OpAmp (agent management) and SPL2 data pipelines. It is on by default in Splunk Enterprise. On a search head cluster, Patroni manages that database across members. It decides which copy is primary, handles failover and stores the cluster's dynamic configuration in etcd, a small key value store that Splunk runs in another helper called Nascent.

Patroni controls all of this through a REST API. Read endpoints report health. The state-changing ones, PATCH and PUT /config, POST /restart, /reload, /switchover and /reinitialize, rewrite configuration and restart or rebuild the database. Patroni can protect those endpoints with HTTP Basic credentials and a host allowlist, and its documentation says the allowlist defaults to allowing every host. According to Splunk's advisory, the API on affected search head cluster members accepted critical configuration operations with no authentication at all.

Splunk has not said which operation leads to command execution. PostgreSQL has several settings that are shell commands run by the database server, and Patroni can push settings and restart the database, so control of the cluster configuration is generally enough to run code as the account that owns the sidecar. Commands then run on the search head itself, with access to everything splunkd can read on that host.

The API listens on a TCP port that Splunk's IPC Broker assigns. Splunk's sidecar documentation uses 8008, Patroni's usual port, in its example (postgres:patroni:address = 8008 under [ipc_broker]), but when no address is set the broker picks a random free port. Do not assume 8008; check what your members actually listen on.

What attackers are doing

Nothing has been reported so far. Splunk found the flaw itself and credits Gabriel Nitu, and as of October 9 no vendor or tracker reports exploitation or published exploit code.

The earlier sidecar bug shows how quickly that can change. CVE-2026-20253 let an unauthenticated user create or truncate files through a PostgreSQL sidecar endpoint in 10.0 and 10.2, and CISA added it to KEV on June 18 with a remediation deadline of June 21. Attackers already know where the sidecar sits and that it answers without a login.

A search head is a valuable target. It holds saved searches, correlation rules and alert actions, the credentials that apps store to reach other systems, and the role mappings for the analysts who use it. An attacker who runs commands there can mute the alerts that would have caught them and then read logs from across the estate.

What to do

1. Upgrade every cluster member

Move 10.4 to 10.4.3 or later and 10.2 to 10.2.7 or later, on every search head cluster member, and run the upgrade the way Splunk documents for the cluster so the members do not drift apart. Splunk's table lists only Splunk Enterprise. The same release batch also produced 10.0.10 and 9.4.15. Splunk lists those in its general fix list for other CVEs in the batch, and some coverage repeats all four as fixes for this flaw. The advisory's version table says 10.0 and 9.4 are not affected by CVE-2026-76268, and we follow that. They still need upgrading for the rest of the batch.

The scores also differ between sources: Splunk gives CVSS 9.8 (vector AV:N/AC:L/PR:N/UI:N), while at least one write-up says 9.1. The vendor figure is the one to use.

2. If you cannot upgrade today

Splunk's workaround applies if you do not use Edge Processor, OpAmp or SPL2 data pipelines. In $SPLUNK_HOME/etc/system/local/server.conf, set disabled = true in the [postgres] stanza and restart Splunk Enterprise. With the sidecar stopped, Patroni stops too.

If you need those features, find the Patroni port with $SPLUNK_HOME/bin/splunk btool server list ipc_broker --debug and confirm it with ss -ltnp on each member. Then use host firewall rules on each member, or the network firewall, so that port answers only the other cluster members. Do the same for the etcd ports (2379 and 2380 in Splunk's example). This shrinks the set of hosts that can attack; it does not fix the flaw.

3. Check whether it was used

Splunk has published no indicators of compromise, so the checks are about behaviour.

• In firewall or flow logs, look for connections to the Patroni port on any search head from hosts outside the cluster, since the advisory date and before.
• Read the current dynamic configuration with a GET /config request to each member's Patroni API from a cluster host, and look for PostgreSQL parameters or commands nobody set. Nascent backs up etcd data every five minutes to $SPLUNK_HOME/var/run/nascent/backup, which gives you earlier copies to compare against.
• Look for child processes of the sidecar's PostgreSQL or Patroni processes other than the database's own workers, such as shells, curl or wget, and for new files or cron entries owned by the Splunk service account.
• In Splunk, review recent changes to saved searches, correlation rules, alert actions, users and roles, and see whether any alert stopped firing.

4. If you find signs of compromise

Rebuild the affected member on a fixed release instead of cleaning it in place, and restore apps and configuration from a copy taken before the activity. Rotate the credentials stored on the search heads: passwords and API tokens saved by apps and add-ons, LDAP and SAML bind accounts, and the cluster's shared secret (pass4SymmKey). Then check the systems those credentials reach.

The wider lesson

Sidecars added PostgreSQL, Patroni, etcd and a broker to a product many teams still see as one process listening on 8000 and 8089. Each one brings its own listening port, and two of them have now answered without authentication in one year. After any Splunk upgrade, list the ports every search head and indexer opens, and allow only the ports the cluster really needs to talk to each other.

Our attack surface management work finds management and cluster ports like these that are reachable from places they should not be, and our security operations team can review your Splunk detections for tampering. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Splunk advisory SVD-2026-1001, Splunk sidecar configuration settings, Cybersecurity News, GBHackers, The Hacker Wire, Mallory, Patroni REST API documentation, Patroni configuration documentation, Halo Security on CVE-2026-20253.