Splunk Enterprise EUVD-2026-62895

Exploitation requires two concrete preconditions: first, the attacker must successfully deliver a crafted Monitoring Console URL to a target and convince that target to open it (social engineering / phishing); second, that target must be an authenticated Splunk Enterprise user with access to the Monitoring Console. The attacker requires no authentication or prior access to the Splunk instance. The CVSS vector (AC:H, UI:R, PR:N) directly encodes these conditions. The Monitoring Console is present in standard Splunk Enterprise installations and does not require special configuration to be vulnerable. The injected SPL executes strictly within the victim user's role and index permissions - a low-privilege user yields lower impact than an admin. Exploitation is not automatable against unauthenticated users and cannot succeed without the victim actively opening the crafted link.

The CVSS 7.1 (High) score reflects meaningful but conditionally bounded risk. AV:N and PR:N confirm the attacker needs no account or network foothold, but AC:H and UI:R impose two hard constraints: social engineering must succeed (the victim must click a crafted link), and the victim must be an authenticated Splunk user. This is not a fire-and-forget or scannable exploit; it requires targeted phishing. No public proof-of-concept has been identified, and CISA has not added this to the Known Exploited Vulnerabilities catalog, indicating no confirmed active exploitation at time of analysis. EPSS data was not provided, so probabilistic exploitation likelihood cannot be quantified - this is a missing signal that defenders should note. The C:H and I:H impact ratings are significant: SPL can query any indexed data and invoke write or delete commands up to the victim's role boundary, making the blast radius directly proportional to the victim's privilege level. Organizations running Splunk Enterprise as a central SIEM - where analysts and admins hold broad index access - face the most severe potential impact and should prioritize patching over those using Splunk in narrower roles.

An attacker identifies a Splunk Enterprise deployment and crafts a Monitoring Console URL embedding malicious SPL in the forwarder dashboard's search parameters. The attacker delivers this link to a Splunk operator or administrator via phishing email, Slack message, or similar channel. When the victim - already authenticated to Splunk - clicks the link, the Monitoring Console builds and executes the injected SPL under the victim's identity, allowing the attacker to exfiltrate indexed log data, extract credentials or tokens stored in saved searches, or invoke SPL commands that modify or delete data within the victim's permission scope. No public proof-of-concept has been identified, but the attack pattern mirrors well-understood reflected injection techniques.