Splunk's Patroni REST API Runs Operating-System Commands Without a Login

TL;DR

• Splunk Enterprise is a platform companies install on their own servers to collect, search and alert on machine data, and Patroni is the PostgreSQL high-availability manager Splunk ships as a sidecar beside the search heads that run its newer data pipelines.
• Advisory SVD-2026-1001, published on 7 October 2026, lists 17 CVEs in one maintenance release of Splunk Enterprise, with a highest severity of 9.8 Critical.
• The critical entry, CVE-2026-76268, is a missing authentication check in the Patroni REST API on a search head cluster member: a request that reaches that interface executes attacker-controlled operating-system commands.
• Two branches carry the flaw, 10.4 up to 10.4.2 and 10.2 up to 10.2.6, while Splunk records no exposure to it on the 10.0 and 9.4 branches.
• The mitigation Splunk publishes fits operators who leave Edge Processor, OpAmp and SPL2 pipelines unused, and the cases where it applies are stated alongside the stanza to edit.
• Four other fixes in the same release need steps beyond the upgrade, including a gateway app that carries its own version number.
• The wider exposure pattern is a management interface that trusts the network around it, and the checks a team can run before the upgrade window are the same ones that answer an inventory question.

What the Patroni interface does on a search head cluster

A search head cluster is a group of Splunk Enterprise search heads that serves as a central resource for searching, in Splunk's own description of the architecture. The members share configurations, job scheduling and search artifacts, one member holds the captain role and coordinates scheduling and replication, and the role can move between members over time. A working cluster also needs a deployer to distribute apps and configuration, search peers as the indexers that searches run across, and optionally a load balancer in front of the members.

Patroni sits in this picture as a sidecar. Splunk's documentation describes sidecars as components configured through stanzas in configuration files, with some activated by default, and it lists a postgres sidecar whose process name is postgres and whose settings live in the [postgres] stanza of server.conf. The default on Splunk Enterprise is disabled = false, which means the component runs out of the box on the versions that ship it.

The branches that carry the missing authentication

CVE-2026-76268 is titled Missing Authentication for Critical Function in the Patroni REST API, and the description states the consequence directly: an unauthenticated user with network access to that interface on a search head cluster member can execute attacker-controlled operating-system commands. The reason given is that the interface does not require authentication for critical configuration operations. Splunk rates it 9.8 Critical under CWE-306, and the National Vulnerability Database records the vector as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, where no privileges and no user interaction appear in the path.

The version arithmetic deserves a second look, because it inverts a familiar habit. Plenty of advisories punish teams for running old code. Here the two newest maintained branches carry the flaw and the older ones do not, with Splunk stating that versions 10.0.x and 9.4.x are not affected by this specific CVE. A team still on 10.0 or 9.4 holds a genuine answer for the critical item, and it still has to handle the rest of the release: 10.0.10 and 9.4.15 exist because other entries in the same advisory apply to them.

What the same advisory release fixes alongside the critical flaw

The advisory bundles 17 CVEs, and the critical one shares a release with a spread of medium and high entries. A local privilege escalation through package upgrades is rated 7.7, a search job retrieval issue and an SQL injection in the SPL2 module catalog sit at 6.5, and several REST API entries land between 4.1 and 4.3, covering authorization checks, input validation and information disclosure.

Four of the entries need something past the upgrade, and Splunk names them in the solutions section. CVE-2026-76264, an authorization gap that lets a user without the admin or power role save scripted lookup settings through raw configuration endpoints, needs one setting after the upgrade: scripted_lookup_raw_write_enforcement = block under [lookup] in limits.conf, followed by a restart. CVE-2026-76265, CVE-2026-76272 and CVE-2026-76280 relate to Splunk Secure Gateway, whose own patched versions are 3.10.11, 3.9.25 and 3.8.72. Operators who cannot upgrade the app can turn it off or remove it, with the caveat that Splunk Mobile, Spacebridge and Mission Control rely on it.

The mitigation Splunk publishes and the cases where it applies

The advisory documents one workaround for the critical item. Turn off the PostgreSQL sidecar by setting disabled = true in the [postgres] stanza of $SPLUNK_HOME/etc/system/local/server.conf, then restart Splunk Enterprise to apply the change. The condition attached to that instruction matters: it fits operators who leave Edge Processor, OpAmp and SPL2 data pipelines unused. A team that depends on those pipelines has to take the upgrade instead, because the workaround removes the feature those pipelines sit on.

![Capture of Splunk's documentation page "Sidecar configuration settings", listing the postgres sidecar with its process name, its [postgres] stanza in server.conf and its default disabled = false setting on Splunk Enterprise.](assets/2026-10-11/splunk-patroni/vendor/splunk-docs-sidecar-configuration.png) Capture of Splunk's documentation page "Sidecar configuration settings" (help.splunk.com, Splunk Enterprise admin manual, retrieved 2026-10-11): the sidecar table that the advisory's mitigation points to, with the [postgres] stanza and its default setting.

Both routes converge on the same internal question. Which processes on this estate answer configuration requests over a network, and who can reach them? The Patroni interface carries the highest rating in this release, and the same review covers authentication brokers and other sidecars listed on the page Splunk points to, each with its own port allocation and default state.

Checks a team can run before the upgrade window

Start with the version spreadsheet, because the branch answer changes what the critical item requires of each host. Confirm the exact build on every search head cluster member, then confirm whether the PostgreSQL sidecar runs at all and whether the pipelines that depend on it carry live use.

• Read the current value of the [postgres] stanza in server.conf on each member, and note whether enable_clustered_mode sits at its default. The same stanza covers single search heads.
• Confirm that the Patroni interface is unreachable from anything outside the cluster network, and record which hosts and load balancers can reach the search head members.
• Check the Splunk Secure Gateway app version against 3.10.11, 3.9.25 and 3.8.72, since four of the CVEs in this release live there.
• Plan the restart the mitigation requires, so it lands inside a maintenance window with the pipeline owners present.

Those four steps are cheap next to the alternative. The pattern behind the critical item has appeared repeatedly through this year, from an inferencing cache that opened an unauthenticated transport socket to a search platform that answers configuration requests from the network, and our note on the LMCache remote-code-execution flaw works through the first of those cases.

Where the exposure pattern repeats in infrastructure

The advisory describes a component that runs by default, allocates a port, and accepts configuration operations from anyone who can reach it. Reachability decides who gets in, which is why a network position ends up carrying the authority of an administrator. That arrangement predates this CVE and continues past it, and it is the reason the fixed image is worth more than the fixed number: an inventory of management interfaces, their defaults and their reachability keeps paying out when the next advisory arrives, and the five legacy flaws CISA listed in October make the same point from the other direction.

Netics runs monitoring and alerting for infrastructure estates, and the first deliverable in that work is a picture of what exposes which interface to whom. Advisory SVD-2026-1001 adds one more entry to that picture, with a 9.8 rating attached to an interface whose only defence was a network boundary.

Sources

Source: Security Vulnerabilities in Splunk Enterprise - September/October 2026, advisory SVD-2026-1001 — advisory.splunk.com/advisories/SVD-2026-1001, Splunk, published 2026-10-07, retrieved 2026-10-11 (17 CVEs in one release with a highest CVSSv3.1 score of 9.8 Critical; fixed versions 10.4.3, 10.2.7, 10.0.10 and 9.4.15; CVE-2026-76268 Missing Authentication for Critical Function in the Patroni REST API with unauthenticated operating-system command execution on a search head cluster member and CWE-306; 10.0.x and 9.4.x recorded as not affected; the mitigation disabling the PostgreSQL sidecar with disabled = true in the [postgres] stanza of server.conf where Edge Processor, OpAmp and SPL2 data pipelines are unused, followed by a restart; CVE-2026-76264 needing scripted_lookup_raw_write_enforcement = block in limits.conf after the upgrade; CVE-2026-76265, CVE-2026-76272 and CVE-2026-76280 needing Splunk Secure Gateway versions 3.10.11, 3.9.25 and 3.8.72, with removal of the app as an option and Splunk Mobile, Spacebridge and Mission Control as its dependants; CVE-2026-76266 at 7.7 for local privilege escalation through Linux package upgrades; the medium entries covering search job retrieval, SPL2 module catalog injection, authorization, input validation and information disclosure).

Source: CVE-2026-76268 — services.nvd.nist.gov, National Vulnerability Database record, published 2026-10-07, last modified 2026-10-09, retrieved 2026-10-11 (CVSS 3.1 base score 9.8 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-306, the statement that Splunk Enterprise versions 10.0.x and 9.4.x are not affected, and Cisco PSIRT as the CNA of record).

Source: Search head clustering architecture — help.splunk.com, Splunk Enterprise documentation, last updated 2026-08-25, retrieved 2026-10-11 (a search head cluster as a group of Splunk Enterprise search heads serving as a central resource for searching; members sharing configurations, job scheduling and search artifacts; the captain role coordinating job scheduling and replication and shifting between members; the deployer, search peers and an optional load balancer as the surrounding components).

Source: Sidecar configuration settings — help.splunk.com, Splunk Enterprise admin manual, last updated 2026-08-06, retrieved 2026-10-11 (sidecars configured through stanzas in configuration files with some activated by default; the postgres sidecar, its process name, its [postgres] stanza in server.conf, disabled = false as the default on Splunk Enterprise and disabled = true on Splunk Cloud Platform; enable_clustered_mode set to false for sidecars on single search heads).

Source: Splunk — advisory SVD-2026-1001 and the Splunk Enterprise documentation, published 7 October 2026, retrieved 2026-10-11. Figures from the advisory and the documentation pages; images are captures of Splunk's own pages plus two Netics editorial diagrams.