This vulnerability exposes session material through the dispatch archive download path when Splunk reports are embedded in external-facing applications. The critical detail is in Splunk's own mitigation language: they reference 'additional configuration for embedded reports' as the secure path. That phrasing is your indicator that the patch doesn't close the authorization boundary in code — it relocates the boundary definition to operator responsibility. You need to verify whether your deployment is one of the affected configurations: any Splunk instance that embeds reports where the HTML source is readable by unauthenticated users.
If you configured embedded reports following Splunk's documentation and believed you were secure, treat that assumption as suspect. The 'additional configuration' step was documented before Splunk understood (or admitted) that the default path was fundamentally insecure. The patch timeline suggests this boundary was never audited against the embedded report feature — the dispatch archive code predates that feature surface, and nobody reviewed the trust assumptions when the new exposure vector was introduced.
Your action items: first, confirm whether embedding is enabled and externally accessible in your environment. Second, examine the specific patch version for your Splunk release (9.4.14, 10.0.9, 10.2.6, or 10.4.1) to determine if it enforces the authorization check or merely updates documentation. If the fix is documentation-only, you still have an exposure until you've independently validated the configuration. Third, review any deployment automation or upgrade processes to ensure they re-validate the embedded report configuration post-upgrade — Splunk's documentation lives in a different maintenance lifecycle than code, and upgrades can silently revert configuration state. The CVSS 9.4 is technically accurate but practically misleading: the blast radius is narrow because it requires specific embedding architecture, but that narrow population includes organizations who explicitly followed Splunk's guidance and believed they were protected.