Splunk Enterprise Patroni REST API (search head clusters)
CVE-2026-76268: Unauthenticated command execution in Splunk Enterprise Patroni API
The Patroni REST API on Splunk Enterprise search head cluster members needs no authentication and lets a network attacker run OS commands (CVSS 9.8). No exploitation has been reported and no public exploit code is confirmed.
Published Updated Splunk advisory SVD-2026-1001
Affected and fixed versions
| Product / branch | Fixed in |
|---|---|
| Splunk Enterprise 10.4.0 to 10.4.2 | 10.4.3 or later |
| Splunk Enterprise 10.2.0 to 10.2.6 | 10.2.7 or later |
| Splunk Enterprise 10.0.x and 9.4.x | Not affected, per the Splunk advisory |
Always confirm against the vendor advisory, which lists every fixed hotfix.
What it is
Splunk Enterprise runs a PostgreSQL sidecar, and on search head cluster members the Patroni REST API is part of that setup. On the affected versions, the API does not require authentication for critical configuration operations (CWE-306). An attacker who can reach it over the network can run operating-system commands on the host. No account and no user interaction are needed.
Splunk rates it 9.8 (critical). Splunk’s advisory doesn’t say whether anyone has exploited it, and the CVE record’s CISA assessment (October 8) lists exploitation as “none” but the attack as automatable. The bug is not in CISA’s KEV catalog as of the 2026-10-16 copy. EPSS was 1.6% (75th percentile) on October 16. We found no confirmed public exploit code. The finder was Gabriel Nitu of Splunk, so the bug was found internally.
Am I affected?
You are affected if you run Splunk Enterprise 10.4.0 to 10.4.2 or 10.2.0 to 10.2.6 and the host is a search head cluster member whose Patroni REST API is reachable by an attacker.
- Splunk says 10.0.x and 9.4.x are not affected. The CVE record’s solution section nevertheless lists 10.0.10 and 9.4.15 as upgrade targets. Treat the advisory as authoritative, and ask Splunk if you run those branches and want certainty.
- The advisory gives no command or menu path to check exposure. Confirm your version, whether you run a search head cluster, and whether the PostgreSQL sidecar is enabled in
server.conf([postgres]stanza).
What to do
-
Upgrade to Splunk Enterprise 10.4.3 or 10.2.7 or later. The advisory lists no extra configuration steps beyond upgrading.
-
If you can’t upgrade tonight and don’t use Edge Processor, OpAmp or SPL2 data pipelines, disable the PostgreSQL sidecar. Edit
$SPLUNK_HOME/etc/system/local/server.conf, set this, then restart Splunk Enterprise:[postgres] disabled = trueSplunk warns that Edge Processor, OpAmp and SPL2 data pipelines depend on the sidecar, so they stop working.
-
Limit network access to search head cluster members to the hosts that need it, until you have patched. This is general hardening, not a vendor instruction.
-
If a cluster member was reachable by untrusted networks while vulnerable, review it for signs of compromise (below) and treat unexplained findings as a host compromise.
Detection
Neither Splunk nor other sources we opened publish exploitation indicators or log signatures for this bug. Reasonable starting points, which are our suggestions rather than vendor guidance:
- Connections to the Patroni REST API on search head cluster members from hosts that aren’t cluster members.
- Unexpected child processes of the Splunk or PostgreSQL sidecar processes, and new files or accounts on those hosts.
- Outbound connections from search head cluster members to unfamiliar addresses.
Indicators of compromise
Checked the Splunk advisory, the CVE record and a general web search. No indicators of compromise have been published.
No indicators of compromise have been published for this CVE yet. We'll add them here if the vendor or a researcher releases any. Until then, use the behaviour in Detection.
Sources
Page changelog
- Full analysis published.
KEV status, EPSS score and vendor data refreshed automatically, last on 18 Oct 2026.