CVE-2026-76345

The version scoping in CVE-2026-76345 is the detail that should change how you respond. This isn't a long-standing flaw — it's a regression introduced in Splunk Enterprise 10.4.0 and patched in 10.4.2. If you skipped 10.4.x entirely and went from 10.3 to 10.5, you're not exposed. If you ran 10.4.0 or 10.4.1 and patched promptly, your exposure window was narrow. What matters most is the mechanism: a cluster bundle management API that validates bundle paths but doesn't enforce the same authorization boundaries as the rest of Splunk's administrative interface. An attacker with high-privilege access — specifically the search head clustering management capability — can use this API to write to user-controllable filesystem locations, which directly translates to code execution. The CVSS score captures severity but obscures the real question: this required administrative access to begin with, which fundamentally changes the threat model from an unauthenticated remote exploit. The two-release patch turnaround is itself a signal. Either Splunk caught this internally during code review — which raises questions about why a new API endpoint bypassed established authorization patterns in the first place — or external disclosure prompted unusually rapid remediation. The patch type matters: if it's path validation added to existing code, the vulnerable logic still exists in your 10.4.2+ binaries and represents deferred risk. If it's capability removal, the feature was designed wrong from the start. Your response should be: confirm exactly which 10.4.x versions you ran and for how long, identify who had high-privilege Splunk access during that window, and treat this as a leading indicator — Splunk's internal authorization model has structural gaps when new features ship. Audit your 10.5+ deployments for similar patterns, not just this CVE.

Reviewed through automated stages and approved by a human before publication.