This vulnerability deserves more attention than its CVSS 8.8 suggests—not because the score is wrong, but because it measures impact on a single system while the actual compromise collapses an entire trust graph. A user with schedule_search capability can reach Splunk's credential store through alert action configuration, and that store doesn't just hold Splunk passwords. It contains LDAP bind accounts, cloud API tokens for AWS/Azure/GCP, database credentials from DB Connect, and custom secrets stored by Splunk apps. A schedule_search user who exploits this isn't escalating within Splunk—they immediately sit at the authentication backbone of every system your SIEM monitors, able to authenticate AS the SIEM to everything it integrates with. That's a one-step lateral movement to systemic compromise, not a 10-step kill chain.
The fix is also not a simple patch question. Splunk has published at least two prior CVEs against credential store boundary failures in this subsystem—CVE-2022-43571 and CVE-2021-44205 each closed a specific entry point. This is the third iteration. The historical pattern suggests point fixes address specific vectors while the underlying architectural tension—user-configurable execution contexts touching admin-protected credential stores—persists. You should verify whether the patch severs credential store access from alert action execution at the execution-context level, or merely reconfigures UI controls. The difference matters: one restores architectural isolation, the other leaves the underlying access path exploitable if an admin misconfigures something or a future feature reintroduces the same intersection.
Operationally, map every user with schedule_search capability and assess their trust posture against the blast radius of what their credentials could reach. If your credential store contains secrets for systems beyond Splunk authentication—and in any non-trivial deployment it does—the exposure isn't Splunk-specific; it's the entire trust graph. Consider this a forcing function to audit legacy execution contexts in your Splunk deployment: alert actions, scripted alerts, custom alert actions, report acceleration, saved search templates. Each represents a user-configurable execution surface that may never have been re-evaluated against the credential store's expanded scope. Deprecation is not eradication—flagged features often mean 'nobody security-reviewed it recently,' not 'it's actually sandboxed.'