The ess_analyst role's write access to UEBA macros is a privilege escalation vector that you need to treat as a design failure, not a bug. Here's why it matters and what to do about it.
The mechanics: ess_analyst has write permission to macros in Splunk UEBA. Those macros get expanded and executed by scheduled searches that run with administrator privileges — because elevated execution is what enables the cross-dataset behavioral correlation that UEBA requires. The analyst writes the macro; the infrastructure runs it at admin level. That's the bridge. The permission model treats macro editing and search execution as independent concerns, and the UI never surfaces the execution context when granting write access to a macro. An admin clicking 'edit' on a macro sees no warning that it will run with admin privileges.
The deeper problem is that this gap lives in the documentation seams. Splunk documents role composition, knowledge object permissions, and scheduled search execution in separate product sections — no single reference maps how permissions granted in one context travel into execution contexts owned by another. The CVE itself links to two documentation pages that together describe the gap. That's not coincidental; that's the documentation model encoding the vulnerability.
Prior CVEs follow the same structural pattern: CVE-2023-46215, CVE-2024-36991, and now this one. Each patches a specific permission-to-execution bridge, but the underlying architecture keeps producing them. Three CVEs in this class is evidence that the model reliably generates these failures at this privilege boundary — treat future CVEs here with a higher prior probability of exploitability than EPSS suggests.
What to check: Audit your UEBA knowledge objects (macros, saved searches, field extractions) against their configured execution contexts, not just against role permissions. Look for any object where a non-admin role has write access but the object runs in a scheduled search with elevated permissions. The fix is either removing write access from ess_analyst for any object in elevated contexts, or redesigning the workflow so analysts can tune detections without authorable objects running at admin level.
The low EPSS score (0.00248) reflects that exploitation requires an authenticated ess_analyst and knowledge of the UEBA environment — that's not irrational. But note the blast radius: an analyst inside a UEBA correlation engine has access to a system that's already mapped behavioral signals across your environment. The execution context isn't just privileged; it's informed. That's the real exposure, and it's not captured by CVSS or EPSS.