How a Database Cluster Manager's REST API Becomes a Command-Execution Path

High-availability database managers exist to do dangerous things on purpose. They promote replicas, demote primaries, rewrite the database's configuration, restart it and, when a replica is beyond repair, wipe its data directory and rebuild it from the leader. Every one of those operations is exposed through an HTTP API so that other cluster members, command-line tools and load balancers can drive them. That API is the single most powerful interface on the host, and in several popular managers it ships with authentication switched off.

Splunk's CVE-2026-76268, disclosed on 7 October 2026, is the current example. Splunk Enterprise 10.2 and 10.4 bundle 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. to manage a PostgreSQL sidecar on 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. members, and the Patroni REST API was reachable without credentials. Splunk rated the result 9.8 and described it as unauthenticated execution of attacker-controlled operating-system commands. This article explains the general shape of the problem using Patroni's own documentation, because the same shape appears in other cluster managers, orchestration agents and service-mesh control planes.

What a cluster manager's API is for

Patroni's documentation lists four consumers of its REST API: Patroni itself during the leader race, the patronictl tool for failovers and restarts, load balancers such as HAProxy doing HTTP health checks, and monitoring systems. Three of those four are machines, not people, and two of them are other nodes in the cluster. The API therefore has to be reachable across the network from every cluster member. The documentation says so directly: the connect_address must not be a loopback address unless the setup is a demo on localhost.

That requirement is the root of the exposure. A management interface that only ever needed to be called from the same host could bind to loopback and inherit the host's access controls. A cluster API has to listen on a routable address, so the only things standing between a remote caller and a failover are the authentication and network rules the operator added afterwards.

Safe endpoints and unsafe endpoints

Patroni divides its API into two classes. Safe endpoints are GET requests that only retrieve information: health checks like /primary, /replica and /health, the /patroni status document, /cluster topology, /history and /metrics. Unsafe endpoints are the PUT, POST, PATCH and DELETE requests that change the state of nodes.

The unsafe set is where command-execution paths live. PATCH /config and PUT /config change the cluster's dynamic configuration, including any entry under postgresql.parameters. Those parameters are passed to PostgreSQL itself, and the Patroni documentation shows the pending_restart flag being raised when a change needs a restart. POST /restart restarts PostgreSQL on a node, optionally on a schedule. POST /reload makes Patroni re-read its configuration file. POST /switchover and POST /failover change which node is the primary; the docs warn that failover "can cause data loss in certain situations." POST /reinitialize removes a replica's data directory and runs pg_basebackup or an alternative replica-creation method to rebuild it.

Read that list as an attacker would. Configuration control over a database engine, control over when and how the engine restarts, control over which host is primary, and the ability to delete a node's data and replace it from a source of the attacker's choosing. Splunk did not publish the exact step that turns Patroni configuration access into operating-system commands, and this article will not guess at it. The point is that the unsafe endpoint set is designed to reach deep into the host, so a missing authentication check on any of them is a critical bug by construction, not an information leak that happens to be rated high.

Authentication is optional, and off by default

Patroni's configuration reference makes every protection opt-in. The restapi.authentication block accepts a basic-auth username and password that "protect unsafe REST API endpoints." If it is absent, unsafe endpoints accept any caller. TLS is enabled only if certfile is set; the docs say that without it "the API server will work without SSL." Client-certificate checking is governed by verify_client, whose default is none; the optional setting checks certificates only on unsafe methods, and required checks them on every call. An allowlist of hosts or CIDR ranges can restrict who may call unsafe endpoints, but the documented default is "allow all."

Patroni's security page adds a detail that matters for anyone planning compensating controls: there is "no way to protect the safe endpoints without enabling TLS." The read-only endpoints leak topology, replication state, the primary's address and the cluster name to anyone who can reach the port. Basic auth does nothing for them. Only mutual TLS with verify_client set to required closes the whole API.

None of this is a criticism of Patroni's design. The project documents the risk and the knobs clearly. The failure mode is downstream: a vendor embeds the manager into a larger product, chooses defaults for its own convenience, and the administrator of the larger product never sees the Patroni configuration at all. Splunk's sidecar documentation does not mention Patroni authentication, and Splunk's own fix for CVE-2026-76268 was a product upgrade, not a configuration change customers could have made themselves.

Why the host boundary disappears

A database cluster manager runs as a privileged local agent. It has to start and stop the database process, write its configuration files, create and delete data directories, and run replica-creation scripts. The Patroni documentation describes create_replica_methods as an ordered list of methods where anything other than basebackup "is assumed to refer to scripts." Whatever user the manager runs as, that user can do all of those things, and that is the floor for what a caller of an unauthenticated unsafe endpoint can do too.

That is the general lesson. When an API's legitimate purpose includes "run this script" or "apply this configuration to a process on the host," the distinction between configuration access and code execution is a formality. The CVSS vector for CVE-2026-76268 reflects it: network, low complexity, no privileges, no user interaction, high impact on confidentiality, integrity and availability.

What to do about managers you did not deploy

Start by finding them. The Splunk case is instructive because the sidecar is on by default on Splunk Enterprise, bundles Patroni, pgbouncer and etcd, and assigns them ephemeral ports unless an administrator pins them. How to Find and Fence the Helper Ports a Product Opens Beside Its Main Service is the inventory and isolation process; it applies to any product that spawns helper daemons.

Then decide what the exposure is worth. On a search head cluster, the host running the manager is also the host holding your SIEM's stored credentials and search history, which is why 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 argues for patching on the identity-tier clock. For a manager you deployed yourself, enable basic auth on the unsafe endpoints as a minimum, set an allowlist of cluster members, and use mutual TLS where the safe endpoints also need protecting. For a manager a vendor embedded, you usually cannot change its configuration without voiding support, so the controls are the product upgrade, the vendor's workaround, and the network.