CVE-2026-76258 in Splunk
Summary
by MITRE • 08/20/2026
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, and Splunk Secure Gateway versions below 3.10.10, 3.9.24, and 3.8.71, a user who does not hold the "admin" or "power" Splunk roles could register an arbitrary companion app and cause Splunk Secure Gateway to forward mobile user requests, including tokens that compromise all relevant data available to the affected mobile user, to an attacker-controlled Uniform Resource Locator (URL). The vulnerability is possible because a hard-coded cryptographic key in the Splunk Secure Gateway companion app registration handler allows for arbitrary callback URL registration without restriction. For more information see Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The identified vulnerability affects multiple versions of Splunk Enterprise and Splunk Secure Gateway, specifically impacting releases prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14 for the enterprise platform, as well as gateway versions below 3.10.10, 3.9.24, and 3.8.71. This security flaw represents a critical failure in access control mechanisms within the Splunk Secure Gateway companion app registration process. The core technical deficiency lies in the use of a hard-coded cryptographic key embedded directly into the application code for validating requests during the companion app registration phase. Because this secret is static and publicly discoverable or easily reverse-engineered from the binary, it fails to provide any meaningful authentication integrity check. Consequently, an attacker can craft valid-looking registration payloads that bypass all intended security checks, allowing them to register arbitrary callback URLs without requiring administrative privileges or elevated user roles such as admin or power.
From a technical perspective, this vulnerability is classified under CWE-287, which denotes Improper Authentication, and more specifically aligns with CWE-345 regarding Insufficient Verification of Data Authenticity. The absence of dynamic key management or secure random generation for the registration handshake means that any user account on the platform can exploit this flaw regardless of their assigned permissions. By leveraging the hard-coded key, an adversary can manipulate the configuration of the Splunk Secure Gateway to redirect sensitive traffic. This misconfiguration enables the interception and exfiltration of mobile user requests, which inherently contain authentication tokens necessary for accessing the Splunk environment. The ability to register arbitrary Uniform Resource Locators as callback endpoints effectively turns the gateway into a man-in-the-middle proxy controlled by an external actor rather than a secure tunneling mechanism.
The operational impact of this vulnerability is severe and directly compromises the confidentiality of data accessible to mobile users within the organization. When Splunk Secure Gateway forwards requests to an attacker-controlled URL, it includes session tokens that serve as credentials for subsequent API calls or web interactions. An adversary possessing these tokens can authenticate as the affected user without needing their password or multi-factor authentication codes. This leads to a complete bypass of identity verification controls and allows unauthorized access to all data sources, dashboards, and reports available to that specific mobile user profile. In environments where sensitive corporate intelligence, financial records, or proprietary research is stored in Splunk, this results in significant data breach consequences with potential regulatory implications under standards such as GDPR or HIPAA depending on the nature of the exposed information.
This attack vector maps closely to MITRE ATT&CK technique T1078, specifically Valid Accounts and T1528 Steal Application Access Token, illustrating how legitimate credentials are harvested through infrastructure manipulation rather than brute force or phishing. The exploitation path involves initial access via a low-privileged account followed by privilege escalation in terms of data exposure due to the misconfigured gateway behavior. To mitigate this risk, organizations must immediately upgrade Splunk Enterprise and Splunk Secure Gateway to the patched versions mentioned above where the hard-coded key has been replaced with secure dynamic authentication methods. Additionally, administrators should audit existing companion app registrations for any unauthorized callback URLs that may have been added prior to patching. Implementing network-level controls such as strict egress filtering can also limit the impact by preventing internal systems from communicating with untrusted external endpoints, thereby reducing the effectiveness of data exfiltration attempts even if an attacker successfully registers a malicious URL.