Splunk Secure Gateway EUVD-2026-63110

Exploitation requires an authenticated Splunk session held by any standard user account - the CVE description explicitly states that users who do NOT hold the 'admin' or 'power' roles are the threat actors, meaning the lowest tier of Splunk user is sufficient. Splunk Secure Gateway must be installed, running, and actively used for Splunk Mobile connectivity; deployments that do not use Secure Gateway or Splunk Mobile are entirely unexposed. The attacker must be able to reach the Splunk Secure Gateway companion app registration endpoint over the network (consistent with AV:N). Post-registration, the token exfiltration is passive - the attacker does not need to take further action, as tokens are forwarded automatically when legitimate mobile users authenticate. Exploitation is bounded by the requirement for an existing authenticated Splunk account of any privilege level, meaning unauthenticated external attackers cannot exploit this directly and the primary risk surface is malicious insiders and accounts compromised via external means.

The CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects network-accessible exploitation by any low-privileged authenticated user with no user interaction required and high confidentiality impact through token theft. The vendor's S:U (unchanged scope) assignment may understate the true impact: the attacker's own account suffers no direct harm - rather, tokens belonging to entirely separate mobile users are exfiltrated - which is a textbook scope-change scenario, and an independent assessment of S:C appears more accurate. No EPSS data was provided in the source intelligence. The vulnerability does not appear in CISA KEV, confirming no active exploitation at time of analysis. Notably, the input tags include 'RCE,' which is inconsistent with the CVE description; the actual impact is credential and token theft, not remote code execution - analysts should not treat this as an RCE and should verify whether this tag is a misclassification in upstream sources. The primary limiting factor is the requirement for an existing low-privileged Splunk account, meaning purely unauthenticated external exploitation is not possible; the realistic threat actor is a malicious insider, a compromised service account, or an attacker who has already obtained any Splunk credentials through phishing or credential stuffing.

An attacker holding any low-privileged Splunk account (e.g., a read-only analyst or compromised service account) authenticates to Splunk and sends a crafted companion app registration request to the Splunk Secure Gateway endpoint, exploiting the hard-coded cryptographic key to register an attacker-controlled HTTPS server as a callback URL. Once registered, all subsequent mobile authentication requests from legitimate Splunk Mobile users are transparently forwarded - including their session tokens - to the attacker's server, granting the attacker access to all Splunk data and capabilities available to those mobile users without triggering any further authentication challenge. No public exploit code has been confirmed at time of analysis, but the technique requires only knowledge of the static key and low-privileged network access to the Splunk instance.