CVE-2026-76259 is a high severity (8.8) privilege management flaw in Splunk Enterprise for Windows. A local user could bind the management port before Splunk starts and intercept authentication tokens from child processes. Splunk fixed it in 10.4.2, 10.2.6, 10.0.9 and 9.4.14. It needs access to the Windows host.
What's affected
The record lists Splunk Enterprise for Windows below 10.4.2, 10.2.6, 10.0.9, 9.4.13 and 9.3.14. Other platforms are not named in the record.
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 names 9.4.13 and 9.3.14 as boundaries. The advisory's product table lists 9.4.14 as the fix for the 9.4 line and has no 9.3 row. Use 9.4.14 or a later release on that line, and check the advisory if you run 9.3. Severity agrees at 8.8 High.
How to check if you're exposed
Confirm which Splunk hosts run on Windows, then get the version on each:
"%SPLUNK_HOME%\bin\splunk.exe" version
Then ask who has local access. This is a local attack, so the exposure is every account that can log on, run code or schedule tasks on that server. Shared jump hosts, build servers and terminal servers that also run Splunk deserve the first look.
The advisory lists no workaround for this CVE, so version is the control that counts.
What to do now
- Upgrade Splunk Enterprise on Windows hosts to 10.4.2, 10.2.6, 10.0.9 or 9.4.14, or higher.
- Prioritize hosts where non-administrators can log on interactively or run code.
- Restart Splunk as part of the upgrade, so the service takes the listener under the fixed behavior.
- Review who holds local logon rights on the Splunk server and remove those that are not needed.
- Record the new version and check the advisory again for any later notes.
Why it matters
The record explains the cause plainly: the Windows management port listener does not apply exclusive address binding protections before the service starts. A local user who gets there first can sit in the path of tokens that child processes send. This is improper privilege management, filed under CWE-269.
The scope is changed in the score, because the stolen tokens give the attacker the reach of the account running Splunk Enterprise, which is often far more than their own. The attack is local and needs a low privilege account, so it is not an internet-facing emergency, but it turns any foothold on a Splunk server into control of the data it holds. The record does not mark it as a CISA KEV entry.
Quick check
Can this be exploited over the network?
The vector in the record is local. The attacker needs access to the Windows host, then binds the management port before Splunk starts.
Is there a workaround?
The advisory lists none for this CVE. Upgrading is the fix.
Sources
Last reviewed: 18 October 2026.
