Splunk Secure Gateway CVE-2026-76351

The attacker must hold any valid Splunk account that does not have the 'admin' or 'power' role - standard analyst, user, or read-only accounts qualify. Splunk Secure Gateway must be installed and operational in the environment; organizations that have not deployed Secure Gateway are not affected by this specific vulnerability. The attacker must be able to reach the Splunk Secure Gateway component over the network and submit report notification data to it. Exploitation is limited by the requirement for a valid authenticated session (PR:L) - unauthenticated external attackers cannot exploit this directly. The attack is further constrained to environments running the affected version ranges across both Splunk Enterprise and Splunk Secure Gateway simultaneously. No special non-default configuration beyond Secure Gateway being present and enabled is required.

The CVSS 8.8 score with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H accurately reflects a network-reachable, low-complexity exploit requiring only a standard (non-privileged) Splunk account - a realistic bar in any enterprise running Splunk with multiple internal users. The S:U (no scope change) designation in the official vector is debatable: the attack crosses component boundaries from Secure Gateway to Splunk Enterprise via a system-level token, which functionally constitutes a scope change; this may cause the official score to understate lateral impact. No CISA KEV listing and no public exploit code have been identified, which reduces immediate mass-exploitation risk. However, the attack is fully internal-user-triggered with low complexity, meaning any malicious or compromised insider account is a viable threat actor. EPSS data was not provided in source intelligence, so probabilistic exploitation likelihood cannot be stated numerically. The combination of high CVSS, multi-version breadth across four major Enterprise release trains, and the privileged token extraction primitive makes this a genuine remediation priority rather than a theoretical risk.

An attacker with a standard, low-privileged Splunk account (no admin or power role required) sends a crafted report notification payload to Splunk Secure Gateway containing manipulated report identifiers. Secure Gateway, without validating these identifiers, constructs a REST API call to Splunk Enterprise using a system-level session token and executes the attacker-controlled request - allowing the attacker to extract the system token and subsequently modify platform-wide configuration or access sensitive indexed data across all Splunk indexes. No public proof-of-concept exploit code has been identified at time of analysis, but the attack requires only crafted HTTP data and a valid low-privilege credential.