Splunk SHC Patroni RCE (CVE-2026-76268): Unauthenticated Sidecar REST and archive_command

When “internal” database ports face the internet

CVE-2026-76268 is not a Splunk Web login bypass or a splunkd REST trick. It lives on the PostgreSQL sidecar that ships with Splunk Enterprise 10.x search head clusters (SHC): the Patroni REST API that orchestrates the embedded database. On vulnerable builds, that API accepts state-changing HTTP without authentication—so anyone who can reach the listener can push dynamic PostgreSQL configuration and eventually run operating-system commands through parameters such as archive_command.

Splunk documents this class of issue under SVD-2026-1001. Public PoC: CVE-2026-76268 on pocbit.org. Repository: murrez/CVE-2026-76268.

| | | |---|---| | Affected | 10.2.0 – 10.2.6, 10.4.0 – 10.4.2 | | Fixed | 10.2.7, 10.4.3 (and later) | | Not in scope (this CVE) | 10.0.x, 9.4.x without this sidecar stack | | CWE | CWE-306 — missing authentication on a critical function | | CVSS 3.1 | 9.8 Critical | | Verify marker | POCBIT-76268-OK (OOB callback or lab file) |

Attack surface in one sentence

The PoC talks directly to Patroni—commonly TCP 8008, sometimes another port assigned by Splunk’s IPC Broker—using PATCH /config and POST /restart. It does not require Splunk management port 8089 or the UI on 8000. That separation matters for firewall rules: blocking “Splunk” on 8000 does not protect a mis-exposed Patroni port.

Typical chain:

1. Discover Patroni (GET /patroni JSON with role, state).
2. Confirm unauthenticated PATCH /config (check mode).
3. Inject wal_level, archive_mode, archive_timeout, and a malicious archive_command.
4. Restart PostgreSQL via Patroni; wait for WAL archive cycle so the command runs.

Real impact requires the host to be an SHC member with [postgres] sidecar enabled and Patroni reachable from the attacker’s network—often a segmentation mistake, not a missing Splunk password.

Why defenders miss it

| Blind spot | Reality | |------------|---------| | “We patched Splunk UI CVEs” | Sidecar Patroni is a separate listener | | “8008 is random” | IPC Broker may pin 8008 in server.conf; docs list it for member-to-member traffic | | “Patroni is Postgres HA—must be ours” | Other products run Patroni; correlate Splunk version + SHC role before incident declaration | | “Exploit succeeded in lab” | Vendor may lock parameters in local config on hardened builds—patch version still mandatory |

Cross-read: reading vendor security advisories, how to prioritize critical CVEs, incident response first 24 hours.

Defender checklist

| # | Action | Detail | |---|--------|--------| | 1 | Version inventory | SHC members on 10.2.x or 10.4.x in the affected ranges | | 2 | Upgrade | 10.2.7+ or 10.4.3+ per SVD-2026-1001 | | 3 | Sidecar not needed? | [postgres] disabled = true in server.conf, restart—only if you do not use Edge Processor / OpAmp / SPL2 pipelines that require it | | 4 | Network | Patroni + etcd (2379/2380) SHC peers only—never WAN | | 5 | Find the port | On-server: $SPLUNK_HOME/bin/splunk btool server list ipc_broker --debug | | 6 | Validate | Authorized --mode check from a jump host; no exploit on production without change window | | 7 | Monitor | Unexpected PATCH/POST to Patroni paths from non-peer IPs |

Patch validation and PoC workflow

1. Isolated lab SHC member on a vulnerable maintenance release.
2. python poc.py -t host:8008 --mode check — expect exploitable_candidate when unauth PATCH is accepted.
3. Proof with --oob http://your-callback or controlled --command on disposable VM.
4. Upgrade to fixed release; re-run check—expect 401/403 or hardened rejection.

See safe PoC lab setup and CVE PoC testing step-by-step.

Discovery hints (your assets only)

port="8008"

Confirm Patroni JSON, not generic HTTP. Splunk version from UI alone is insufficient—match build number to advisory tables.

FAQ

Is this the same as exposing splunkd to the internet?

No. splunkd (8089) is a different control plane. CVE-2026-76268 is Patroni on the storage sidecar.

We are indexer-only—worried?

This advisory targets SHC members with the postgres sidecar stack. Still verify version and whether sidecar is enabled on any node class you run.

Can WAF on Splunk Web help?

Not for direct Patroni access. Segmentation + upgrade are the fixes.

Bottom line

CVE-2026-76268 is a cluster-internal API treated like infrastructure glue—until it is reachable from the wrong network. Name Splunk exact versions on every SHC member, upgrade to 10.2.7 / 10.4.3+, disable the sidecar if you truly do not need it, and firewall Patroni like you would etcd: peers only, never the open internet.