CVE-2026-76322: Splunk Enterprise Auth Bypass Vulnerability

CVE-2026-76322 Overview

CVE-2026-76322 is an authorization flaw in Splunk Enterprise Dashboard Studio that allows a low-privileged user holding the user Splunk role to craft a dashboard executing attacker-controlled Search Processing Language (SPL) in the context of another authenticated user. The issue exists because Dashboard Studio does not consistently enforce the expected app-visibility authorization boundary before dashboard search query options reach search dispatch. Successful exploitation requires the victim to be tricked into initiating a request within their browser, meaning phishing or social engineering is a prerequisite. The vulnerability is tracked under CWE-862: Missing Authorization.

Critical Impact
Attackers can execute SPL as a higher-privileged authenticated user, gaining access to all data available to that user and affecting system integrity and availability.

Affected Products

Splunk Enterprise versions below 10.4.2
Splunk Enterprise versions below 10.2.6
Splunk Enterprise versions below 10.0.9 and 9.4.14

Discovery Timeline

2026-08-19 - CVE CVE-2026-76322 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-76322

Vulnerability Analysis

Splunk Dashboard Studio provides search-based visualizations using the ds.search data source. This vulnerability arises when a user with the low-privileged user role authors a Dashboard Studio dashboard containing SPL query options that bypass the normal app-visibility authorization checks. When another authenticated user, typically one with broader data access, is coerced into loading the malicious dashboard, the attacker-controlled SPL is dispatched under the victim's identity.

The attacker inherits the victim's data-access rights for the duration of the search. This enables unauthorized reads of any indexed data the victim can view, plus writes and configuration changes achievable through SPL commands such as outputlookup, collect, or sendemail. The requirement for user interaction narrows the exploit path but does not eliminate risk in environments where analysts routinely open shared dashboards.

Root Cause

Dashboard Studio does not consistently enforce the app-visibility authorization boundary before passing dashboard search query options to search dispatch. The authorization check that should validate whether the requesting user is permitted to run the specified SPL within the given app context is inconsistently applied, allowing a crafted dashboard to smuggle SPL past the boundary.

Attack Vector

The attack proceeds in three stages. First, an attacker holding the user Splunk role authors a Dashboard Studio dashboard embedding malicious SPL through the ds.search data source. Second, the attacker phishes a higher-privileged authenticated Splunk user, tricking them into loading the dashboard in their browser. Third, when the victim's browser renders the dashboard, the SPL is dispatched under the victim's context, granting the attacker indirect access to all data and operations the victim can perform. For technical background, see Create search-based visualizations with ds.search in the Splunk documentation.

No public proof-of-concept code exists for this vulnerability as of publication. See the Splunk Security Advisory SVD-2026-0801 for vendor guidance.

Detection Methods for CVE-2026-76322

Indicators of Compromise

Dashboard Studio dashboards authored by low-privileged user role accounts that contain ds.search data sources targeting indexes or apps outside their authoring scope.
Search dispatch entries in audit.log where the executing user's role differs from the dashboard owner's role and SPL contains commands like outputlookup, collect, or sendemail.
Unexpected browser-initiated dashboard loads followed by high-volume or high-privilege searches shortly after a phishing email or shared link.

Detection Strategies

Review the _audit index for search activity where info=granted and the dashboard source path indicates a user-role authored Studio dashboard being loaded by administrators or power users.
Correlate dashboard view events with subsequent search dispatch to identify SPL that reads or writes indexes not normally accessed by the viewing user.
Baseline dashboard authorship patterns and alert on new Studio dashboards created by user role accounts that contain search commands with data-modification side effects.

Monitoring Recommendations

Enable and forward Splunk audit.log and _internal search activity to a centralized log store for cross-correlation with authentication and email gateway events.
Monitor for phishing indicators such as inbound emails or chat messages containing links to internal Splunk dashboard URLs.
Track privileged user browser sessions that dispatch unusually broad searches immediately after loading dashboards authored by lower-privileged accounts.

How to Mitigate CVE-2026-76322

Immediate Actions Required

Upgrade Splunk Enterprise to version 10.4.2, 10.2.6, 10.0.9, 9.4.14, or later per the vendor advisory.
Audit existing Dashboard Studio dashboards authored by non-privileged users and remove or quarantine any containing suspicious SPL.
Communicate to Splunk administrators and analysts that they should avoid opening unsolicited dashboard links until patching completes.

Patch Information

Splunk has released fixed builds addressing the authorization boundary enforcement in Dashboard Studio. Refer to Splunk Security Advisory SVD-2026-0801 for exact fixed versions per release branch and download links.

Workarounds

Restrict Dashboard Studio authoring capabilities so that only trusted roles can create dashboards using the ds.search data source.
Enforce app-visibility and role-based access controls to limit what SPL commands the user role can invoke, particularly write-capable commands.
Deploy phishing-resistant controls such as URL rewriting, warnings on internal dashboard links from external sources, and user awareness training focused on Splunk-hosted content.

bash

# Example: restrict the 'user' role from running data-modifying search commands
# Edit $SPLUNK_HOME/etc/system/local/authorize.conf
[role_user]
srchFilter = NOT (index=sensitive_*)
cumulativeRTSrchJobsQuota = 0
# Remove capabilities that allow writing via SPL
# schedule_search, edit_lookups, and similar should not be granted