Safeguard
Vulnerability Analysis•

CVE-2026-76322: Medium SPL Injection via Dashboard Studio in Splunk

CVE-2026-76322 is a medium (6.7) flaw in Splunk Dashboard Studio that lets a user role account run SPL as another user. Upgrade to a fixed release.

Safeguard Security Team
3 min read

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

  1. Upgrade Splunk Enterprise to 10.4.2, 10.2.6, 10.0.9 or 9.4.14, or higher, as Splunk's advisory directs.
  2. If you cannot upgrade this week and nobody needs the web interface on that instance, turning Splunk Web off is the workaround Splunk lists.
  3. Remind users with search access to treat unexpected links into Splunk Web with suspicion, especially links that open a dashboard or explorer view.
  4. Review which roles can run searches and which hold the admin and power roles, so a phished session carries as little as possible.
  5. 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.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.