CVE-2026-76261 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.9, 3.9.23, and 3.8.70, a user who does not hold the "admin" or "power" Splunk roles could read Spacebridge asymmetric private keys, which are secrets that compromise affected Spacebridge private-key material stored in the app collection, through the Splunk Secure Gateway App Key Value Store Representational State Transfer (REST) API. The vulnerability is possible on instances upgraded from older Splunk Secure Gateway deployments when the private-key migration remains incomplete, leaving key material in a collection with an insecure default access control list.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
A critical security flaw has been identified within specific versions of Splunk Enterprise and Splunk Secure Gateway that allows unauthorized users to exfiltrate sensitive cryptographic materials. The vulnerability affects Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14, as well as Splunk Secure Gateway versions before 3.10.9, 3.9.23, and 3.8.70. The core issue lies in the handling of Spacebridge asymmetric private keys, which are essential secrets used for secure communications within the Splunk ecosystem. These keys represent high-value targets for attackers because their compromise can lead to a complete breakdown of confidentiality and integrity for data transmitted through these channels.
The technical root cause is tied to an incomplete migration process during upgrades from older deployments of Splunk Secure Gateway. When instances are upgraded, private-key material should be migrated securely into protected storage mechanisms with strict access controls. However, in certain scenarios where this migration remains incomplete or fails silently, the key material persists in a legacy app collection that retains insecure default access control lists. This misconfiguration means that the sensitive cryptographic keys are not properly isolated from standard application users who lack administrative privileges.
The operational impact of this vulnerability is severe because it bypasses the intended role-based access controls designed to protect secrets. A user account without admin or power roles, which would normally be restricted from accessing internal system configurations and secrets, can exploit the Splunk Secure Gateway App Key Value Store Representational State Transfer API to read these Spacebridge asymmetric private keys. By leveraging this REST API endpoint, an attacker with low-level privileges can retrieve the private key material stored in the vulnerable collection. This effectively elevates their privilege level regarding sensitive data access without requiring authentication as a high-privilege user.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if the keys are treated as static secrets exposed via API. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1552 Unsecured Credentials, specifically the sub-technique for accessing private keys or certificates stored on a local system. The exploitation path involves using valid but insufficient credentials to access sensitive information that should be restricted, highlighting a failure in enforcing least privilege principles during state transitions like software upgrades.
To mitigate this risk, organizations must immediately upgrade their Splunk Enterprise and Splunk Secure Gateway installations to the specified patched versions or later. It is crucial to verify that any previous instances have completed the private-key migration process successfully. Administrators should audit existing deployments for incomplete migrations by checking app collections for lingering key material that may not be properly secured. Additionally, implementing strict monitoring on REST API calls related to the Key Value Store can help detect unauthorized access attempts while patches are being applied. Ensuring that default access control lists do not apply to sensitive cryptographic stores is vital for maintaining the integrity of the security architecture in Splunk environments.