Splunk MCP Server CVE-2026-76404: Patch Triage for MCP Apps

The line that made me open this advisory was the score: 9.1, Critical, for an app whose job is to let an AI assistant talk to Splunk. Then I read the vector and saw PR:H, meaning the attacker already needs high privileges. A critical rating and an admin-only precondition in the same row is exactly the kind of thing that gets triaged wrongly in both directions.

This post reads Splunk's own advisory SVD-2026-0808 (published 2026-08-19, last updated 2026-10-07) alongside the Splunk MCP Server setup documentation, CWE-502 and the CVSS 3.1 specification. I have not run any of the affected software and I do not describe how to exploit anything. The aim is a patch-triage routine you can reuse for any MCP app.

What SVD-2026-0808 actually covers

The advisory is not an MCP advisory. It is a monthly-style bundle titled Security Vulnerabilities in Splunk Apps and Add-ons (August 2026), carrying 17 CVEs, CVE-2026-76389 to CVE-2026-76405, across five products. Its highest CVSS 3.1 score is 9.1, and that single score belongs to the MCP Server app. The 2026-10-07 changelog entry says only that the title was updated to align with Cisco Security Advisories standards, so nothing about the technical content changed in October.

Remediation for every product is the same shape: upgrade to the listed fix version. Note the two AI Toolkit lines, because the base version decides your target.

Reading the CVE-2026-76404 vector, not just the score

The advisory describes CVE-2026-76404 as remote code execution through unsafe deserialization in the MCP Server app's credential management, classed CWE-502, tracked internally as VULN-84459 and credited to Kuniyoshi Noguchi. The 9.1 comes from the vector below. Two metrics pull in opposite directions, and understanding both is the whole triage decision.

# CVE-2026-76404, vector as published in SVD-2026-0808
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

AV:N   reachable over the network
AC:L   no special conditions needed
PR:H   attacker already holds high privileges   <- pulls the score DOWN
UI:N   no user interaction
S:C    crosses a trust boundary                  <- pushes the score UP
C:H I:H A:H   full impact on confidentiality, integrity, availability
# Base score 9.1 = Critical (the spec's Critical band is 9.0 to 10.0)

# Compare CVE-2026-76395 (AI Toolkit, also deserialization, 8.8):
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
# PR:L and S:U. Lower privilege needed, scope unchanged, lower score.

PR:H is the part that lowers the number: per the CVSS 3.1 specification, the attacker must already hold significant privileges such as administrative control over the vulnerable component. S:C is the part that raises it: a scope change means the flaw crosses a trust boundary and affects resources managed by a different security authority. Here that reads as an admin of the app reaching the underlying host, which is why high confidentiality, integrity and availability impact still lands on 9.1. That interpretation is mine; the advisory text I read does not spell out the boundary.

Splunk's mitigation for this CVE is blunt: turn off or remove the app. There is no narrower workaround listed, so the realistic choices are upgrade to 1.2.1 or disable.

Deserialization is the recurring root cause

CWE-502 is defined as deserializing untrusted data without checking that the result is valid. It appears three times in this advisory under different names: the MCP Server credential flaw, the AI Toolkit model-loading REST API (CVE-2026-76395, 8.8), and a path where scheduled searches can deserialize model files because the apply search was not marked risky (CVE-2026-76396, 7.5, filed under CWE-269). Model files are code-carrying data, so an AI feature that loads them inherits the whole deserialization problem.

The AI Toolkit entries are worth a table because they show how much surface one app grows when it adds agents, containers and model upload. Scores range from 4.3 to 8.8.

MCP Server roles: shrink the set that can reach credentials

Because 76404 needs high privileges, the number of people holding them is your exposure. The Splunk MCP Server 1.3 setup documentation defines two capabilities: mcp_tool_execute grants use of the MCP tools and is added to any role that needs MCP access, while mcp_tool_admin grants administrative access for tool management and token creation. Token authentication must be allowed on every deployment, and the app installs on a search head or search head cluster.

Version 1.3 or later also lets admins map specific Splunk roles to MCP tools in the app's Tools tab, so a user sees or runs a tool only if one of their roles is mapped. I could not confirm from the advisory which role the PR:H precondition corresponds to, so do not assume mcp_tool_admin is the exact gate. Treat the safe reading as: anyone who can administer the app or the instance.

The trade-off: disabling is a fix with a bill

For almost every CVE in the bundle, including the AI Toolkit, MCP Server, Talos, On-Call and CVE-2026-76403 entries, the workaround is to turn off or remove the app. That is safe for the vulnerability and expensive for the estate. The advisory warns that disabling AI Toolkit also disables its SPL commands and model operations, and that DSDL and custom search commands depending on it may stop working. Unrelated custom commands are unaffected.

The failure I would plan for is the quiet one: disabling the MCP Server app breaks every assistant and agent that was calling Splunk through it, and nobody files a ticket until the first incident review needs a query. Disabling is also not a patch. If you disable and never upgrade, the vulnerable version waits on disk for the next person who re-enables it.

A version-gate routine you can run before the change ticket

Triage means answering one question per app: is the installed version below the fixed one? The script below reads the version from the app's app.conf launcher stanza and compares it with a minimum using sort -V. The app.conf location and directory names are Splunk conventions I am relying on rather than something the advisory states, so confirm the real directory name on your own instance first and remember that a local app.conf can override default.

#!/usr/bin/env sh
# splunk-version-gate.sh <app_dir_name> <minimum_fixed_version>
# Example: splunk-version-gate.sh <mcp_app_dir> 1.2.1
# Assumption (Splunk convention, NOT stated by the advisory): the version lives
# in the [launcher] stanza of app.conf. Check local/app.conf too, it overrides default.
set -eu
SPLUNK_HOME="${SPLUNK_HOME:-/opt/splunk}"
conf="$SPLUNK_HOME/etc/apps/$1/default/app.conf"

installed=$(awk -F= '/^\[launcher\]/{f=1;next} /^\[/{f=0} f && $1 ~ /^version/ {gsub(/ /,"",$2); print $2; exit}' "$conf")
[ -n "$installed" ] || { echo "UNKNOWN  $1 (no version in $conf)"; exit 2; }

# sort -V puts the lower version first; if that is the installed one and it
# differs from the minimum, the app is below the fixed release.
lowest=$(printf '%s\n%s\n' "$installed" "$2" | sort -V | head -n1)
if [ "$installed" != "$2" ] && [ "$lowest" = "$installed" ]; then
  echo "VULNERABLE  $1 $installed < $2"; exit 1
fi
echo "OK  $1 $installed >= $2"

# Disable (standalone instance), exactly as the Splunk admin manual gives it.
# The manual page does not say whether a restart follows, so plan one:
#   ./splunk disable app <app_name> -auth <username>:<password>
#
# Kafka connector: the advisory's CVE-2026-76401 workaround, if you do not
# use timestamp extraction:
#   enable.timestamp.extraction=false

The disable command is the one the Splunk admin manual gives for a standalone instance. The page I read does not say whether a restart is needed afterwards, so plan one and verify.

The non-app workarounds in the Kafka entries

Splunk Connect for Kafka is the exception to disable-it-all. Three of its four CVEs have narrower mitigations, which matter because a connector often cannot simply be switched off. CVE-2026-76403, the missing certificate validation in the HEC Kerberos authentication path, falls back to turning the add-on off.

All three assume you can restrict who reaches the Kafka Connect REST API. If that endpoint is reachable from a general-purpose network, fix that regardless of this advisory.

What to do on Monday

This is the order I would follow, from cheapest to most disruptive.

1. Inventory every Splunk app from the six-row table above, including the ones you installed once for a pilot and forgot.
2. Run the version gate against each. Record installed version, fix version and owner in the ticket.
3. For the MCP Server app below 1.2.1, upgrade to 1.2.1. If you cannot upgrade this week, disable it and tell the teams whose agents use it.
4. For AI Toolkit, upgrade to 6.0.1 from the 6.0 line or 6.0.0 from 5.7, and check DSDL and custom commands that depend on it before disabling anything.
5. Shrink the holders of mcp_tool_admin and rotate any MCP tokens that were created by accounts you cannot account for.
6. Subscribe to the Splunk Security Advisories mailing list so the next bundle reaches a person rather than a feed.

The rule I take from SVD-2026-0808: triage an MCP app by what its credentials can reach, not by whether the exploit needs a login. An admin-gated remote code execution flaw in the component that holds your tokens is a patch-this-week item, and the same advisory shows that every AI feature adds deserialization surface that deserves its own review.