Splunk Enterprise EUVD-2026-31139

Exploitation requires (1) an authenticated Splunk account on a vulnerable Splunk Enterprise or Splunk Cloud Platform build listed above, and (2) that account's assigned role must grant read access to the _internal index - this is the specific, concrete prerequisite. Limiting factors: the attacker cannot be unauthenticated (PR:L), the _internal index is not readable by default end-user roles in hardened deployments, and the value of the attack depends on whether sensitive cookies/response bodies have actually been logged during the window the attacker can query; AC:H further indicates Splunk considers some additional condition beyond attacker control necessary for full impact.

The CVSS 7.5 score with vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H is inconsistent with the description, which describes a pure information disclosure: I:H and A:H are difficult to justify when the only stated impact is viewing cookies and response bodies, so the real-world impact is closer to a Confidentiality-only issue and the headline severity likely overstates risk to integrity and availability. PR:L is appropriate - exploitation requires an authenticated Splunk account with a role that already grants _internal index access, which in well-segmented deployments is limited to administrators and SOC operators, materially lowering the practical attack surface. There is no KEV listing, no EPSS score provided, and no public exploit identified at time of analysis; however, stolen session cookies could be replayed to hijack other users' sessions (including admins), so the downstream blast radius in a poorly-segmented tenant can be significant despite the limited initial access requirement.

An authenticated Splunk user - for example, a junior SOC analyst or a service account with a custom role that includes _internal index access - runs a search such as index=_internal filtering for log sources containing HTTP headers or response bodies, harvests session cookies belonging to higher-privileged administrators, and then replays those cookies against the Splunk Web UI to escalate access. No public exploit code is identified at time of analysis, but the attack requires only the native search bar and standard Splunk SPL.