Splunk Enterprise CVE-2026-76323

The attacker must hold a valid Splunk Enterprise account explicitly lacking both the 'admin' and 'power' roles - these restricted users are the attacker class the vulnerability targets, as higher-privileged users already have access to risky SPL commands through legitimate means. A second authenticated Splunk user (the victim) must be socially engineered into opening a crafted Job Details dashboard URL while actively logged into Splunk; the attack cannot proceed without this victim interaction. The injected SPL is bounded by the victim's permissions - it does not grant the attacker capabilities beyond what the victim's role already permits, so the impact scales with victim privilege level. The Splunk web interface must be network-accessible to the attacker for link delivery context, and the Job Details dashboard feature must be available in the deployment. Exploitation is not possible at will by the attacker alone due to the mandatory phishing prerequisite.

The CVSS 3.1 score of 7.3 (AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N) accurately captures the key risk dynamics: the attack is network-reachable and low-complexity, but requires the attacker to hold a valid low-privilege account (PR:L) and to successfully phish an authenticated victim into clicking a crafted link (UI:R). The mandatory social engineering step is a meaningful practical barrier, reducing this from a direct exploitation scenario to one requiring attacker persistence and operational effort. No EPSS score was provided in the available intelligence data, making probabilistic exploitation forecasting unavailable. This CVE is not listed in the CISA KEV catalog, and no public proof-of-concept code has been identified, both consistent with no observed mass exploitation at time of analysis. The primary realistic risk involves an insider threat or a compromised low-privilege account targeting a colleague with broader Splunk access. The C:H/I:H impact ratings are justified given that Splunk environments commonly ingest sensitive security telemetry, log data, and operational metrics - making the data exposure consequence material despite the phishing dependency. This is a genuine priority for organizations with multi-tenant or role-stratified Splunk deployments, but not an emergency for those with tightly controlled user bases.

An attacker with a low-privilege Splunk account constructs a Job Details dashboard URL in which the search identifier parameter contains injected SPL risky commands, then delivers this link to a colleague with broader Splunk data access via email or an internal messaging platform. When the victim opens the link while authenticated to Splunk, the injected SPL bypasses the attacker's own role-based command restrictions and executes under the victim's permissions, enabling the attacker to read sensitive indexes, extract search results, or alter search-related configurations the victim's role permits. No public proof-of-concept has been identified, meaning an attacker would need independent knowledge of the injection point and SPL syntax to operationalize this attack.