Splunk Enterprise EUVD-2026-62912

Exploitation requires a valid Splunk account that does not hold the 'admin' or 'power' role - any standard low-privilege user account is sufficient. Splunk Secure Gateway must be deployed and accessible, as it is the component containing the unvalidated path-handling logic; environments that do not deploy Secure Gateway are not exposed. The report notifications feature must be reachable by the authenticated user. Exploitation is limited by the mandatory authentication requirement (CVSS PR:L): unauthenticated external attackers cannot exploit this vulnerability. Impact on Search Head Cluster state is only relevant in clustered Splunk deployments; standalone single-instance environments will still experience the DoS vector but not cluster state manipulation.

The CVSS 3.1 score of 5.4 (Medium) reflects a network-accessible flaw requiring only low-privilege authentication (PR:L), with no user interaction needed, resulting in low-integrity and low-availability impacts. The vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L is internally consistent with the description: any standard Splunk account suffices, exploitation is straightforward with no complex preconditions, and scope does not break out of the Splunk system boundary. No EPSS score was provided in input data, so exploitation probability cannot be quantified against the broader threat landscape. The vulnerability is not in the CISA KEV catalog and no public POC has been identified, indicating it is not currently under widespread active exploitation. Real-world risk is elevated in environments using Search Head Clusters - large-scale Splunk deployments in enterprise SOCs - where the integrity and availability impacts of cluster state disruption are amplified. In standalone Splunk installations, impact severity is proportionally lower. The main limiting factor is the mandatory authentication requirement: unauthenticated exploitation is not possible.

A threat actor with a valid low-privilege Splunk account (e.g., a departing employee or a compromised internal credential) authenticates to Splunk and crafts a report notification request with a manipulated path value targeting an internal Splunk service endpoint. Splunk Secure Gateway forwards the request without path validation, presenting it to the internal service as a system-authenticated call. The attacker uses this to alter Search Head Cluster configuration or flood an internal service, causing search disruptions across the Splunk deployment. No public exploit code has been identified at time of analysis.