CVE-2026-76335

This CVE reveals an enforcement gap in Splunk's own capability model: the edit_manager_xml capability exists and governs access to certain management functions, but it was not enforced when XML configuration files are written through a specific code path. An authenticated user without this capability could write malicious XML to the manager configuration, then trigger its execution simply by opening the affected Splunk Web Manager page. The attack requires two steps, but the second is trivially achievable — every user who visits that page becomes a potential victim, which fundamentally changes the threat model from direct privilege escalation to a persistent weapon that detonates for anyone who accesses the shared interface afterward. The XML payload survives on disk across Splunk restarts and potentially across upgrades, making this more like planting an implant than a transient exploit. The CVSS 8.8 reflects code execution capability, but the actual blast radius is larger than a typical authenticated RCE because one exploit creates a deferred detonation that scales with user activity. This pattern — write arbitrary content to a configuration file, then trigger its interpretation as code — is not unique to Splunk. It appears across decades of CVEs in Apache Struts, Jenkins, Tomcat, and PHP frameworks. The recurring root cause is architectural: systems conflate permission to write configuration with permission to cause that configuration to be executed as code, making these authorizations at different times through different code paths. The Splunk fix in versions 10.4.2, 10.2.6, 10.0.9, and 9.4.14 presumably adds the edit_manager_xml check to the write path, but the deeper architectural question is whether Splunk's capability model is enforced centrally or applied per-feature. If it's the latter, similar enforcement gaps likely exist elsewhere. For detection, examine whether Splunk logs or alerts when users without edit_manager_xml submit manager XML — if the enforcement was simply absent, there may be no audit trail of these attempts, making retrospective identification of exploitation difficult. Prioritize hunting for similar write-then-trigger patterns in other configuration mechanisms, particularly in features that predate the modern permission model and may have never been audited against it.

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