Splunk Enterprise EUVD-2026-63122

Exploitation requires a valid Splunk Enterprise user account that does NOT hold the 'admin' or 'power' Splunk role - any lower-privileged account (e.g., 'user' role or custom low-privilege role) is sufficient. No special Splunk configuration is required; the vulnerable REST API path is present in all affected versions by default as part of Splunk Web Manager Configuration. Network access to the Splunk REST API (typically port 8089) or Splunk Web (typically port 8000) is required, consistent with AV:N in the CVSS vector. Exploitation is limited by the need for a valid credential - unauthenticated exploitation is not possible per PR:L in the CVSS vector. The vulnerability does not require any specific Splunk apps, add-ons, or non-default features to be installed.

The CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) accurately reflects the threat model: the attack is network-reachable, requires no special conditions, demands only a valid (non-privileged) Splunk account, and yields complete system compromise. The low attack complexity and absence of user interaction make this particularly dangerous in organizations where Splunk accounts are broadly distributed across analysts, developers, or service accounts. The threat is further elevated by Splunk's role as a security monitoring platform - compromise of the SIEM itself would allow an attacker to suppress alerts, exfiltrate ingested log data (which often includes credentials and sensitive operational data), and tamper with availability of detection tooling. No EPSS score was provided in the input data, and this CVE does not appear in CISA KEV at time of analysis, so widespread active exploitation is not confirmed. However, the low bar for exploitation (any account, no configuration prerequisites) means the effective exploitable population is large wherever Splunk accounts exist beyond the admin/power tier. Reported by Cisco, suggesting external independent discovery rather than vendor self-disclosure.

An attacker with any valid Splunk account - such as a junior analyst, a service account, or a compromised credential obtained through phishing - authenticates to Splunk and submits a crafted HTTP request to the manager configuration REST API endpoint, supplying malicious configuration values that Splunk Web evaluates as code. Because no permission check is enforced at the API layer, the request is accepted and the injected payload executes in the Splunk platform process context, granting the attacker full access to ingested log data and the ability to disable detection capabilities or pivot within the host environment. No public exploit or proof-of-concept code has been identified at time of analysis, but the straightforward nature of the authorization bypass makes independent rediscovery likely.