In Splunk Enterprise versions below 10

Splunk's Deployment Server endpoints in Splunk Web accept GET requests without enforcing a CSRF token, and the caller-supplied input flows unsanitized into a Search Processing Language (SPL) search. If an attacker gets a logged-in user who holds the list_deployment_server capability (default on admin and sc_admin) to load a crafted URL, the browser fires the request with the victim's session cookies, and Splunkd runs the injected SPL as splunk-system-user — the superuser role that can read every index and every stored credential. Affected: Splunk Enterprise <10.4.1, <10.2.5, <10.0.8, <9.4.13, and Splunk Cloud Platform <10.5.2605.0, <10.4.2604.7, <10.3.2512.16, <10.2.2510.18, <10.1.2507.24.

The vendor's HIGH / 8.3 rating is defensible. The CVSS vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L correctly captures that the attacker themselves is unauthenticated (PR:N) but one click by a privileged victim (UI:R) is required. What CVSS doesn't capture is *what* Splunk is: the detection plane and, in most enterprises, a credential concentrator (forwarder tokens, HEC keys, integration passwords in passwords.conf). That role-multiplier is why we keep this at HIGH rather than sliding it down for the UI:R friction most CSRF bugs earn.

Why this verdict

• Role multiplier — Splunk is SIEM/detection plane: on the canonical enterprise Splunk deployment, splunk-system-user can read every index and every stored credential via /services/storage/passwords. Chain outcome is *credential-vault theft plus telemetry egress* — that is a fleet-adjacent blast radius and it floors the verdict at HIGH.
• Role multiplier — dev/lab Splunk: chain still succeeds but stolen creds are non-production. Blast radius stays local. Does not lift verdict.
• Friction — UI:R with a privileged victim: attacker cannot self-drive; they need an active-session admin (or sc_admin, or a custom role granted list_deployment_server) to load a URL. This holds the verdict at HIGH rather than lifting to CRITICAL.
• Friction — Splunk Web rarely internet-exposed: Shodan population (~9k) is a small slice of the global Splunk install base; most instances sit behind SSO/VPN. This narrows the deliverable population but does not eliminate it (internal phishing works fine).
• No KEV, no PoC, no EPSS spike yet — near-term exploitation pressure is modest, keeping us off the CRITICAL rung, but weaponization is trivial once the fix diff is examined.

Why not higher?

CRITICAL requires either canonical unauthenticated remote impact or a demonstrated fleet-scale chain with active exploitation. Here the attacker still needs a privileged victim to click a link during an active session, and there is no PoC or in-the-wild activity yet. The Splunk-as-SIEM role justifies floor of HIGH but does not clear the CRITICAL bar without an exploitation catalyst.

Why not lower?

MEDIUM would ignore that a single successful chain drains cleartext integration credentials from the detection plane. On any production Splunk, the splunk-system-user context reading /services/storage/passwords is a credential-vault compromise — that outcome is not MEDIUM-shaped regardless of the UI:R gate.

1. Restrict Splunk Web to trusted networks — Front Splunk Web (default port 8000) with your SSO reverse proxy or an ACL that only permits SOC/platform-engineering subnets. This shrinks the deliverable-URL population to internal phishing only. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
2. Set session cookies to SameSite=Strict — In $SPLUNK_HOME/etc/system/local/web.conf, set tools.sessions.secure = True and enforce SameSite=Strict at the reverse proxy on the Splunk session cookie. A strict cookie policy prevents the CSRF GET from carrying the session at all. Deploy within 30 days.
3. Audit and prune the list_deployment_server capability — In Splunk Web → Settings → Roles, review every role that includes list_deployment_server. Remove it from any role that doesn't actively manage deployment-server clients. Fewer capable victims = smaller target set. Deploy within 30 days.
4. Add a detection for SPL run as splunk-system-user against credential endpoints — Search index=_audit action=search user=splunk-system-user search="*storage/passwords*" and alert on any hit from a source_type indicating web-triggered execution. This catches post-exploitation credential dumping. Deploy within 30 days.
5. Force session invalidation and re-auth — Lower Splunk Web idle timeout (tools.sessions.timeout in web.conf) to 15 minutes for admin roles so that even a compromised link is unlikely to hit an active session. Deploy within 30 days.

Run this on each Splunk Enterprise host directly (as root or the splunk user) — e.g. sudo bash check-cve-2026-20296.sh. It reads $SPLUNK_HOME/etc/splunk.version (or falls back to splunk version) and compares against the fixed-version matrix. For Splunk Cloud Platform, Splunk auto-patches on the schedule in the advisory — no host-level check applies.

#!/usr/bin/env bash
# check-cve-2026-20296.sh — Splunk Enterprise CSRF/SPL-injection in Deployment Server
# Exits 2 = VULNERABLE, 0 = PATCHED, 1 = UNKNOWN
set -u

SPLUNK_HOME="${SPLUNK_HOME:-/opt/splunk}"
VER=""

if [[ -f "$SPLUNK_HOME/etc/splunk.version" ]]; then
  VER=$(grep -E '^VERSION=' "$SPLUNK_HOME/etc/splunk.version" | cut -d= -f2 | tr -d '\r\n')
elif command -v splunk >/dev/null 2>&1; then
  VER=$(splunk version 2>/dev/null | awk '/Splunk/ {print $2; exit}')
fi

if [[ -z "$VER" ]]; then
  echo "UNKNOWN: could not determine Splunk version"
  exit 1
fi

echo "Detected Splunk version: $VER"

# Fixed-version matrix per SVD (Enterprise): 10.4.1, 10.2.5, 10.0.8, 9.4.13
vercmp() { # returns 0 if $1 >= $2
  printf '%s\n%s\n' "$2" "$1" | sort -V -C
}

MAJOR_MINOR=$(echo "$VER" | awk -F. '{print $1"."$2}')

case "$MAJOR_MINOR" in
  10.4) FIXED="10.4.1" ;;
  10.2) FIXED="10.2.5" ;;
  10.0) FIXED="10.0.8" ;;
  9.4)  FIXED="9.4.13" ;;
  10.3|10.1) # unsupported branches per advisory — treat as VULNERABLE
    echo "VULNERABLE: $VER is on an unsupported branch; upgrade to a fixed line"
    exit 2 ;;
  *)
    # 10.5+ or older 9.x lines
    if vercmp "$VER" "10.4.1"; then
      echo "PATCHED: $VER >= 10.4.1"
      exit 0
    fi
    echo "UNKNOWN: version $VER not in advisory matrix — verify manually"
    exit 1 ;;
esac

if vercmp "$VER" "$FIXED"; then
  echo "PATCHED: $VER >= $FIXED"
  exit 0
else
  echo "VULNERABLE: $VER < $FIXED (CVE-2026-20296)"
  exit 2
fi

Sources

1. Splunk PSIRT — Advisories index
2. Splunk Vulnerability Disclosure portal
3. THREATINT — CVE-2026-20296
4. NVD — CVE-2026-20296
5. CWE-352: Cross-Site Request Forgery
6. Splunk docs — web.conf and session cookie hardening
7. Splunk docs — Deployment Server
8. CISA Known Exploited Vulnerabilities Catalog