CVE-2026-76396

CVE-2026-76396 reveals a silent privilege escalation path in Splunk's capability model. The `apply` command — which triggers model deserialization — was never marked as 'risky.' This means any user with `schedule_search` capability can invoke a code path that loads and deserializes arbitrary model files, bypassing the intended security boundary between search scheduling and code execution. The core fragility is architectural, not code-level. Splunk's capability system depends on developers manually tagging commands as risky — one missing annotation creates a bypass. The semantic gap is the trap: `schedule_search` has nothing to do with model deserialization, so auditors reviewing role assignments see nothing alarming about granting it. The vulnerability only emerges when you understand that `apply` performs deserialization, a high-risk operation that should require explicit authorization. Operational impact is amplified by Splunk's typical deployment role. These instances sit at the center of security operations — ingesting logs, running correlation searches, feeding SIEMs. Compromising the AI Toolkit through this path doesn't target a utility; it targets the system that monitors everything else. This makes the blast radius fundamentally different from a missing flag in a standalone tool. For defenders: audit your capability assignments for roles granted `schedule_search` and verify whether those roles need access to the AI Toolkit's `apply` command. More critically, treat this as a signal to audit all AI Toolkit commands — how many others perform deserialization, file access, or code-loading without risky flags? The answer likely reveals a systematic gap, not an isolated oversight. The deeper concern: this is the second time Splunk has patched a capability annotation gap. Adding a single `risky` flag to `apply` fixes this instance but doesn't fix the architecture. A sustainable security boundary requires changing the default — any command performing deserialization or privileged file access should be risky by default, with explicit opt-outs reviewed at code submission, not silent inclusions reviewed post-hoc after a CVE drops.

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