CVE-2026-76341
MediumCVSS 5.4Exploitation Probability (EPSS)
Low risk13th percentile - higher than 13% of all known CVEs
Summary
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user with the "power" role can store attacker-controlled SPL in a Table Editor dataset and share it. When an "admin" user opens the dataset, the SPL executes with the admin's permissions, potentially exposing data and allowing limited modification. The vulnerability is due to missing SPL safeguards for risky commands in the Table Editor.
Risk Assessment
An attacker could access data available to the admin or modify it, posing a serious threat to data confidentiality and integrity. However, this requires phishing the admin to initiate a request in their browser.
Recommendation
Immediately upgrade Splunk Enterprise to version 10.4.2, 10.2.6, 10.0.9, or 9.4.14 (or later). Additionally, exercise caution with shared datasets and links to mitigate phishing risks.
Other vulnerabilities in Splunk Enterprise
See all- CVE-2026-76268Critical
Vulnerability in Splunk Enterprise before versions 10.4.3 and 10.2.7 allows an unauthenticated user with network access to the Patroni REST API on a search head cluster member to execute attacker-controlled OS commands. The interface does not require authentication for critical configuration operations.
- CVE-2026-76312Critical
In Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who can read the Hypertext Markup Language (HTML) source of a page that embeds a Splunk report could use exposed session material to access all relevant data and affect system integrity. The vulnerability is possible because the dispatch archive download path does not correctly enforce the embedded-report authorization boundary and includes sensitive session material in archived search-job data.
- CVE-2026-76311Critical
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has an embedded report token could download the dispatch archive for an embedded report search job and use exposed session material to access all relevant data and affect system integrity on the Splunk platform instance. The vulnerability is possible because the embedded report authorization flow does not block dispatch archive download requests before Splunk Enterprise begins sending the archive to the requester.
- CVE-2026-76310Critical
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has an embedded report token could download the associated search job dispatch archive, recover session material, and use it to access all relevant data available to the report owner and affect system integrity, including by performing administrative actions when the owner holds the "admin" Splunk role. The vulnerability is possible because embedded report access does not block Representational State Transfer (REST) API dispatch archive download requests.
- CVE-2026-20253CriticalActively exploited
In Splunk Enterprise 10.2 before 10.2.4 and 10.x before 10.0.7, an unauthenticated user can create or truncate arbitrary files via a PostgreSQL sidecar service endpoint. The endpoint lacks authentication.
- CVE-2026-76298High
In Splunk Enterprise versions below 10.4.4 and 10.2.8, a user without the admin or power Splunk roles could derive the PostgreSQL sidecar database superuser password and run arbitrary OS commands as the account running Splunk Enterprise on search head cluster members. The flaw exists because the PostgreSQL sidecar service derives a privileged database password from the search head cluster identifier that appears in search job logs.
- CVE-2026-76297Medium
In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, an unauthenticated user could trick a user holding the edit_federated_providers capability into turning off all federated search providers. This is possible because the federated provider REST API accepts GET requests for state-changing actions, and exploitation requires phishing the affected user.
- CVE-2026-76296Medium
In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the "admin" or "power" Splunk roles could create, move, edit, or delete sourcetype renaming configurations that they own in apps that they do not have permission to access. The vulnerability is possible when Splunk Web is turned on because Splunk Web does not verify the required app permissions before it performs sourcetype renaming operations.
- CVE-2026-76295Medium
In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, and Splunk Secure Gateway versions below 3.10.12, 3.9.26, and 3.8.73, a user without the "admin" or "power" roles could view dashboard and report listings beyond the requested filter scope while remaining within accessible objects. The vulnerability exists because Splunk Secure Gateway does not neutralize special characters in values before creating filters.
- CVE-2026-76294Medium
In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the "admin" or "power" Splunk roles could move field extractions or field transformations to apps for which the user does not have read access. The vulnerability is possible because the Representational State Transfer (REST) API does not validate destination app access before it processes field extraction and field transformation move operations.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS