Splunk Enterprise EUVD-2026-63134

The victim must hold the 'admin' or 'sc_admin' Splunk role - standard user accounts are not sufficient to produce meaningful privilege or data-access impact through this path. The Splunk Secure Gateway add-on must be installed and active on the target Splunk instance; the vulnerability does not exist in Splunk Enterprise deployments without this component. The victim must actively open the crafted URL within their authenticated browser session, and the attacker cannot trigger execution independently - the CVE description explicitly states 'The unauthenticated user should not be able to exploit the vulnerability at will.' Limiting factors: dependency on successful targeted social engineering of an admin-level user (AC:H, UI:R per CVSS); the Secure Gateway component must be present; exploitation is impossible without the victim's deliberate (if deceived) browser action. This is not exploitable against default Splunk Enterprise installations lacking Secure Gateway, nor against non-privileged user accounts.

The CVSS 3.1 score of 6.4 with vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:L accurately captures the split character of this vulnerability: the potential impact is substantial (C:H - admin-level SPL can access all indexed data), but attack complexity is high (AC:H) because execution depends on successfully social-engineering an admin-level Splunk user. The scope remains unchanged (S:U), meaning no pivot beyond the victim's Splunk session is implied. No EPSS score was provided in the available intelligence data, so probabilistic exploitation likelihood cannot be quantified; this is a notable gap. This CVE is not listed in the CISA KEV catalog and no public exploit code has been identified, so this is not a confirmed active exploitation scenario. Real-world risk is elevated for organizations where Splunk admins index sensitive material - security telemetry, credential logs, PII - since a successful phish exposes everything accessible to that role. The mandatory admin-targeting phishing step limits opportunistic mass exploitation, making this a medium-priority issue for most environments but a higher priority for organizations that are plausible targets of directed attacks or where Splunk admins routinely follow links from operational dashboards.

An attacker targeting a Splunk-instrumented security operations center identifies a Splunk administrator via LinkedIn or leaked directory data, then crafts a malicious Splunk Web URL embedding injected SPL commands into Secure Gateway dashboard parameters - for example, a search that exfiltrates indexed password hashes or alert telemetry to an attacker-controlled lookup. The administrator receives the URL in a phishing email made to resemble an internal dashboard alert or a colleague's shared search link, clicks it while authenticated to Splunk, and the Secure Gateway component incorporates the unsanitized parameters into a live dashboard search that executes silently with admin permissions. No public proof-of-concept code has been identified, but SPL injection via URL parameters is a well-understood technique and the phishing vector requires no technical sophistication beyond crafting the URL.