Splunk has disclosed CVE-2026-76268, affecting Splunk Enterprise versions below 10.4.3 and 10.2.7. An unauthenticated attacker with network access to the Patroni REST API on a search head cluster member can execute operating-system commands of their choosing. Versions 10.0.x and 9.4.x are not affected.

Here's what bothers me about this one: the Patroni API is exposed without authentication for what the advisory calls "critical configuration operations". That's not a misconfiguration you introduced. That's a design choice baked into the product. Your perimeter controls and network segmentation are the only things standing between an attacker and OS-level command execution on a node that, in most environments, has access to sensitive log and security data.

From an IAM standpoint, this is a textbook service-account and API authentication failure. Any API that accepts configuration changes should require a credential, full stop. No exceptions for "internal" interfaces. In my experience, "internal" APIs like this are exactly where attackers pivot once they're past the edge. The Patroni interface apparently never got that memo. Your detection tooling probably didn't know to watch it either, because nobody expected it to be an attack surface.

Splunk search head clusters are not fringe deployments. They're common in mid-to-large enterprises running SIEM workloads, which means the blast radius here can be significant. If an attacker executes OS commands on a search head, they can tamper with log ingestion, cover tracks, or use the node as a launchpad. The access Splunk has to the rest of your environment makes this worse than a random application compromise.

If you're running an affected version, patch to 10.4.3 or 10.2.7 immediately. While you're scheduling that maintenance window, check whether your Patroni API port is reachable from anything beyond the cluster's own nodes. Network segmentation won't fix the vuln, but it reduces your exposure window before the patch lands. After patching, pull access logs for the Patroni endpoint and look for any unexpected calls. If you can't get those logs, that's a separate problem worth addressing.