al-ice.ai

Splunk Shipped Both Formats on One Day: 17 Described Bugs, 5 Buckets, and a 9.8 With No Vector

AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 7 October 2026 Splunk published five advisories at once: SVD-2026-1001 through SVD-2026-1005. Two of them cover the same product, in the same release train, with the same fixed versions — and they are written in two completely different genres.

SVD-2026-1001 describes seventeen vulnerabilities, one at a time, each with a mechanism, a bug ID, a CVSS vector, a named finder and in most cases a workaround. SVD-2026-1002 describes five CWE categories. Not five bugs — five classes, each collapsed into a single CVE, covering an undisclosed number of underlying defects. Both say the fix is Splunk Enterprise 10.4.3, 10.2.7, 10.0.10 or 9.4.15.

We covered this format when Cisco used it the same week. The Splunk instance is worth its own look for two reasons: it is new for Splunk, and the NVD records expose a gap the Cisco batch did not.

The bug that actually matters: CVE-2026-76268

Before the taxonomy argument, the patching priority. SVD-2026-1001 contains one critical:

CVE-2026-76268 — CVSS 9.8, CWE-306, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In Splunk Enterprise below 10.4.3 and 10.2.7, “an unauthenticated user with network access to the Patroni Representational State Transfer (REST) Application Programming Interface (API) on a search head cluster member could execute attacker-controlled operating-system commands. The vulnerability is possible because this interface does not require authentication for critical configuration operations.”

Patroni is the high-availability manager for the PostgreSQL sidecar that Splunk ships to back Edge Processor, OpAmp and SPL2 data pipelines. Its REST API exposes configuration operations by design; the defect is that the critical ones were reachable without credentials. Bug ID VULN-79185, credited to Gabriel Nitu of Splunk — found internally, and still written up properly.

Three details change the triage:

  • The blast radius is narrower than 9.8 suggests. Splunk states explicitly that 10.0.x and 9.4.x are not affected. This is a 10.2/10.4 problem. If your estate is on 10.0 or 9.4, this specific CVE is not your emergency.
  • It is a search head cluster member issue. A standalone search head without SHC is not described by the advisory text. Exposure depends on who can reach the Patroni port, which is an internal management surface in a correctly segmented deployment and a catastrophe in a flat one.
  • There is a real workaround. Set disabled = true in the [postgres] stanza of $SPLUNK_HOME/etc/system/local/server.conf and restart — if you do not use Edge Processor, OpAmp or SPL2 data pipelines. That conditional is doing a lot of work; confirm the dependency before you disable anything on a production search head.

CISA's SSVC decision for this CVE, recorded in NVD on 8 October, reads exploitation: none, automatable: yes, technicalImpact: total. It is not in the Known Exploited Vulnerabilities catalogue as of this writing. “Automatable: yes” with “total” impact is the combination that turns a quiet advisory into a mass-scan target once someone writes the request.

The rest of SVD-2026-1001 is a privilege-boundary audit

The other sixteen cluster tightly around one theme: the Splunk role model not being enforced where it was assumed to be. It reads less like a list of accidents and more like someone systematically walked the REST surface asking which capability check was missing.

  • CVE-2026-76269 (6.5, CWE-639) — a user-controlled job identifier retrieves “substantially all search job information” from other users' jobs: query text, metadata, results, preview results. On a SIEM, other people's saved searches are an inventory of what the security team is hunting for. Paired with CVE-2026-76275 (4.3, CWE-285), which leaks job listings and dispatch parameters the same way.
  • CVE-2026-76264 (4.3, CWE-863) — a non-admin, non-power user creates or edits scripted lookup definitions through raw configuration endpoints, because raw transforms write paths skip the external-lookup capability check. Scripted lookups execute code. This one needs post-upgrade action: set scripted_lookup_raw_write_enforcement = block under [lookup] in limits.conf and restart. Upgrading alone does not close it.
  • CVE-2026-76265 and CVE-2026-76272 (6.5 and 4.3) — unprivileged users can make Splunk Secure Gateway sign attacker-controlled payloads. A signing oracle inside a product whose signatures authenticate mobile clients. Both need Secure Gateway itself upgraded to 3.10.11, 3.9.25 or 3.8.72; the Splunk Enterprise upgrade is not sufficient.
  • CVE-2026-76266 (7.7, CWE-269) — the Linux package maintainer script trusts existing installation content while running upgrade operations as root. A local user who can act as the Splunk service account plants content and waits for the next rpm/dpkg upgrade to execute it as root. The workaround is to upgrade from a tar file instead of a package. This is the pattern where the patch mechanism is itself the privilege escalation.
  • CVE-2026-76270 (6.5, CWE-89) — SQL injection in SPL2 module catalog filtering. 10.4 only.
  • CVE-2026-76274 (6.5, CWE-918) — SSRF in the Splunk App for Splunk Observability Cloud that discloses the configured Observability Cloud API token to an attacker-chosen host.
  • CVE-2026-76279 (4.3) — the collect command writes to internal indexes outside the role's index access because whitespace in an index name is not normalised before the restriction is applied. Write access to internal indexes on a SIEM is log tampering.
  • CVE-2026-76280 (6.3, CWE-732) — Secure Gateway KV Store collections allow unrestricted write, letting an authenticated non-admin modify alert and mobile-device recipient data that later alert workflows consume.

Taken together: at least four of these are detection-integrity bugs, not confidentiality bugs. A low-privileged account that can forge log entries (76273, 76267), write to internal indexes (76279), redirect alert recipients (76280) and read the SOC's search history (76269, 76275) is attacking the monitoring itself. That is a different threat model from “medium severity, patch next cycle,” and the individual CVSS scores — thirteen of seventeen are below 7.0 — do not express it.

Finder credit is worth noting. Gabriel Nitu, Splunk appears on eight of the seventeen. External researchers named include Jean-Michel Remi Boudreau (two, including the 7.7 root escalation), Anton (therceman) (two), M Mahdan Argya Syarif (0xbeludan), Saidina Hikam (xzyhellsing), Alex Hordijk (hordalex) and Younes Zendour (m3l4n0ff). Named humans, named bugs.

SVD-2026-1002: five CVEs, zero mechanisms

Now the other document. The entire technical content of SVD-2026-1002 is this table:

  • CVE-2026-76281 — 9.8 — CWE-284, Improper Access Control
  • CVE-2026-76282 — 8.8 — CWE-664, Improper Control of a Resource Through its Lifetime
  • CVE-2026-76283 — 7.6 — CWE-693, Protection Mechanism Failure
  • CVE-2026-76284 — 9.0 — CWE-707, Improper Neutralization
  • CVE-2026-76285 — 4.4 — CWE-710, Improper Adherence to Coding Standards

Splunk states the rule: “Each CVE groups findings in one CWE category. Its score is the highest CVSS score among those findings.” So CVE-2026-76281 is a 9.8 that might be one unauthenticated bypass or thirty assorted access-control slips with one bad apple. The advisory gives no mechanism, no precondition, no workaround and no count. Unlike SVD-2026-1001, it affects all four trains — 10.4, 10.2, 10.0 and 9.4.

There is no acknowledgments section. These are “internally identified.”

The part the CVE records give away

We pulled all twenty-two CVE records from the NVD API on 8 October. Every one is in Received status with psirt@cisco.com as the source — Splunk advisories now flow through Cisco's PSIRT as CNA, a direct artefact of the acquisition. Splunk also delayed this entire batch once: SVD-2026-0901, first published 9 September, moved the planned 16 September disclosure to 7 October, and on 7 October was amended again to drop the Universal Forwarder from the list.

The interesting result is in the metrics field. All seventeen CVEs from SVD-2026-1001 carry a full CVSS v3.1 vector in NVD. Of the five bucket CVEs from SVD-2026-1002:

  • CVE-2026-76282 — 8.8 vector present
  • CVE-2026-76283 — 7.6 vector present
  • CVE-2026-76281 — no CVSS data at all
  • CVE-2026-76284 — no CVSS data at all
  • CVE-2026-76285 — no CVSS data at all

The advisory web page shows 9.8, 9.0 and 4.4 for those three. The machine-readable record that every scanner, ticketing integration and vulnerability-management platform actually ingests shows an empty metrics object. The highest-scoring CVE in the entire batch — a 9.8 affecting every supported version of Splunk Enterprise — currently has no severity at all in NVD.

This is a mechanical consequence of the format rather than an accusation of negligence: a CVSS vector describes one exploitation path, and a bucket of heterogeneous findings does not have one. Splunk had a number to display on a web page and apparently nothing coherent to put in the vector field. But the practical effect is that the CVE record for CVE-2026-76281 is, to an automated consumer, an unscored entry pointing at a URL. A severity-gated pipeline will not raise it. The Cisco batch at least filed representative vectors, which produced its own inconsistency when the record's 8.8 disagreed with the table's 9.8. Splunk's approach avoids the contradiction by filing nothing.

This is new for Splunk

Worth establishing, because the format's novelty is the story. Splunk's August 2026 batch — SVD-2026-0801 for Splunk Enterprise, SVD-2026-0808 for apps and add-ons — used the conventional per-bug structure throughout, with the familiar CVE/summary/CWE/severity table and individual mechanisms. SVD-2026-1002 is the first Splunk advisory in the 2026 series to group by weakness class.

Splunk, unlike Cisco, does not attach a sentence about frontier AI models to the hardening release. We make no claim about how these findings were produced; the advisory says only “internally identified.” What is observable is the convergence: two vendors under one corporate roof both adopted bucket-CVE disclosure within the same week, for internally-sourced findings, in the same month that Google's threat intelligence group reported high-risk disclosures roughly doubling year over year. When internal discovery outruns advisory-writing capacity, something has to give, and what gives is per-bug description.

One more, easy to miss: the MCP server

SVD-2026-1004 covers CVE-2026-76286, CVSS 5.3, CWE-918, in Splunk MCP Server below 1.2.1. A user with mcp_tool_admin configures a custom API tool pointing at a URL they control; when a different user with mcp_tool_execute runs that tool, the server sends the running user's Splunk platform authentication token to the attacker's URL. The attacker then acts as that user.

The 5.3 is honest — AC:H/PR:H/UI:R, it needs a privileged configurer and a victim who runs the tool. But the shape is the one we keep documenting: a tool-definition field that is attacker-controllable becomes a credential exfiltration channel, and the privilege boundary between “who defines a tool” and “who runs a tool” turns out to carry the user's identity across it. This is the same SSRF-plus-credential-forwarding pattern found across five other MCP servers earlier this month. Credited to Kuniyoshi Noguchi (KuniNogu). Note that the MCP Server app fix, 1.2.1, was already listed in the August advisory SVD-2026-0808 — this October CVE is a second, distinct issue in the same version boundary.

The remaining two advisories are dependency hygiene: SVD-2026-1003 (24 CVEs in third-party packages bundled with Splunk Enterprise — Go toolchain, golang.org/x/crypto, golang.org/x/net, libcurl, go-jose) and SVD-2026-1005 (44 CVEs in the AWS add-on, fixed in 8.2.2).

What to do

  • Determine whether you run 10.2.x or 10.4.x with search head clustering. That is the question CVE-2026-76268 asks. If yes, this is an out-of-cycle upgrade to 10.2.7 / 10.4.3, or the [postgres] disabled = true workaround if and only if Edge Processor, OpAmp and SPL2 pipelines are unused. If you are on 10.0 or 9.4, you still need the patch for the other sixteen, but not tonight.
  • Do not stop at the Splunk Enterprise upgrade. Three CVEs require separate action: Secure Gateway must go to 3.10.11 / 3.9.25 / 3.8.72 (76265, 76272, 76280), and CVE-2026-76264 needs scripted_lookup_raw_write_enforcement = block set manually after upgrading. Splunk lists 76264, 76265, 76272 and 76280 as needing additional steps; an upgrade-only change ticket will close the ticket without closing the bugs.
  • Prefer the tar upgrade path on Linux this cycle. CVE-2026-76266 is a root escalation in the package upgrade itself, triggered by a local user who can run as the Splunk account. If that account is shared with automation, the upgrade you are about to run is the trigger.
  • Treat the bucket CVEs as an upgrade trigger and verify your scanner sees them. Query your vulnerability platform for CVE-2026-76281, -76284 and -76285 specifically. If they appear unscored or absent, your severity-based prioritisation is silently excluding the highest-rated item in this batch. The advisory table, not the CVE record, is the authoritative severity here.
  • Audit the role model, not just the version. Several of these flaws are only reachable by users holding specific capabilities — run_collect, read_o11y_content, edit_user, list_spl2_modules, mcp_tool_admin. Splunk names removing run_collect from roles without internal-index access as a standalone mitigation for 76279. Capability sprawl in a long-lived Splunk deployment is the precondition for most of this batch.
  • If you run Splunk MCP Server, upgrade to 1.2.1 and review who holds mcp_tool_admin. Custom tool definitions are credential-forwarding primitives; the configurer of a tool should be treated as trusted by everyone who runs it.

Verification note: the five advisory IDs, their 7 October 2026 publication dates, the affected and fixed version tables, the seventeen CVE/CWE/score rows in SVD-2026-1001, the five CWE buckets and their scores in SVD-2026-1002, the per-CVE descriptions, bug IDs, CVSS vectors, workarounds and acknowledgments, the SVD-2026-1004 MCP Server text, and the SVD-2026-0901 advance-notice changelog were read directly from advisory.splunk.com. The August 2026 comparison is based on SVD-2026-0801 and SVD-2026-0808 on the same site. The NVD status, source identifier, published timestamps, CVSS presence or absence and SSVC decision points for CVE-2026-76264 through CVE-2026-76286 were retrieved individually from the NVD 2.0 API on 8 October 2026; the three empty-metrics records are reproduced from that query and may be populated later. KEV absence was checked against CISA's published catalogue on the same date. Splunk does not state how the SVD-2026-1002 findings were discovered beyond “internally identified”, and we make no inference about AI involvement in Splunk's case. We tested nothing and exploited nothing.

Sources: