CVE-2026-76353 in Splunk
Summary
by MITRE • 08/19/2026
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could submit a crafted knowledge bundle delta to delete arbitrary files accessible to Splunk Enterprise on a cluster manager. This could affect system integrity and disrupt service. The vulnerability is possible because knowledge bundle delta processing does not restrict removal paths to the staging directory and the endpoint does not enforce the expected authorization boundary. For more information see Knowledge bundle replication overview (https://help.splunk.com/en/splunk-enterprise/administer/distributed-search/10.4/knowledge-bundle-replication/knowledge-bundle-replication-overview) in the Splunk documentation.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The identified vulnerability in Splunk Enterprise versions prior to 10.4.2, 10.2.6, 10.0.9, and 9.4.14 represents a critical failure in access control mechanisms within the knowledge bundle replication subsystem. This flaw allows unprivileged users, specifically those lacking admin or power roles, to execute arbitrary file deletion operations on cluster managers by submitting crafted knowledge bundle deltas. The core technical deficiency lies in the processing logic for these delta updates, which fails to enforce strict path restrictions that confine removals exclusively to designated staging directories. Furthermore, the endpoint responsible for handling these requests does not adequately validate the authorization boundary required for such destructive actions, effectively bypassing standard role-based access controls designed to protect system integrity.
From a technical perspective, this vulnerability is classified under CWE-269, which denotes Improper Privilege Management, as it allows lower-privileged entities to perform high-level administrative functions without proper verification. Additionally, the exploitation technique aligns with CWE-732, describing Incorrect Permission Assignment for Critical Resource, because the system fails to restrict file operations to expected safe paths. The ability to delete arbitrary files accessible to Splunk Enterprise on a cluster manager poses severe risks to operational continuity and data integrity. An attacker could leverage this flaw to remove critical configuration files, application binaries, or log archives, leading to service disruption, denial of service conditions, or potentially creating an environment conducive to further exploitation by compromising the underlying operating system's stability through resource exhaustion or missing dependencies.
The impact extends beyond simple file deletion; it undermines the trust model inherent in Splunk’s distributed search architecture where cluster managers coordinate state across multiple nodes. By manipulating knowledge bundles, which are typically used for distributing configuration updates and app packages, an attacker can introduce malicious states that persist even after remediation if not properly audited or restored from backups. This vulnerability highlights a significant gap in the validation of input data within the replication pipeline, where path traversal logic is either absent or incorrectly implemented to allow escape from sandboxed directories into broader filesystem paths accessible by the Splunk service account.
To mitigate this risk, organizations must immediately upgrade their Splunk Enterprise instances to version 10.4.2, 10.2.6, 10.0.9, or 9.4.14 or later, as these releases contain patches that enforce stricter path validation and correct the authorization boundary checks for knowledge bundle delta processing. In environments where immediate patching is not feasible, administrators should restrict network access to the Splunk management interfaces to trusted subnets only, ensuring that untrusted users cannot submit crafted requests to the affected endpoints. Additionally, implementing robust monitoring for unusual file system changes on cluster managers and auditing user activity related to knowledge bundle submissions can help detect potential exploitation attempts before significant damage occurs. Regular review of role permissions is also advised to ensure that no unnecessary privileges are granted to non-administrative accounts within the Splunk platform.