Description

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 write dispatch metadata to an arbitrary location on the host by supplying a crafted search identifier to a Representational State Transfer (REST) API endpoint and affect system integrity on the host. The vulnerability is possible because Splunk Enterprise does not validate the search identifier before using it to create a dispatch directory. For more information see 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) in the Splunk documentation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-08-19T22:17:19.150Z",
  "pubdate": "2026-08-19T22:17:19.150Z",
  "executiveSummary": "Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14 contain an arbitrary file write vulnerability that affects system integrity on the underlying host.\nThe vulnerability allows an authenticated user lacking the \"admin\" or \"power\" Splunk roles to write dispatch metadata to arbitrary file system locations.\nThis security flaw stems from an insufficient validation mechanism within a Representational State Transfer (REST) API endpoint, which processes user-supplied search identifiers without adequate sanitization before constructing dispatch directories.\nSuccessful exploitation enables malicious actors with standard user privileges to manipulate host file systems, potentially leading to unauthorized data modification or other system integrity impacts.\nRemediation requires upgrading Splunk Enterprise to the patched version releases designated by the vendor.",
  "technicalDetails": "The root cause of the vulnerability resides in the lack of input validation for search identifiers submitted to a specific Representational State Transfer (REST) API endpoint within Splunk Enterprise.\nWhen a user supplies a crafted search identifier to the vulnerable REST API endpoint, the application fails to validate or sanitize the string before utilizing it to construct file system paths for creating a dispatch directory.\nBecause the search identifier is incorporated directly into file system operations, directory traversal sequences or absolute paths within the crafted identifier allow the application to write dispatch metadata outside the intended search artifact directory.\nThe affected component is responsible for handling search dispatch metadata generation and directory initialization within Splunk Enterprise.\nAffected versions include Splunk Enterprise instances below 10.4.2, 10.2.6, 10.0.9, and 9.4.14.\nAuthentication is required to access the REST API endpoint, but the vulnerability can be triggered by users who do not hold elevated privileges such as the \"admin\" or \"power\" Splunk roles.\nThe attack flow proceeds as follows: 1) An authenticated low-privileged user constructs a malicious search identifier containing path traversal or targeted directory placement payloads. 2) The user submits this crafted identifier via an HTTP request to the vulnerable Representational State Transfer (REST) API endpoint. 3) The backend Splunk Enterprise process accepts the search identifier without input validation. 4) The application uses the unsanitized identifier to programmatically create a dispatch directory and write dispatch metadata. 5) The metadata is written to an arbitrary location on the host file system specified by the payload.\nThe post-exploitation impact includes compromised system integrity on the host through unauthorized file creation or overwriting of arbitrary files accessible to the Splunk service account."
}