The CVSS 5.4 assigned to this Splunk vulnerability fundamentally mischaracterizes the actual risk. The score treats the "phishing admin" prerequisite as meaningful friction, but in operational Splunk environments, this is routine workflow. Admins regularly open, review, and work with Table Editor datasets shared by power users — this is how collaborative Splunk deployments function, not a suspicious action requiring social engineering. The 'phishing' framing in Splunk's disclosure constructs an imaginary security boundary around behavior that is, by design, how the product operates.
The core issue is a trust model violation. Splunk's role-based access controls and SPL safeguards were designed around the mental model of a human consciously typing commands into a search bar and accepting warnings. Nobody audited whether those same safeguards apply when internal features invoke searches on behalf of users. The Table Editor's Initial Data step runs a field-summary search that bypasses SPL safeguards entirely — not because anyone intended to create a bypass, but because this automation channel was never added to the threat model. It's a UI convenience feature that inherited trust from the Splunk ecosystem automatically.
Once a power user escalates to admin through this path, the blast radius is catastrophic. Admin access in Splunk means access to credentials stored in password files, ability to modify authentication configurations, and capacity to write persistence mechanisms into lookup files that survive credential rotation. The CVSS is calibrated to the exploit's mechanical complexity, not its outcome severity. That mismatch is where the real danger lives.
The detection visibility gap compounds this significantly. Exploitation leaves no anomalous audit trail — the admin opening a shared dataset generates exactly the same log entry as routine work. Splunk is frequently deployed as a security monitoring platform, yet its own search functionality can smuggle commands past its own safeguards without leaving forensic residue. This directly explains the low EPSS score: rarity reflects detection difficulty, not exploitation rarity.
The practical implication extends beyond patching this specific CVE. The root cause is epistemic: safeguards exist but weren't audited against all automated search paths. Any Splunk feature that runs searches with elevated context should be treated as a potential bypass point. The Table Editor isn't an anomaly — it's the latest instance of a recurring architectural pattern where security boundaries get defined around explicit user interactions while internal automation channels operate under assumed trust.