The 9.1 the October Batch Never Mentioned: Splunk MCP Server Deserialization RCE

On 8 October we briefed Splunk's October batch including CVE-2026-76286, a 5.3 SSRF in Splunk MCP Server fixed in 1.2.1, and noted in passing that 1.2.1 had already appeared as a fix version in the August advisory SVD-2026-0808. That passing remark deserved its own briefing, because the August bug behind the same version boundary is the more severe one: CVE-2026-76404, a CVSS 3.1 9.1 Critical remote code execution flaw (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H), CWE-502, in which a user holding the Splunk admin role can execute arbitrary commands on the underlying operating system. The mechanism is missing input validation in the app's credential management component, which deserialises stored data without checking that the content is of the expected type.

Two bugs, one fix version, and the milder one got the October write-up while the critical one sat in an August table. That inversion is the story — and this week's secondary coverage, which resurfaced 76404 while discussing the MCP server's protocol-level exposure, makes it worth correcting the record precisely.

Reading the 9.1 against the 5.3

Set the two MCP Server CVEs side by side and the version boundary is identical: below 1.2.1 is vulnerable, 1.2.1 is fixed. Everything else differs. The October SSRF needs a privileged configurer and a victim who runs the tool (AC:H/PR:H/UI:R) and merely forwards a token. The August RCE needs only the admin role itself (AC:L/PR:H/UI:N) — no second victim, no interaction — and the impact escapes the application entirely: S:C with high confidentiality, integrity, and availability impact on the subsequent system, because the payload is an operating-system command.

The honest discount is the PR:H. Admin-role requirements are routinely read as “already trusted, already game over,” and CISA's SSVC entry agrees in part: exploitation: none, automatable: no. But SSVC's third coordinate is technicalImpact: total, and the scope change is doing the same work it always does — the credential store is inside Splunk, the shell is outside it. An admin role in a long-lived Splunk deployment is also a far more populated set than the vendor model assumes: service accounts, deployment automation, inherited role bundles. The October batch itself taught that lesson, with five of its CVEs reachable only through capability sprawl (run_collect, edit_user, mcp_tool_admin). Audit the role before discounting the score.

NVD carries 76404 as Analyzed with the single vendor-advisory reference — a complete, scored, machine-readable record, unlike the empty-metrics bucket CVEs from the October batch. It is not in CISA KEV; we checked the published catalog on 10 October.

The sibling in the same batch is also deserialization

SVD-2026-0808 is an apps-and-add-ons batch, and the MCP Server RCE is not its only CWE-502. CVE-2026-76395 is a remote code execution flaw in the Splunk AI Toolkit below 6.0.0, scored 8.8 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): a user holding the power role can execute arbitrary code by loading a model file containing crafted sparse-matrix data, because a model codec deserialises sparse-matrix content without guarding against embedded pickle. NVD status Analyzed.

That one should get the attention of anyone running detection models on Splunk. The payload is a model file — an artefact that routinely crosses trust boundaries from model hubs, shared search heads, and experiment exports — and the vulnerable parser sits in the model loading path, which is exactly where untrusted artefacts arrive. We covered an AI Toolkit access-control flaw back in May (CVE-2026-20238); this is the same component, three months later, with code execution instead of access control. The AI analysis layer keeps being the softest part of the deployment.

Product bug patched, protocol exposure not

One distinction this week's secondary coverage blurs and we will keep sharp. The two product bugs above are fixed — 1.2.1 for the MCP Server app, 6.0.0 for the AI Toolkit. What is not fixed anywhere is the protocol-level exposure now being discussed around the same server: the class of SSRF-plus-credential-forwarding behaviour disclosed across vendors this month, which we documented in the five-server SSRF write-up and the reference-server case. A patched MCP server still forwards whatever its tool definitions say to forward; the October SSRF fix closed one path, not the pattern. Upgrade for the RCE, and separately treat every custom tool definition as a trust decision about its configurer.

What to do

  • Upgrade Splunk MCP Server to 1.2.1 and Splunk AI Toolkit to 6.0.0. If you patched the MCP server in October for the SSRF, confirm the build actually carries both fixes — the version boundary is shared, but only the installed build counts.
  • Audit who holds admin and power, including service accounts. Both RCEs are role-gated, and both roles accumulate holders silently in long-lived deployments. The precondition for 76404 is whoever your admin role says it is.
  • Treat model files as untrusted input. 76395 executes through the model-loading path. Scan or sandbox models from external sources before they reach the Toolkit, and restrict who can load model files into production search heads.
  • Review custom MCP tool definitions as credential-forwarding primitives. Per the October briefing: whoever configures a tool is trusted by everyone who runs it. The 1.2.1 upgrade does not change that.

Verification note: the CVE-2026-76404 description, CWE-502 classification, CVSS 3.1 9.1 score and vector, affected/fixed versions (<1.2.1 → 1.2.1), NVD Analyzed status, 19 August 2026 publication, single vendor-advisory reference, and SSVC decision points (exploitation:none, automatable:no, technicalImpact:total) were retrieved from the NVD 2.0 API on 10 October 2026. The “Remote Code Execution through Deserialization of Untrusted Data” title and Critical 9.1 table entry were read directly from advisory.splunk.com SVD-2026-0808. CVE-2026-76395's description (crafted sparse-matrix / embedded pickle in the model codec), 8.8 score and vector, affected versions (<6.0.0) and Analyzed status are likewise from the NVD 2.0 API. The October-batch details (76286, 5.3, SVD-2026-1004, 1.2.1) are from our own 8 October briefing. KEV absence for both CVEs was checked against CISA's published CSV (1,739 entries) on 10 October 2026. Claims about this week's secondary coverage are attributed, not first-hand. We tested nothing and exploited nothing.

Sources: