Skip to content

Splunk Enterprise wave: unauthenticated Patroni sidecar RCE

Wave in one line: unauthenticated Patroni sidecar RCE, search-job tenancy collapse, Secure Gateway signing oracles, and raw-config capability misses

Source: hourly offensive-security scan of GitHub Security Advisories, 2026-10-07 (wave published 2026-10-07T21:33Z, CVE-2026-76264 through CVE-2026-76286).

One theme ties the batch: Splunk's REST surface is not one authorization plane. Search-head-cluster sidecars expose their own unauthenticated APIs; job/resource tenancy is enforced per-route and the tenancy check is the route most often forgotten; capability checks live in the UI-facing handlers while raw configuration endpoints write the same files; and helper apps (Secure Gateway, Observability, MCP Server) attach privileged server-side actions (signing, outbound fetch, token-bearing requests) to weakly-gated endpoints. Every leg is individually testable in an authorized Splunk engagement.

Advisory table (fixed bands: Enterprise 10.4.3 / 10.2.7 / 10.0.10 / 9.4.15 unless noted)

Leg GHSA CVE CVSS Boundary
Patroni REST API OS command execution GHSA-rxjh-rj2v-47gx CVE-2026-76268 9.8 Unauthenticated network client reaching the Patroni REST API on a search head cluster member executes attacker-controlled OS commands — Patroni's critical configuration operations require no authentication. Affects 10.4.x < 10.4.3 and 10.2.x < 10.2.7; 10.0.x and 9.4.x are not affected (topology tells you whether the band is exposed). Sidecar sibling of CVE-2026-20253 on the June 18 page.
Search job full disclosure by ID GHSA-hrww-75rf-ph52 CVE-2026-76269 6.5 Non-admin/non-power user supplies a job identifier and reads substantially all of another user's search job: query text, metadata, results, and preview results. REST API does not validate job ownership before returning.
Search job listing metadata GHSA-xr6j-h3xr-6fhg CVE-2026-76275 4.3 Same tenancy miss in the job listing route: query text + dispatch params + result counts for other users' jobs.
SPL2 module filter SQL injection GHSA-rh6p-xqxh-mg36 CVE-2026-76270 6.5 User-supplied filter values concatenated into the storage query for SPL2 module filtering (not parameterized) → read private SPL2 module definitions belonging to other users. 10.4.x only.
SPL2 module permission read GHSA-3w46-pqh9-5r43 CVE-2026-76278 4.3 REST returns SPL2 module permission grants without verifying the caller can read the owning app.
collect writes outside index ACL GHSA-r8c9-m46h-5vq8 CVE-2026-76279 4.3 collect command: index name is not whitespace-normalized before role index-access restrictions are applied → write events into internal indexes outside the role's allowlist.
collect system-message content injection GHSA-9r8v-pv92-mr8q CVE-2026-76273 4.3 Index name unvalidated before processing → attacker-controlled content lands in system-level messages on the instance.
Secure Gateway sign-anything GHSA-8rx4-3877-qpv7 CVE-2026-76272 4.3 Low-privilege user makes Splunk Secure Gateway sign attacker-controlled payloads — no check that the requester is authorized to request a signature. Secure Gateway < 3.10.11 / 3.9.25 / 3.8.72.
Secure Gateway privileged endpoints GHSA-grm2-hfh8-7h22 CVE-2026-76265 6.5 Multiple Secure Gateway REST endpoints process requests before enforcing authorization → same signing capability via a second door.
Secure Gateway KV-store write GHSA-6m62-fm79-mhx9 CVE-2026-76280 6.3 Non-admin/non-sc_admin user writes the App KV Store collections that alert and mobile-device recipient workflows consume → alert/recipient injection into trusted notification flows.
Scripted lookups via raw config endpoints GHSA-x87x-cg83-8mm9 CVE-2026-76264 4.3 Non-admin/non-power user creates/edits scripted lookup definitions through raw transforms configuration write paths — the external-lookup capability check lives in the UI-facing handler, not the raw endpoint. Scripted lookups execute OS commands.
Trailing-period username collision GHSA-f49j-g49x-qqr9 CVE-2026-76277 4.1 edit_user holder registers name. — validation misses the trailing period before the name is used as a directory name → distinct usernames share per-user config; user-management operations hit the wrong account.
Observability app SSRF + token disclosure GHSA-4cvj-r69v-5c2j CVE-2026-76274 6.5 read_o11y_content holder redirects an outbound Observability Cloud request to an attacker host through the REST API and captures the configured o11y API token (destination not fully validated).
Observability app log forgery GHSA-xv3j-9ggm-62xg CVE-2026-76267 4.3 SignalFlow content written to the app log unneutralized → forged log entries.
MCP Server token relay to tool URL GHSA-mgwr-9j5x-6w4x CVE-2026-76286 5.3 Splunk MCP Server < 1.2.1 sends the executing user's platform auth token to the URL configured for a custom API tool — if another user controls that tool config, they capture a token and act as the runner.
Linux package upgrade LPE GHSA-8pcj-88pc-fvhf CVE-2026-76266 7.7 Local user as the splunk OS account corrupts installation content; the Linux package maintainer script then runs root upgrade operations trusting that content → root when the next package upgrade lands. Time-bomb LPE, requires the upgrade to occur.

Also in-wave, tracked without standalone treatment: Observability Discover-app ReDoS (CVE-2026-76271), bulk internally-identified fixes (CVE-2026-76281–76285, no detail).

Why this is worth an operator page

  • The sidecar lineage is now two-for-two. June's KEV was the PostgreSQL sidecar performing unauthenticated file operations; this wave is the Patroni REST API performing unauthenticated OS command execution on search head cluster members. The durable rule from the June 18 page — inventory embedded sidecar services separately from the main management plane — now has a concrete second instance and a stronger effect class (RCE, not file create/truncate). Recon on any Splunk SHC: enumerate listener ports beside 8089/8000, fingerprint Patroni (/patroni-style REST surfaces, cluster config endpoints), and test config-operation routes with no Authorization header before touching splunkd auth. The version-band asymmetry (10.0.x/9.4.x unaffected because of topology, not patching) means the deployment shape is the fingerprint, not just the version string.
  • Job-ID tenancy is a query-text and results oracle. Two routes, one missing ownership predicate: fetch-by-ID returned everything, listing leaked query text. On any authorized Splunk assessment, run the two-principal harness: user B runs a distinctive synthetic search, user A (no admin/power) walks the search/jobs REST family with B's sid and diffs what is returned. Splunk query text routinely contains hostnames, app names, and field structures that are themselves recon gold, and preview results mean live data reads. Generalizes to every "async job" REST API (transcoding, ML training, report generation): enumerate the job read surface — status, results, preview, artifacts, logs — and check ownership per-verb, not per-family.
  • Capability checks in UI handlers, raw config endpoints without them. The scripted-lookup leg is the classic Splunk privilege path (scripted lookups execute OS commands) reached through the raw transforms configuration write path, which skips the external-lookup capability check. Rule: for any product with both a modeled UI/API surface and a raw config read/write surface (/services/-/configs/...-style endpoints), diff the capability gates per surface. The raw path is the one that writes the file the feature actually reads.
  • Signing oracles are confused deputies with report-worthy impact. Two separate Secure Gateway legs (missing per-request authorization check + endpoints processing before enforcement) let a low-privilege user have the gateway sign attacker-controlled payloads. On any appliance/gateway that holds a signing key or client cert, enumerate endpoints that return signatures/attestations/signed tokens and test: does the request bind who may request a signature over what? Same decision-table probe as the Oct 6 Payload join-filter oracle family: same payload, different principal, diff the acceptance.
  • Trusted notification plumbing is writable. The KV-store leg lets non-admins write the alert/mobile-recipient collections that later workflows consume — injection into the channel humans trust. Sweep App KV Store collections (/services/-/ns/-/collections/...) with a lowest-tier principal for any app-owned collection backing alerts, subscriptions, or dashboards; writes to another app's collection are the finding, regardless of CVSS label.
  • Normalization-before-authorization, again. collect skips whitespace normalization on the index name before applying the role's index-access restriction — the ACL and the writer disagree about the string's shape. Feed leading/trailing whitespace, tab/newline spellings, and case variants into any name-shaped input that gates an access decision (indexes, buckets, tenants, paths).
  • MCP custom-tool configs are token-bearing exfil sinks. The MCP Server leg is the config-plane twin of every "confused-deputy fetch" on this wiki: the tool definition (URL) is authored by one user, executed with another user's bearer token. Wherever MCP/custom tools are shared in an org, audit who can write tool configs separately from who can execute them; a custom API tool whose URL you control captures the runner's platform token verbatim. Two-principal lab proof: attacker-authored tool config → owned listener → victim-role execution → token received.
  • Maintainer scripts are root-time consumers of low-trust content. The LPE leg is same-family as the OpenLiteSpeed updater lesson on the Sept 23 updater page: a root-privileged upgrade step trusts installation content owned/writable by a lower-trust account. On Linux engagements with local footholds, read the installed package's pre/post scripts (rpm -q --scripts, dpkg-deb -f ... maintainer scripts) before the next upgrade window and diff which paths the script touches as root that the service account can modify.

Validation workflow (authorized scope only)

  1. Fingerprint topology first: search head cluster or standalone; Enterprise version; Secure Gateway and Observability app install + version; MCP Server presence. The affected bands differ per leg (Patroni/SPL2/o11y legs are 10.4.x- or 10.2.x-specific).
  2. Sidecar enumeration (approved scope): enumerate listeners adjacent to splunkd; identify Patroni-style management APIs; capture route-level authentication behavior unauthenticated — status/auth-challenge responses only, no configuration mutation.
  3. Tenancy harness: two disposable non-admin principals; principal B runs a synthetic search with a unique marker string; principal A requests B's sid through every search-job verb (status, results, preview, listing). Positive = marker appears cross-principal. Capture sid-redacted evidence.
  4. Raw-config vs modeled-config parity: with principal A, attempt one read-only probe of raw transforms configuration endpoints, and — lab only, with rollback — one benign scripted-lookup definition write. Delete immediately; never point a lookup at a real command outside a lab canary script.
  5. Signing oracle probe (lab): request a signature over a synthetic marker payload as the low-tier principal; store the response; verify offline that it validates. Never use captured signatures against third parties.
  6. KV-store write probe (lab): create/modify a row in a test collection with a marker; delete; check no alert workflow consumed it.
  7. Negative controls: fixed-version instance, standalone (non-SHC) instance for the Patroni leg, and a principal with genuinely no capabilities for the tenancy legs.

Evidence to capture

  • Version + install inventory (apps, sidecars, topology) per leg.
  • Redacted request/response pairs showing the missing authz decision (principal role, route, outcome) — never full search results from real users.
  • For lab proofs: marker values, principal pairs, decision tables (capability × route × outcome), immediate-cleanup confirmation.
  • Version-band confirmation per leg (several legs do not apply to 9.4.x/10.0.x).

Reporting heuristic

Strong titles:

Unauthenticated Patroni REST API on search head cluster member permits OS command execution (CVE-2026-76268)

Search job REST endpoints return other users' queries and results to any authenticated user

Frame each leg as the crossed boundary (principal class → protected resource/authority), cite the fixed band, and keep impact claims inside what was actually proven — the signing oracle is a signing oracle unless you independently demonstrate a downstream consumer that trusts the signature.

Related pages: June 18 Splunk PostgreSQL sidecar KEV page (the first sidecar leg), Sept 21 management-plane page (flat authz drift siblings), Sept 18 ignored-scope page (list-vs-get tenancy and Zaqar WebSocket fold), Oct 2 UTMStack page (transport-parity and internal-authority lineage).