CVE-2026-76255 is a medium severity (6.4) authorization gap in Splunk Enterprise. The Data Model Editor runs a base search for auto-extracted fields without the safeguards for risky SPL commands, so a user outside the admin and power roles could trick another user into running SPL as them. Splunk's advisory directs an upgrade to 10.4.2, 10.2.6, 10.0.9 or 9.4.14.
What's affected
The record lists Splunk Enterprise versions below 10.4.1, 10.2.6, 10.0.8 and 9.4.13. The component is the Data Model Editor in Splunk Web.
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 CVE text uses boundaries of 10.4.1, 10.0.8 and 9.4.13, while the advisory's overall guidance and product table name 10.4.2, 10.0.9 and 9.4.14 as the fixed releases. Upgrading to the table's versions satisfies both. Severity agrees at 6.4 Medium.
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.
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 keeps a set of safeguards that warn or block when a search uses risky commands. In this case the Data Model Editor does not apply them when it runs the base search for auto-extracted fields. That is a missing authorization check, filed under CWE-862.
The attacker needs a low privilege Splunk account and a victim who initiates a request in their browser. The victim's permissions then decide what data the search can read and what it can change. It is a good example of why role design matters: a low-trust user should never be able to cause a high-trust user to run their query. The record does not mark it as a CISA KEV entry.
Quick check
Which users can exploit this?
The record says a user who does not hold the admin or power roles. They still need to trick another user into starting a request in their browser.
Is Splunk Web off a valid workaround?
Splunk lists turning Splunk Web off as a possible workaround for this CVE, since the issue affects instances with Splunk Web turned on.
Sources
Last reviewed: 18 October 2026.
