Splunk CVE-2026-76268: Default-On Patroni Sidecar Takes OS Commands With No Login

Splunk's October advisory batch carries a 9.8 that most Splunk Enterprise shops will not recognise by name. CVE-2026-76268 is not in the splunkd REST API or Splunk Web. It is in PatroniPatroni🛡️An open-source high-availability manager for PostgreSQL that handles leader election, failover, replica creation and dynamic configuration, driven through a REST API. The API's state-changing endpoints are unauthenticated unless basic auth, client certificates or an allowlist are configured., an open-source PostgreSQL high-availability manager that Splunk bundles inside its "Storage" sidecar, and on a search head clusterSearch Head Cluster🛡️A group of Splunk search heads that replicate configuration and knowledge objects among themselves so any member can serve users and the group survives a node failure. Members communicate over several management interfaces, which widens each node's attack surface relative to a standalone search head. member that sidecar's REST API answers to anyone with network reach and no credentials at all.

What Happened

On 7 October 2026 Splunk published two advisories. SVD-2026-1001 lists 17 individually described CVEs in Splunk Enterprise and bundled apps; SVD-2026-1002 is a "security hardening" release that groups internally found bugs into five CVE IDs by weakness class, the highest of which (CVE-2026-76281, improper access control) also scores 9.8. The fix for everything in both advisories is the same set of releases: 10.4.3, 10.2.7, 10.0.10 and 9.4.15.

The headline bug is CVE-2026-76268, CWE-306 (Missing Authentication for Critical Function), CVSS 3.1 9.8 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Splunk's description is short: an unauthenticated user with network access to the Patroni REST API on a search head cluster member could execute attacker-controlled operating-system commands, because the interface "does not require authentication for critical configuration operations." The finding is credited to Gabriel Nitu of Splunk, so this was found internally rather than reported from the field. NVD published the record the same evening through Cisco's PSIRT, Splunk's parent CNA.

Splunk does not report exploitation, and as of catalog version 2026.10.04 the CVE is not in CISA's Known Exploited Vulnerabilities list. No public proof of concept has surfaced in the coverage so far. One aggregator quoted a score range of 9.1 to 9.8 "depending on the reference source"; the vendor advisory and NVD both say 9.8, and that is the number to use.

Who Is Affected

Only the two newest branches carry the bug: Splunk Enterprise 10.4.0 through 10.4.2 (fixed in 10.4.3) and 10.2.0 through 10.2.6 (fixed in 10.2.7). Splunk states that 10.0.x and 9.4.x are not affected by CVE-2026-76268, although both branches still need 10.0.10 and 9.4.15 for the rest of the batch.

Two conditions narrow the exposure further. The vulnerable interface lives on search head cluster members, so standalone search heads and indexers are outside the advisory's wording. And the Storage sidecar has to be running. Splunk's sidecar documentation says it is activated by default on Splunk Enterprise (disabled = false in the [postgres] stanza of server.conf) and deactivated by default on Splunk Cloud Platform. In practice that means a 10.2 or 10.4 search head cluster on Linux is running Patroni whether or not you have ever touched Edge Processor, OpAmp or SPL2 pipelines, the features the sidecar exists to support.

Technical Analysis

Splunk's sidecar model is the context that makes this bug matter. Sidecars are long-running processes started beside splunkd by a supervisor process, listed in a manifest file and restarted automatically if they die. The documentation warns that they "can occupy network ports," that they show up as subprocesses of splunkd in the process tree, and that endpoint security tools "might fire alerts" because of them. It also notes that if splunkd is killed, the supervisor and sidecars might keep running.

The Storage sidecar (process name "postgres", PostgreSQL 17.7, Linux only) is not just a database. Splunk's port-allocation example for it reserves addresses for the Postgres primary and replica listeners, a pgbouncer connection pooler, a "postgres_nanny" service and Patroni itself, with etcd peer and client ports handled by a separate Nascent sidecar. That is a complete HA database stack, and Patroni is its control plane.

Patroni's own documentation explains why its REST API is dangerous without authentication. The project divides the API into "safe" endpoints (GET requests that only read state) and "unsafe" endpoints (PUT, POST, PATCH and DELETE that change the state of nodes). The unsafe set includes PATCH and PUT on /config, which rewrite the cluster's dynamic configuration including arbitrary PostgreSQL parameters, plus POST /restart, POST /reload, POST /switchover, POST /failover and POST /reinitialize, the last of which deletes a replica's data directory and rebuilds it. Authentication for the unsafe endpoints is optional: HTTP basic auth via restapi.authentication, TLS client certificates via verify_client (default: none), or an allowlist of callers (default: allow all). Patroni's security page is blunt that unsafe endpoints "can be protected" with basic auth, not that they are.

Splunk has not said which operation yields command execution, and the advisory language, "critical configuration operations," suggests the path runs through configuration rather than a memory-safety bug. Treat the mechanism as unknown. What is known is that a management API designed to be reached by other cluster members and load balancers was shipped reachable with no credential check, on a product whose job is to hold every other system's logs. The pattern is the subject of How a Database Cluster Manager's REST API Becomes a Command-Execution Path.

One more detail affects your firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. rules. Splunk's IPC Broker assigns each sidecar service a random port from the kernel's ephemeral range unless an administrator pins it in the [ipc_broker] stanza of server.conf. Splunk's example pins Patroni to 8008, pgbouncer to 6432 and etcd to 2379 and 2380, but the default is "random available port." If you have never pinned them, the Patroni listener on your search heads is on a port you probably do not know.

Immediate Actions

Upgrade search head cluster members on 10.4 and 10.2 to 10.4.3 or 10.2.7. That is the only complete fix.

If you cannot upgrade immediately, Splunk's workaround is to turn the Storage sidecar off: set disabled = true in the [postgres] stanza of $SPLUNK_HOME/etc/system/local/server.conf and restart Splunk Enterprise. Splunk conditions this on not using Edge Processor, OpAmp or SPL2 data pipelines, which the sidecar supports. Follow the documented practice of creating the setting in a local directory rather than editing files under default.

Independently of the patch, restrict network access to search head cluster members so that only other cluster members, the deployer and administrative hosts can reach them. Because sidecar ports float by default, do this at the host and segment level rather than per port, or pin the ports first. Splunk's documentation shows how to check the ephemeral range with sysctl net.ipv4.ip_local_port_range. The broader method is in How to Find and Fence the Helper Ports a Product Opens Beside Its Main Service, and if you have not yet confirmed whether a search head is reachable from outside, start with How to Find Which of Your Admin Consoles Are Reachable From the Internet.

Then work through the rest of the batch, because an upgrade alone does not close four of the CVEs. CVE-2026-76264 needs scripted_lookup_raw_write_enforcement = block under [lookup] in limits.conf after upgrading. CVE-2026-76265, CVE-2026-76272 and CVE-2026-76280 all require the Splunk Secure Gateway app to be upgraded separately to 3.10.11, 3.9.25 or 3.8.72. CVE-2026-76266 (7.7) lets a local user who can run commands as the Splunk account turn a later Linux package upgrade into root; Splunk's mitigation is to upgrade from a tar file instead. CVE-2026-76274 is an SSRF in the Splunk App for Splunk Observability Cloud that discloses the configured Observability Cloud API token, and CVE-2026-76269 and CVE-2026-76275 let a low-privileged user read other users' search jobs, including query text and results.

Long-Term Outlook

The Patroni bug was found in-house and fixed before anyone reported attacks, which is the good version of this story. The structural lesson is less comfortable. Splunk Enterprise now ships a supervisor, a database, a connection pooler, a cluster manager and an etcd store as subprocesses that most administrators never configured, with ports that move between restarts. Any one of them can carry a pre-auth bug, and the first time many teams will learn a component exists is when it appears in an advisory. If a vendor-bundled service exposes a listener you cannot configure authentication for, How to Put Authentication in Front of a Service That Ships Without It covers the options.

A SIEM is also not an ordinary application server. An attacker running commands on a search head has the credentials stored for every input, the search history of your security team, and the ability to delete or suppress the evidence of their own activity. Why Your SIEM Is a Tier-0 AssetTier-0 Asset🛡️A system whose compromise gives an attacker control over the identities or infrastructure of every other tier, such as domain controllers, identity providers and, by the same test, a SIEM holding stored credentials. Tier-0 assets get the strictest administrative access rules and the fastest patch window.: What an Attacker Gets From One Search Head makes the case for patching Splunk on the same clock as domain controllers, not on the application-tier schedule.

Sources

• Splunk advisory SVD-2026-1001, Security Vulnerabilities in Splunk Enterprise, September/October 2026: https://advisory.splunk.com/advisories/SVD-2026-1001
• Splunk advisory SVD-2026-1002, Security Hardening in Splunk Enterprise, September/October 2026: https://advisory.splunk.com/advisories/SVD-2026-1002
• NVD record for CVE-2026-76268 (via the NVD API, published 2026-10-07): https://nvd.nist.gov/vuln/detail/CVE-2026-76268
• Splunk documentation, Sidecar configuration settings (10.4): https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.4/splunk-sidecars/sidecar-configuration-settings
• Splunk documentation, About Splunk sidecars (10.4): https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.4/splunk-sidecars/about-splunk-sidecars
• Patroni documentation, REST API: https://patroni.readthedocs.io/en/latest/rest_api.html
• Patroni documentation, Security Considerations and YAML configuration (restapi section): https://patroni.readthedocs.io/en/latest/security.html
• CISA Known Exploited Vulnerabilities feed (catalog 2026.10.04, CVE absent): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• SecurityOnline, Splunk Patches 22 Flaws in Splunk Enterprise (Do Son, 2026-10-08): https://securityonline.info/splunk-enterprise-vulnerabilities-october-2026/
• Cyber Security News, Splunk Patches Critical 9.8 Flaw: https://cybersecuritynews.com/splunk-patches-critical-flaw/