CVE-2026-76336

This CVE exposes a critical authorization gap in Splunk's SPL2 module management REST API: any authenticated user can delete exported datasets and functions that other users depend on. The vulnerability affects Splunk versions 10.2 through 10.4.2, and notably does NOT affect any version below 10.2 — meaning the gap was introduced simultaneously with SPL2 module functionality, not regressed later. This is a feature-bounded flaw created at the same time as the capability it abuses. What makes this severe is the blast radius, which the CVSS score undersells. SPL2 modules are shared operational artifacts — exported datasets and functions that analysts build searches and dashboards around. A low-privilege user deleting these shared modules doesn't just harm themselves; they degrade the Splunk environment for every user, including admins who may not even know their operational workflows depend on those modules. This is closer to a supply chain attack on your own SIEM than a traditional authorization bypass. The fix requires two things. First, verify your Splunk version and apply the patch from 10.4.3 or later immediately — this is a one-line authorization check that should have existed at launch. Second, audit every other SPL2 module management endpoint (list, modify, export) for the same missing authorization pattern. If this global deletion endpoint slipped through, the others are suspect. The vulnerability exists because the REST handler was likely built assuming its callers would be trusted internal tooling, with authorization delegated upstream to the UI layer — a common but dangerous architectural misunderstanding. If you're running an older Splunk version, understand that the true exposure window extends well beyond the version numbers: enterprises on 10.2 or 10.3 often delay upgrades due to regression testing requirements, meaning the operational risk persists long after the CVE was published.

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