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 inject arbitrary Search Processing Language (SPL) commands through the geostats command. The injected SPL runs with the permissions of another authenticated user after that user initiates the attacker-controlled geostats search in Splunk Web. The injected SPL could expose all relevant data available to the second user, including stored credentials, and modify lookup files that the second user has permission to change. The vulnerability is possible because the geostats command does not sufficiently validate input before Splunk Enterprise processes it. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who does not hold the "admin" or "power" Splunk roles should not be able to exploit the vulnerability at will. For more information see geostats (https://help.splunk.com/en/splunk-enterprise/spl-search-reference/10.0/search-commands/geostats) in the Splunk documentation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-08-19T22:17:18.490Z",
  "pubdate": "2026-08-19T22:17:18.490Z",
  "executiveSummary": "Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14 contain an improper input validation vulnerability within the geostats command that enables unauthorized Search Processing Language (SPL) injection.\nThe vulnerability allows a low-privileged user lacking \"admin\" or \"power\" roles to craft malicious search strings containing arbitrary SPL commands.\nSuccessful exploitation requires a phishing vector where an attacker tricks a second authenticated user into executing an attacker-controlled geostats search via Splunk Web within their browser.\nWhen the victim initiates the crafted search, the injected SPL executes under the security context and permissions of the victimized user.\nThe primary impact includes the potential exposure of all relevant data accessible to the second user—including stored credentials—as well as the unauthorized modification of lookup files that the victim has permissions to alter.\nThis vulnerability bridges privilege boundaries indirectly via user interaction, posing significant risks to data confidentiality and integrity across affected Splunk Enterprise deployments.",
  "technicalDetails": "The root cause of the vulnerability stems from insufficient input validation within the geostats search command component of Splunk Enterprise before processing user-supplied parameters.\nThe affected product is Splunk Enterprise, specifically targeting versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14.\nThe vulnerable component is the geostats command processor, documented at https://help.splunk.com/en/splunk-enterprise/spl-search-reference/10.0/search-commands/geostats.\nPrivilege and authentication requirements dictate that the initial attacker holds restricted privileges without possessing the \"admin\" or \"power\" Splunk roles, meaning they cannot independently execute the malicious SPL at will without external interaction.\nThe attack flow proceeds as follows: First, an attacker lacking administrative or power privileges formulates an arbitrary Search Processing Language (SPL) injection payload embedded within a crafted geostats search query. Second, the attacker deploys a phishing vector to deceive an authenticated target user—potentially one with higher privileges or broader data access—into clicking a specially crafted link or initiating a request within Splunk Web via their browser. Third, when the victim initiates the attacker-controlled geostats search, Splunk Enterprise processes the input without adequate validation. Finally, the injected SPL executes with the execution context and authorization credentials of the victimized authenticated user.\nPayload behavior and post-exploitation impact involve the unauthorized execution of arbitrary search commands leveraging the victim's session. This execution path can expose sensitive data accessible to the second user, such as stored credentials, and facilitate the unauthorized modification of lookup files that fall within the scope of the victim's access permissions."
}