CVE-2026-76338: Improper Authentication through REST API Distributed Search Token Requests in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has access to a trusted distributed search private key could forge an administrative session token, access all relevant data, affect system integrity, and disrupt service availability. The vulnerability is possible because the distributed search authentication token endpoint does not require a signed request to identify a configured search peer, allowing the request to fall back to shared local key material. For more information see About distributed search (https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/10.4/overview-of-distributed-search/about-distributed-search) and authentication.conf (https://help.splunk.com/en/splunk-enterprise/administer/admin-manual/10.4/configuration-file-reference/10.4.2-configuration-file-reference/authentication.conf) in Splunk documentation.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 10.4.2 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 10.2.6 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 10.0.9 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 9.4.14 - Configuration
Set strictPeerNameValidation = true in authentication.conf on every distributed node, then restart Splunk Enterprise.
Splunk Enterprise (distributed search) authentication.conf strictPeerNameValidation = true
Event History
Frequently Asked Questions
What must an attacker obtain to exploit this issue?
The attacker must have access to a trusted distributed search private key. They do not need an authenticated Splunk account or user interaction.
Which deployments are exposed?
Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14 are affected where a trusted distributed search private key is accessible to an unauthenticated attacker.
What access could successful exploitation provide?
An attacker could forge an administrative session token. This could allow access to relevant data, modification of system integrity, and disruption of service availability.
What should be done if immediate upgrading is not possible?
The provided information identifies access to a trusted distributed search private key as the exploitation prerequisite. Restricting and protecting access to that key can reduce exposure, but the data does not provide a complete workaround.