CVE-2026-76269 in Splunk
Summary
by MITRE • 10/07/2026
In Splunk Enterprise versions below 10.4.3, 10.2.7, 10.0.10, and 9.4.15, a user who does not hold the "admin" or "power" Splunk roles could use a user-controlled job identifier to access substantially all search job information from jobs that belong to other users, including search query text, job metadata, results, and preview results, through an Application Programming Interface (API) implemented as a Representational State Transfer (REST) API. The vulnerability is possible because the REST API does not fully validate job ownership before returning search job information.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The identified vulnerability in Splunk Enterprise versions prior to 10.4.3, 10.2.7, 10.0.10, and 9.4.15 represents a critical failure in access control mechanisms within the platform's REST API infrastructure. This flaw allows unprivileged users, specifically those lacking admin or power roles, to bypass intended security restrictions by manipulating user-controlled job identifiers. By supplying specific job IDs that belong to other users with higher privileges, an attacker can retrieve sensitive data associated with those search jobs. The scope of accessible information is extensive, encompassing the actual text of the search queries executed by privileged users, detailed metadata regarding when and how these searches were run, as well as the raw results and preview outputs generated from them. This capability effectively neutralizes the role-based access control model that Splunk relies upon to segregate data visibility among different user tiers within an organization.
From a technical perspective, this vulnerability stems directly from insufficient validation of job ownership during API request processing. When a REST API endpoint is invoked to retrieve search job information, it accepts a job identifier as input but fails to rigorously verify that the identity associated with the current session matches the owner of the specified job ID. Instead of checking for authorization permissions relative to the resource being accessed, the system appears to trust the provided identifier without cross-referencing it against the authenticated user's permission set or ownership records. This logic error enables a classic insecure direct object reference scenario where sequential or predictable identifiers can be iterated through by an attacker to enumerate and access data belonging to other users across the entire Splunk instance, assuming they have valid authentication credentials for any account with at least basic search capabilities.
The operational impact of this vulnerability is severe due to the nature of data typically processed within a SIEM environment like Splunk. Search queries often contain sensitive investigative logic, threat intelligence indicators, and internal network scanning parameters that reveal organizational security posture. The retrieval of job metadata can expose timelines of administrative actions or forensic investigations conducted by security teams. Most critically, access to search results means an attacker could exfiltrate personally identifiable information, financial records, health data, or proprietary business secrets stored within the indexed logs. This constitutes a significant breach of confidentiality and integrity, potentially leading to regulatory non-compliance under frameworks such as GDPR, HIPAA, or PCI-DSS depending on the data types present in the Splunk indexes.
In terms of industry standard classifications, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure to enforce proper authorization checks before granting access to resources. It also maps closely to CWE-639 Authorization Bypass Through User-Controlled Key, as the attacker leverages a user-controlled key (the job ID) to bypass security measures that should restrict data visibility based on role and ownership. Within the MITRE ATT&CK framework, this behavior is consistent with T1078 Valid Accounts, where an adversary uses legitimate credentials to access resources they are not authorized for, and potentially T1530 Data from Cloud Storage if the exfiltrated information involves cloud-based data sources indexed by Splunk. The attack vector allows for remote exploitation without requiring physical access or complex social engineering beyond initial credential theft or privilege escalation within a lower-level account.
Mitigation strategies must prioritize immediate patching to resolve this logic flaw in the REST API layer. Organizations running affected versions should upgrade to Splunk Enterprise version 10.4.3, 10.2.7, 10.0.10, or 9.4.15 as soon as possible to apply vendor-provided fixes that enforce strict ownership validation on all search job retrieval endpoints. In the interim, before patching is feasible, administrators should restrict network access to Splunk management ports using firewalls and implement strong authentication mechanisms such as multi-factor authentication for all user accounts. Additionally, auditing logs should be monitored closely for unusual patterns of API calls involving frequent requests for different job IDs by non-privileged users, which may indicate active exploitation attempts. Role assignments should also be reviewed to ensure that only essential personnel have access to sensitive indexes and data models, thereby limiting the blast radius if a lower-level account is compromised.