CVE-2026-76255

The advisory frames this as a vulnerability requiring phishing, but the actual exploitation friction is minimal: a victim merely initiates a standard browser request within their own authenticated session. This isn't spear-phishing — it's session-abuse through legitimate application workflows. The deeper issue is that Splunk's Data Model Editor invokes base searches for auto-extracted fields without propagating SPL safeguards from the UI layer, converting any collaborative Data Model workflow into a potential escalation vector. This is a structural failure, not a user behavior problem. Splunk's permission model conflates authentication with authorization — the platform knows WHO runs a search but doesn't consistently enforce WHAT that user can instruct the search to do. The SPL safeguards exist but are applied unevenly across feature call paths, and the documentation frames them as "best practices" rather than enforced constraints. That distinction is the genealogical signal: advisory-layer security creates exploitable gaps in any execution path that wasn't instrumented. Check your Splunk deployment for shared Data Models and collaborative editor contexts — those are the frictionless exploitation surfaces. The patch likely closes this specific call path but leaves the architectural assumption intact. Expect similar bypasses in other features that auto-invoke searches (pivoting search, saved search inheritance, alert actions) unless Splunk refactors safeguard enforcement as a platform-wide invariant rather than a feature-specific afterthought. The question isn't whether this vulnerability exists — it's how many other feature paths inherit the same execution context failure.

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