Description

In Splunk Enterprise versions below 10.4.2 and 10.2.6, a user who does not hold the "admin" or "power" Splunk roles could delete all Search Processing Language 2 (SPL2) modules across all apps and users on the instance through the SPL2 module management Representational State Transfer (REST) API. This could delete exported datasets and functions, affect system integrity, and cause partial service disruption. The vulnerability does not affect Splunk Enterprise versions below 10.2. The vulnerability is possible because the SPL2 module management REST API does not sufficiently authorize and validate module deletion requests. For more information see Manage SPL2 modules (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/multiple-searches-in-an-spl2-module/manage-spl2-modules) and Module permissions (https://help.splunk.com/en/splunk-enterprise/search/spl2-search-manual/modules-statements-and-views/module-permissions) in the Splunk documentation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-19T22:17:18.093Z",
  "pubdate": "2026-08-19T22:17:18.093Z",
  "executiveSummary": "This vulnerability involves an improper authorization and validation flaw within the SPL2 module management Representational State Transfer (REST) API of Splunk Enterprise. Specifically, users lacking administrative or power privileges can interact with the endpoint to execute destructive operations.\nThe primary impact of successful exploitation is the unauthorized deletion of all Search Processing Language 2 (SPL2) modules across all applications and users on the targeted Splunk instance, which can result in the loss of exported datasets, functions, compromised system integrity, and partial service disruption.\nAffected systems include Splunk Enterprise versions below 10.4.2 and 10.2.6 (excluding versions below 10.2).\nThe risk implications are severe regarding data loss and operational availability, as unauthorized low-privileged internal actors or compromised accounts can wipe critical analytical components.\nAttacker capabilities require access to the Splunk instance with a standard, non-privileged user account that neither holds the admin nor the power Splunk roles.\nExploitation requirements are limited to authenticated network access to the vulnerable SPL2 module management REST API, leveraging the absence of strict access control enforcement during module deletion requests.",
  "technicalDetails": "The root cause of the vulnerability resides within the SPL2 module management Representational State Transfer (REST) API of Splunk Enterprise. The affected component fails to sufficiently authorize and validate incoming module deletion requests.\nSpecifically, the API logic does not adequately verify whether the issuing security context possesses the necessary administrative or power roles prior to processing the deletion commands.\nThe vulnerable component is the SPL2 module management endpoint exposed via the Representational State Transfer (REST) API within Splunk Enterprise.\nAffected versions are explicitly identified as Splunk Enterprise versions below 10.4.2 and 10.2.6, while versions below 10.2 remain unaffected.\nAuthentication requirements dictate that the attacker must possess a valid user account on the target Splunk Enterprise instance.\nPrivilege requirements are low; the exploiting user does not hold the admin or power Splunk roles, representing a clear privilege-boundary violation where standard users can perform privileged administrative deletions.\nNetwork exposure is defined by accessibility to the Splunk Enterprise instance and its internal or exposed REST API interfaces.\nThe attack flow proceeds step-by-step as follows: First, an authenticated user lacking administrative privileges crafts and sends an HTTP request targeting the vulnerable SPL2 module management REST API endpoint. Second, the API receives the module deletion request. Third, due to insufficient authorization checks and lack of granular parameter validation, the application fails to validate the user's role against the required administrative threshold. Fourth, the backend processes the request and executes the deletion logic across the entire instance. Finally, all Search Processing Language 2 (SPL2) modules across all apps and users are systematically deleted.\nThe post-exploitation impact includes the permanent deletion of exported datasets and functions tied to the removed SPL2 modules, system integrity degradation, and partial or total service disruption of search capabilities relying on SPL2."
}