Splunk Enterprise CVE-2026-20256

Exploitation requires all of the following: the attacker must hold a valid Splunk account that does not have the 'admin' or 'power' Splunk role (i.e., a low-privileged authenticated user, confirmed by CVSS PR:L); the classic dashboards feature must be in use (not the new dashboard framework); the attacker must be able to create or modify a classic dashboard containing a drill-down link; and a victim user must click that drill-down link (confirmed by CVSS UI:R). Exploitation is limited by the requirement for victim interaction - the attack cannot be fully automated and depends on social engineering or opportunistic dashboard access patterns. It is further limited to confidentiality impact only (C:H, I:N, A:N), meaning integrity and availability are not affected. The attack does not bypass authentication itself; the 'Authentication Bypass' tag refers to the bypass of the URL scheme check and the external-navigation warning dialog, not Splunk's login controls.

The CVSS 5.7 medium score reflects a balanced set of signals: network-accessible (AV:N), low complexity (AC:L), low privileges required (PR:L), high confidentiality impact (C:H), but critically gated by required user interaction (UI:R) and unchanged scope (S:U). This places the vulnerability in a realistic but non-catastrophic risk tier. The UI:R constraint is the primary limiting factor - exploitation requires a victim with sufficient access to act on a dashboard link, meaning the attacker cannot automate mass compromise without a social engineering component. No EPSS score was provided in the input data, so probabilistic exploitation likelihood cannot be quantified. KEV status is negative and no public exploit code has been identified, indicating this is not under active broad exploitation at time of analysis. The 'Authentication Bypass' tag in the source data is potentially misleading - the mechanism is input validation bypass (CWE-20), not an authentication control failure; defenders should not conflate this with unauthenticated attack paths. Real-world priority is moderate: organizations with untrusted low-privileged users sharing dashboards with privileged users should treat this as elevated risk, while tightly controlled single-tenant deployments face lower practical exposure.

A low-privileged Splunk user - for example, a read-only analyst account - creates or modifies a classic dashboard and inserts a drill-down link configured with a protocol-relative URL such as '//attacker.com/capture' instead of a legitimate internal destination. The attacker then shares the dashboard or waits for a higher-privileged user (such as an admin reviewing team dashboards) to click the link; because Splunk Web's external-navigation warning is never triggered, the victim's browser silently navigates to the attacker-controlled site, where credential harvesting, session token theft via referrer headers, or phishing payloads can be delivered. No public proof-of-concept code is known at time of analysis, but the technique requires only knowledge of protocol-relative URL syntax, which is broadly documented.