CVE-2026-76340

The CVSS 5.3 score for CVE-2026-76340 understates the actual risk. This vulnerability allows unauthenticated callers to invoke token-signing key reload in Splunk Enterprise 10.4, bypassing the change_authentication capability requirement entirely. The CVSS captures only the immediate action — reload the keys — but not the downstream cascade that makes this architecturally severe. A key reload in a distributed Splunk deployment (search heads, heavy forwarders, indexers) isn't atomic. When an attacker forces a reload, old tokens become invalid before new key material propagates evenly across nodes. This creates uneven, sustained authentication failures across the deployment rather than a clean handoff. In multi-tenant Splunk environments — common in enterprises aggregating data from multiple business units or external customers — triggering this vulnerability disrupts every workload trust relationship feeding into that instance simultaneously. One attack becomes a multi-organizational event. The CVSS treats this as medium impact on a single system; the actual blast radius in integrated environments is potentially catastrophic. Three questions determine your exposure. First, what exactly does the reload action do — does it regenerate keys, load from existing storage, or both? This determines whether there's a window where authentication is simply broken. Second, was this endpoint newly created in 10.4, or was a previously-internal endpoint newly exposed to unauthenticated callers? The scope says 10.4 and below unaffected, implying this bypass was introduced rather than unearthed — a different remediation profile. Third, does the 10.4.2 patch add authentication only, or does it constrain what the reload action can actually do? The low EPSS (0.0027) likely reflects that this endpoint isn't yet widely enumerated in attacker tooling, not that exploitation is theoretical. A 5.3 score also means this gets queued behind higher-severity vulnerabilities in patch pipelines, extending the effective exposure window well beyond the version window. Assume this is exploitable in any deployment where the REST API is internet-facing, and prioritize the 10.4.2 patch regardless of current EPSS readings.

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