CVE-2026-76345 in Splunk
Summary
by MITRE • 08/20/2026
In Splunk Enterprise versions below 10.4.2, a user with a high-privilege Splunk role that can manage search head clustering could use the search head cluster member bundle Representational State Transfer (REST) API to write files to locations that the user account running Splunk Enterprise can write to, which could allow for remote code execution. Successful exploitation could result in access to all relevant data and could affect the integrity and availability of the Splunk deployment. The vulnerability does not affect Splunk Enterprise versions below 10.4. The vulnerability is possible because the search head cluster member bundle REST API does not enforce the expected authorization boundary and does not validate bundle paths before accepting bundle content. For more information see Using the REST API reference (https://help.splunk.com/en/splunk-enterprise/rest-api-reference/10.2/introduction/using-the-rest-api-reference), About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access), and About distributed search (https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/9.4/overview-of-distributed-search/about-distributed-search) in the Splunk documentation.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/20/2026
A critical security vulnerability exists within Splunk Enterprise versions prior to 10.4.2, specifically affecting systems configured with search head clustering. This flaw allows a user possessing high-privilege roles capable of managing search head clusters to exploit weaknesses in the REST API interface used for handling cluster member bundles. The core technical deficiency lies in the failure of the application to enforce proper authorization boundaries and validate file paths before accepting bundle content. Consequently, an authenticated attacker with sufficient privileges can manipulate the input parameters associated with the search head cluster member bundle endpoint to write arbitrary files to any directory location where the underlying Splunk Enterprise service account has write permissions. This lack of path validation effectively bypasses intended security controls designed to restrict file system access based on role-based policies.
The operational impact of this vulnerability is severe, as it directly facilitates remote code execution within the context of the user running the Splunk process. By writing executable scripts or malicious configuration files to accessible directories, an attacker can achieve arbitrary command execution on the host operating system. This capability compromises the confidentiality, integrity, and availability of the entire Splunk deployment. Accessing all relevant data becomes trivial once remote code execution is achieved, potentially exposing sensitive logs, proprietary information, and critical business intelligence stored within the platform. Furthermore, the ability to modify or delete files can lead to service disruption, effectively rendering the logging and monitoring infrastructure unavailable for operational purposes.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves unauthorized access to system resources due to insufficient enforcement of security policies. It also relates closely to CWE-732 Incorrect Permission Assignment for Critical Resource, given the ability to write files to unintended locations based on file system permissions rather than application-level restrictions. In terms of adversary tactics, this exploit maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter, which describes how attackers execute commands via scripts or interpreters after gaining initial access. The attack vector leverages the REST API, corresponding to T1190 Exploit Public-Facing Application, although it requires prior authentication with elevated privileges rather than being fully unauthenticated.
Mitigation strategies must prioritize immediate software updates for all affected environments. Organizations running Splunk Enterprise versions below 10.4.2 should upgrade to version 10.4.2 or later as soon as possible to apply the vendor-patched fixes that enforce strict path validation and correct authorization checks on the cluster bundle API endpoints. In cases where immediate patching is not feasible, administrators should implement network-level controls such as firewalls or access control lists to restrict REST API access exclusively to trusted management subnets and authorized administrative IP addresses. Additionally, enforcing least-privilege principles by reviewing and restricting roles that possess search head cluster management capabilities can reduce the attack surface. Regular auditing of user permissions and monitoring for unusual file system write activities in Splunk installation directories provide additional layers of defense against exploitation attempts.