The CVSS 7.3 score for this Splunk vulnerability is dangerously misleading. The real issue is not a missing escape function — it is a fundamental failure in Splunk's threat modeling where the Job Details dashboard operates as an implicit trust boundary that should not exist.
SPL safeguards were architected assuming direct user queries are untrusted while certain internal pathways — specifically the Job Details dashboard that displays job identifiers — are treated as trusted intermediaries. This is the flaw: the dashboard passes caller-supplied identifiers to SPL execution without validation, assuming another component already handled sanitization. No component did. The result is that any authenticated user can inject arbitrary SPL through this pathway, inheriting the full permission context of the victim who clicks the malicious link.
The 'requires phishing' framing in the description should not comfort defenders. Phishing is a reliable, well-established attack prerequisite — organizations that rely on users not clicking malicious links have already lost. The relevant question is what the victim's privilege level grants the attacker, and here the answer is: everything that user can access in Splunk.
Worse, this is not an isolated failure. Splunk patched four version branches simultaneously (10.4.2, 10.2.6, 10.0.9, 9.4.14), which strongly suggests this specific pattern — internal pathways circumventing SPL safeguards — has recurred across versions without the underlying architectural assumption being corrected. Each patch likely sanitized the specific identifier type exploited rather than implementing centralized validation for all caller-supplied identifiers flowing to SPL. The organizational question is whether Splunk now forces all identifier flows through a central validation layer, or whether each dashboard component remains individually responsible for recognizing when to validate.
From a defensive perspective, treat this as higher severity than CVSS 7.3 indicates. Splunk is frequently a data aggregation hub feeding SIEMs, automation runbooks, and ticketing systems. When an authenticated user's permissions get weaponized here, the pivot extends to downstream systems that process Splunk outputs with higher trust. Verify that your Splunk deployment is fully patched across all four affected version branches, and audit other dashboard components for similar implicit trust patterns — the Job Details dashboard is unlikely to be the only pathway where internal identifiers reach SPL execution unvalidated.