CVE-2026-76331 is a saved-search dispatch vulnerability where SPL injection occurs through time parameters that received no input validation. The root cause is not a conscious security trade-off—it is an absence of security thinking in code that was written when the endpoint genuinely was admin-only. Developers handling the time parsing logic assumed they would only ever receive sanitized inputs from higher-privileged contexts, and they never revisited that assumption as the endpoint's reachable audience expanded.
The EPSS score of 0.0023 measures how hard the ignition point is to reach, not how far the explosion travels. The saved-search dispatch handler is wired into alerts, reports, dashboards, scheduled searches, and downstream integrations—a single validation gap in a hub feature becomes a radial blast path through Splunk's entire data pipeline. That is why the severity is 8.1 despite low exploitability: the trigger is narrow, but the detonation is wide.
The patch versioning (10.4.2, 10.2.6, 10.0.9, 9.4.14) tells you the fix was scoped to the dispatch handler's time parameter handling, not a broader validation framework. That is the right immediate fix, but the open question is which other parameters in that same handler—dispatch.earliest_time, dispatch.latest_time, or related parameters—remain as implicit trust pathways that were left unchanged. Assume they carry the same gap until proven otherwise.
Treat this CVE as a diagnostic signal: audit other Splunk endpoints that are documented as admin-only for parameter handling that assumes pre-validated calling context. The pattern is almost certainly not isolated. If your deployment has custom saved searches, scheduled reports, or alert actions wired into dispatch, map those dependencies now—this is where the real blast radius lives.