Splunk CVE-2026-76268: Unauthenticated Patroni API RCE

What to do

1. Run $SPLUNK_HOME/bin/splunk version on every search head and list the 10.2.x and 10.4.x cluster members.
2. Upgrade those to 10.4.4 or 10.2.8, which also fix the October 21 sidecar password bug (CVE-2026-76298); move 10.0 and 9.4 to 10.0.11 or 9.4.16.
3. If you cannot upgrade yet and do not use Edge Processor, OpAmp or SPL2 data pipelines, set disabled = true in the [postgres] stanza of $SPLUNK_HOME/etc/system/local/server.conf and restart.
4. Firewall the sidecar ports (Patroni is 8008 in Splunk's documented example) so only other cluster members can reach them.
5. Use tar packages rather than Linux packages for the upgrade if local users can write to the Splunk installation (CVE-2026-76266).

How to check if you are affected or compromised

• Run $SPLUNK_HOME/bin/splunk btool server list postgres --debug to see whether the sidecar is enabled and which file sets it.
• On each cluster member, check what listens on the Patroni port (ss -ltnp | grep 8008) and whether it is reachable from outside the cluster.
• Search firewall or flow logs for connections to the Patroni port from hosts that are not search head cluster members.
• Look for unexpected child processes of the PostgreSQL or Patroni sidecar running as the Splunk service account.

What happened#

On October 7, 2026, Splunk published SVD-2026-1001, its September/October roll-up for Splunk Enterprise. The headline flaw is CVE-2026-76268 (CVSS 3.1 9.8). It sits in the Patroni REST API that Splunk ships as part of its PostgreSQL sidecar. Patroni manages high availability for the bundled PostgreSQL. Splunk says that on a search head cluster member, "an unauthenticated user with network access to the Patroni ... REST API ... could execute attacker-controlled operating-system commands," because the interface "does not require authentication for critical configuration operations." The bug was credited to Gabriel Nitu of Splunk and Ofir Alkoby of a.security.

The same day, Splunk's internal hardening advisory SVD-2026-1002 listed grouped CVEs scored up to 9.8, without per-bug detail. Two weeks later, on October 21, a second round followed. SVD-2026-1007 includes CVE-2026-76298 (8.8), another flaw in the same sidecar: a user without the admin or power role could "derive the PostgreSQL sidecar database superuser password" from the search head cluster identifier shown in search job logs, then run OS commands. SVD-2026-1008 adds hardening fixes scored up to 9.9.

Who is affected#

CVE-2026-76268 affects Splunk Enterprise 10.4.0 to 10.4.2 and 10.2.0 to 10.2.6, and only search head cluster members. Splunk states that 10.0.x and 9.4.x are not affected. Splunk's sidecar documentation says the [postgres] sidecar is on by default in Splunk Enterprise and off in Splunk Cloud Platform. Its example port map puts Patroni on 8008, next to PostgreSQL on 5432 to 5434 and etcd on 2379 and 2380.

CVE-2026-76298 affects releases below 10.4.4 and 10.2.8, again on search head cluster members, and it needs a low-privileged Splunk login.

Do you really need to act?#

If you run a 10.2 or 10.4 search head cluster, yes, this week. An unauthenticated network bug that runs commands as the Splunk service account is as bad as it gets for a SIEM. On a SIEM search head, that account usually has access to stored credentials, cloud API keys and the logs an intruder would most like to erase. This is also the second time in 2026 that this sidecar has caused trouble: the June PostgreSQL sidecar flaw, CVE-2026-20253, was exploited in the wild and added to CISA's KEV catalog.

Three things narrow the exposure. The bug needs network access to the Patroni port, not to Splunk Web, and cluster ports are often reachable only from inside the cluster network. Single search heads and older branches are out of scope. And no exploitation has been reported: CVE-2026-76268 is not in KEV as of October 25. Still, the work is public enough that Singapore's CSA issued an alert on October 16, and Pentest-Tools.com added a network detection the same day. Treat "flat internal network plus a 10.2 or 10.4 cluster" as urgent.

What to do now#

1. Inventory versions with $SPLUNK_HOME/bin/splunk version on every search head, and note which ones are cluster members.
2. Upgrade to the October 21 releases rather than the October 7 ones: 10.4.4, 10.2.8, 10.0.11 or 9.4.16. Those cover CVE-2026-76268, CVE-2026-76298 and both hardening rounds.
3. If you can't upgrade yet and don't use Edge Processor, OpAmp or SPL2 data pipelines, disable the sidecar by adding [postgres] with disabled = true to $SPLUNK_HOME/etc/system/local/server.conf, then restart. Splunk says core search, indexing and dashboards keep working, but the features above break.
4. Restrict the sidecar ports with host or network firewalls so that only other cluster members can reach them.
5. For Linux package upgrades, note CVE-2026-76266 (7.7): a local user who can act as the Splunk account can get root during a Linux package upgrade. Splunk's workaround is to upgrade with the tar package.

How to tell if you were hit#

Start with exposure. splunk btool server list postgres --debug shows whether the sidecar is enabled, and ss -ltnp | grep 8008 on each member shows whether Patroni is listening and on which address. Then check firewall or flow logs for connections to that port from anything other than cluster peers. On the hosts, look for shells, downloaders or other unexpected processes spawned under the PostgreSQL or Patroni sidecar as the Splunk user, plus unexpected changes to the sidecar's configuration. Splunk has not published indicators for this bug.

Timeline#

• Oct 7, 2026 — Splunk publishes SVD-2026-1001 and SVD-2026-1002 with Splunk Enterprise 10.4.3, 10.2.7, 10.0.10 and 9.4.15.
• Oct 14, 2026 — Splunk gives advance notice of an October 21 release.
• Oct 16, 2026 — Singapore's CSA issues alert AL-2026-145, and a commercial scanner adds a detection.
• Oct 21, 2026 — Splunk publishes SVD-2026-1007 (including CVE-2026-76298) and SVD-2026-1008 with 10.4.4, 10.2.8, 10.0.11 and 9.4.16.
• Oct 25, 2026 — No in-the-wild exploitation reported, and the CVE is not in KEV.

Vulnerability records

• CVE-2026-76268 · In Splunk Enterprise versions below 10.4.3 and 10.2.7, an unauthenticated user with network access to the Patroni Representational State Transfer (REST)…
• CVE-2026-76298 · In Splunk Enterprise versions below 10.4.4 and 10.2.8, a user who does not hold the "admin" or "power" Splunk roles could derive the PostgreSQL sidecar…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Splunk — SVD-2026-1001: Security Vulnerabilities in Splunk Enterprise, September/October 2026 advisory.splunk.com
2. Splunk — SVD-2026-1007: Security Vulnerabilities in Splunk Enterprise, October 2026 advisory.splunk.com
3. Splunk — SVD-2026-1002: Security Hardening in Splunk Enterprise, September/October 2026 advisory.splunk.com
4. Splunk — SVD-2026-1008: Security Hardening in Splunk Enterprise, October 2026 advisory.splunk.com
5. CVE record — CVE-2026-76268 cve.org
6. Splunk Docs — Sidecar configuration settings help.splunk.com
7. Cyber Security Agency of Singapore — AL-2026-145: Critical Vulnerabilities in Splunk Enterprise csa.gov.sg
8. Pentest-Tools.com — Splunk Enterprise Patroni REST API Missing Authentication RCE (CVE-2026-76268) pentest-tools.com