The CVE describes a credential disclosure via the Splunk REST API, and the word 'encrypted' in the disclosure may lead you to focus on encryption failures. Don't. This is a capability mapping error: the rest_properties_get capability — which should govern only general property reading — inadvertently gates access to stored credentials that require the more restrictive list_storage_passwords capability. A role granted rest_properties_get for legitimate low-privilege operations can retrieve credentials it should never access.
This matters because Splunk deployments typically store credentials for external systems: AWS API keys, database passwords, third-party integration tokens, SSO secrets. When rest_properties_get unexpectedly unlocks credential storage, you're not just bypassing Splunk's access model — you're potentially exfiltrating the keys to every system Splunk touches. The CVSS 6.5 base score reflects the authenticated, capability-gated nature of the exploit, but it cannot express the lateral-movement potential to infrastructure that had nothing to do with Splunk's own risk posture.
What to do: First, inventory which roles in your Splunk deployment hold the rest_properties_get capability. Second, assess what credentials are stored in that Splunk instance — if it holds keys to AWS, Azure, databases, or third-party APIs, the blast radius is far larger than the Splunk system itself. Apply the patch immediately. Third, assume this is not isolated: audit other broad property-read capabilities (rest_uri_get, rest_attr_get) for similar misclassifications. Treat any capability that gates both property reading and credential storage as a known risk vector until proven otherwise. The fix is patching, but the discipline is assuming the capability model contains related mapping errors and auditing accordingly.