Description

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could store attacker-controlled Search Processing Language (SPL) in a Table Editor dataset and share the dataset. A user who holds the "admin" Splunk role triggers the SPL when that user opens the dataset in the Table Editor. The SPL runs using the permissions of the second user and could expose all relevant data and modify limited data on the search head. The vulnerability is possible because the Table Editor does not apply SPL safeguards for risky commands when it prepares the dataset initial data. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see Define initial data for a new table dataset (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/9.4/create-and-edit-table-datasets/define-initial-data-for-a-new-table-dataset), SPL safeguards for risky commands (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/best-practices-for-splunk-platform-security/spl-safeguards-for-risky-commands), 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-08-19T22:17:18.750Z",
  "pubdate": "2026-08-19T22:17:18.750Z",
  "executiveSummary": "A privilege escalation and arbitrary Search Processing Language (SPL) execution vulnerability exists in Splunk Enterprise Table Editor datasets.\nThe vulnerability affects Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14.\nThe flaw allows an authenticated user assigned the 'power' Splunk role to store attacker-controlled SPL within a shared Table Editor dataset.\nWhen a user with the 'admin' Splunk role opens the shared dataset in the Table Editor, the stored SPL executes automatically using the administrative user's elevated permissions.\nSuccessful exploitation can lead to the exposure of sensitive data and limited data modification on the search head.\nThe vulnerability stems from the Table Editor component failing to apply standard SPL safeguards for risky commands during the preparation of initial dataset data.\nExploitation requires user interaction via phishing, wherein the attacker must trick the administrative user into initiating a request within their browser.\nBecause the vulnerability requires social engineering and relies on a victim to trigger the payload, the attacker cannot exploit the vulnerability completely at will.",
  "technicalDetails": "The root cause of the vulnerability resides in the Table Editor component of Splunk Enterprise, which fails to enforce SPL safeguards for risky commands when preparing the initial data for a new table dataset.\nThe affected product is Splunk Enterprise, specifically versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14.\nThe attack vector requires authentication and involves cross-user privilege abuse facilitated by social engineering (phishing).\nThe threat actor must hold the 'power' Splunk role to create and share a malicious Table Editor dataset containing attacker-controlled SPL.\nThe attack flow proceeds as follows: First, the attacker crafts a Table Editor dataset containing malicious, unfiltered SPL that bypasses standard risky command restrictions. Second, the attacker shares this dataset with other users. Third, the attacker initiates a phishing attack to trick a user holding the 'admin' Splunk role into opening the dataset within the Table Editor via their browser. Fourth, upon opening the dataset, the underlying application triggers the execution of the stored SPL. Fifth, because the request is processed in the context of the victim, the SPL executes with the elevated privileges of the 'admin' user rather than the restricted 'power' user.\nThe payload behavior includes executing arbitrary search commands that bypass native security controls designed to restrict risky SPL commands.\nThe post-exploitation impact includes the exposure of all relevant data accessible to the administrator and the capability to modify limited data on the search head.\nPrerequisites for exploitation include an authenticated attacker with a 'power' role, a targeted user with an 'admin' role, and successful social engineering to induce the administrator to trigger the request."
}