Splunk Secure Gateway CVE-2026-76257

Exploitation requires an authenticated Splunk account holding a role with the 'list storage passwords' permission - this is not a default end-user capability and typically indicates elevated, though not administrative, access. The attacker does NOT need Splunk Secure Gateway administration privileges; the absence of that check is the vulnerability. Splunk Secure Gateway must be deployed and actively used with MDM functionality for the exposed secrets to have downstream impact. Network access to the Splunk REST API interface (default port 8089) is required. Exploitation is limited to network-reachable instances and cannot be performed anonymously; unauthenticated access is blocked by Splunk's core authentication layer. Non-default configurations that remove or restrict the 'list storage passwords' role capability, or that restrict Secure Gateway REST API endpoint reachability, reduce exposure.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects a network-reachable, low-complexity flaw requiring only low-level authentication - consistent with the real-world exploitation path of an insider or compromised low-privilege account invoking unauthenticated-to-SGW REST endpoints over the network. The CVSS score of 6.5 is proportionate: the impact is confidentiality-only at the Splunk system level, though downstream integrity impact on the MDM ecosystem is significant and understated by the S:U scope designation. No EPSS score was provided in the source data, and no KEV listing exists, suggesting exploitation has not been observed at scale as of the analysis date. The attack complexity is genuinely low once the prerequisite role is held - no chaining, race conditions, or additional steps are required. The primary limiting factor is the need for an existing authenticated Splunk account with the 'list storage passwords' capability, making this primarily an insider threat or post-initial-compromise escalation vector rather than an external attack path. Organizations running Splunk Secure Gateway with MDM integration should treat this as high-priority due to the trust-breaking downstream impact on device enrollment.

An attacker with a Splunk account granted the 'list storage passwords' capability - obtained through a compromised employee account or via insider access - sends a crafted HTTP request to one of the unprotected Splunk Secure Gateway REST API endpoints (such as the deployment bundle or SAML setup endpoint) over the network. Without requiring Secure Gateway administration privileges, the endpoint processes the request and returns MDM signing secrets. The attacker then uses those secrets to enroll attacker-controlled mobile devices into the organization's MDM environment, bypassing device trust controls and gaining persistent access to corporate mobile resources. No public proof-of-concept code has been identified, but the attack requires no special tooling beyond standard HTTP capabilities.