CVE-2026-76319 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, a low-privileged user that does not hold the fsh_manage capability could perform Remote Code Execution through Federated Search bundle selection. This could allow for access to all relevant data and affect system integrity and availability. The vulnerability is possible because the Federated Search dispatch flow accepts caller-controlled bundle selection without enforcing the capability that manages federated providers and indexes. For more information see Security models for Federated Search for Splunk (https://help.splunk.com/en/splunk-enterprise/search/federated-search/10.4/run-federated-searches-across-other-splunk-deployments/service-accounts-and-security-for-federated-search-for-splunk/security-models-for-federated-search-for-splunk) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/20/2026
A critical security vulnerability exists within Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14, specifically affecting the Federated Search functionality. This flaw allows a low-privileged user who lacks the fsh_manage capability to achieve Remote Code Execution through malicious bundle selection during federated search operations. The vulnerability stems from an improper enforcement of access controls within the dispatch flow for federated searches. Specifically, the system accepts caller-controlled input regarding which data bundles or indexes should be queried without adequately verifying that the requesting user possesses the necessary permissions to manage federated providers and associated indexes. This gap in authorization logic effectively bypasses the intended security boundaries established by Splunk's role-based access control model.
The technical root cause lies in the failure of the application layer to validate the fsh_manage capability before processing requests related to bundle selection for federated searches. In a properly secured environment, users without this specific administrative privilege should be restricted from influencing which remote data sources are accessed or how search bundles are constructed and executed across distributed Splunk deployments. By allowing unprivileged actors to dictate these parameters, the system inadvertently permits them to inject malicious payloads or manipulate search logic in ways that lead to arbitrary code execution on the underlying host systems. This represents a significant deviation from secure coding practices where input validation and authorization checks must be strictly enforced at every stage of request processing, particularly when dealing with components that interact with external services or execute complex query operations.
The operational impact of this vulnerability is severe, as successful exploitation grants an attacker full remote code execution capabilities on the affected Splunk Enterprise instances. This level of access allows adversaries to compromise system integrity by modifying configurations, installing backdoors, or exfiltrating sensitive data stored within the platform. Furthermore, it impacts availability by enabling attackers to disrupt search services, consume excessive computational resources through resource exhaustion attacks, or render the instance unusable for legitimate users. Since Splunk often serves as a central repository for security telemetry and operational logs across an organization, compromising these systems can also hinder incident response efforts and obscure attacker activities within the broader network environment.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where a user is granted privileges that they should not possess due to insufficient authorization checks. Additionally, it relates to CWE-74, Improper Neutralization of Special Elements in Output Used by a Downstream Component, as the attacker leverages controlled input to influence downstream execution contexts. From an offensive security perspective, this exploit path corresponds to techniques found in the MITRE ATT&CK framework under Initial Access and Execution categories, particularly those involving trusted software vulnerabilities or command injection via administrative interfaces. The ability to escalate privileges from a low-privileged account to full system control underscores the critical nature of enforcing least privilege principles across all functional modules within enterprise security platforms.
To mitigate this risk, organizations running affected versions must immediately upgrade Splunk Enterprise to version 10.4.2 or later, where these authorization checks have been corrected. Until patching is complete, administrators should review user roles and capabilities to ensure that no low-privileged users are inadvertently assigned permissions related to federated search management. It is also advisable to restrict network access to the Splunk web interface and API endpoints to only trusted IP addresses and authorized personnel. Implementing strict input validation on all external-facing components and regularly auditing role definitions against industry standards such as CIS Benchmarks can further reduce the attack surface. Continuous monitoring for anomalous search patterns or unexpected privilege escalations within the Splunk audit logs will aid in detecting potential exploitation attempts before significant damage occurs.