CVE-2026-76322 is a medium severity (6.7) missing authorization flaw in Splunk Enterprise. A user with the plain user role could craft a Dashboard Studio dashboard that runs attacker-controlled SPL for another authenticated user. Splunk fixed it in 10.4.2, 10.2.6, 10.0.9 and 9.4.14, and lists turning Splunk Web off as a workaround.
What's affected
The record lists Splunk Enterprise below 10.4.2, 10.2.6, 10.0.9 and 9.4.14. The component is Dashboard Studio.
Splunk's advisory table lists the affected and fixed Splunk Enterprise versions for the whole August 2026 advisory:
- 10.4 line: 10.4.0 to 10.4.1, fixed in 10.4.2
- 10.2 line: 10.2.0 to 10.2.5, fixed in 10.2.6
- 10.0 line: 10.0.0 to 10.0.8, fixed in 10.0.9
- 9.4 line: 9.4.0 to 9.4.13, fixed in 9.4.14
Where sources differ. The record and the advisory agree on versions and on 6.7 Medium for this CVE.
How to check if you're exposed
Find your version first. On the Splunk host, run:
$SPLUNK_HOME/bin/splunk version
Compare the result with the fixed versions above. Then check whether Splunk Web is running on that instance, because Splunk lists turning Splunk Web off as a workaround for this issue, which tells you the vulnerable code sits in the web interface. The web.conf specification and Splunk's guidance on disabling unnecessary components describe how the web server is controlled.
Also list who can reach Splunk Web. A flaw that depends on a user opening a crafted link matters most where many people log in with broad roles.
Also review which users can create or share Dashboard Studio dashboards, since the weakness involves the app visibility boundary.
What to do now
- Upgrade Splunk Enterprise to 10.4.2, 10.2.6, 10.0.9 or 9.4.14, or higher, as Splunk's advisory directs.
- If you cannot upgrade this week and nobody needs the web interface on that instance, turning Splunk Web off is the workaround Splunk lists.
- Remind users with search access to treat unexpected links into Splunk Web with suspicion, especially links that open a dashboard or explorer view.
- Review which roles can run searches and which hold the admin and power roles, so a phished session carries as little as possible.
- Re-check the version after the upgrade and note it in your asset record.
Why it matters
Splunk says Dashboard Studio does not consistently enforce the expected app visibility authorization boundary before dashboard search query options reach search dispatch. In plain terms, a dashboard a low privilege user builds can end up running a search for someone with more access. That is a missing authorization check, filed under CWE-862.
As with the other Splunk Web issues in this advisory, a victim has to initiate a request in their browser, and the attacker needs the user role. The effect depends on what the victim can read and change. The record does not mark it as a CISA KEV entry.
Quick check
What role does the attacker need?
The record says a user holding the user Splunk role, plus a victim who initiates a request in their browser.
What can the injected search reach?
Everything the victim's account can reach, according to the record: relevant data, system integrity and availability.
Sources
Last reviewed: 18 October 2026.