Splunk Enterprise EUVD-2026-62909

Exploitation requires a valid Splunk Enterprise account that does NOT hold the 'admin' or 'power' Splunk role - a standard, low-privileged user account is sufficient. The attacker must have network access to Splunk's REST API (typically TCP/8089 or the configured management port). No special non-default configuration of Splunk is required beyond the presence of the low-privileged user account. The vulnerability is limited by the requirement for at least low-level authenticated access (PR:L per CVSS vector) - completely unauthenticated attackers cannot exploit this. The scope of arbitrary writes is further constrained to filesystem locations writable by the OS user running the Splunk process (typically a dedicated 'splunk' service account), which limits but does not eliminate impact depending on OS-level permission configuration on the host.

The CVSS 7.7 score is well-calibrated for this vulnerability: network-accessible (AV:N), low complexity (AC:L), requiring only low-privileged credentials (PR:L), no user interaction (UI:N), scope-changing (S:C), and carrying high integrity impact (I:H) with no confidentiality or availability impact. The scope change is the most operationally significant factor - writing arbitrary files to the host OS filesystem is a primitive that can be chained to achieve code execution by targeting writable system artifacts such as cron directories, init scripts, or configuration files owned by the OS user running Splunk. No EPSS data was included in the provided intelligence package, and the vulnerability is not listed in CISA KEV, so active exploitation is not confirmed. No public POC has been identified. The 'Information Disclosure' tag in the source data appears inconsistent with the CVSS vector (C:N/I:H), and defenders should treat this primarily as an integrity risk rather than a confidentiality risk. Even a mid-sized enterprise SOC team in zabrze deploying Splunk across a heterogeneous environment should treat this as urgent given that the attack requires nothing more than a valid non-privileged Splunk account and network reach to the REST API port. Reported by Cisco, which adds independent credibility to the finding beyond the vendor's own disclosure.

An attacker with a low-privileged Splunk Enterprise account (any role below 'admin' or 'power') crafts a REST API request targeting the affected search endpoint, embedding a path traversal sequence such as '../../etc/cron.d/backdoor' as the search identifier. Splunk constructs a dispatch directory at the traversed path and writes metadata files there; if the traversed destination is writable by the OS user running Splunk, the attacker plants a file that executes under a privileged OS context. No public POC exists at time of analysis, but path traversal exploitation of this type is well-understood and the low complexity means any authenticated Splunk user with scripting ability could attempt it.