CVE-2026-20297

The CVSS 7.2 score here is misleading. Yes, you need `edit_local_apps` AND `install_apps` to exploit this — but in Splunk's operational model, these capabilities are routinely bundled for anyone who deploys apps, which is a baseline Splunk operator function. You're not measuring an attacker pool of specialists; you're measuring a configuration state that Splunk's own workflow design encourages. The path traversal then does something the CVSS anchor doesn't capture: it collapses Splunk's entire directory isolation in one step. `$SPLUNK_HOME/etc/` contains the authentication configuration, user definitions, password stores from local apps, and the app manifest files Splunk trusts at runtime. This isn't a lateral movement step — it's already filesystem sovereignty. The 'legitimate app installation' phrasing in the description is the real signal: the attack looks exactly like normal admin activity, which is why no alerting rule catches it. The 2019 path traversal in app installation (CVE-2019-10018) suggests this may be incomplete remediation from a surgical fix rather than an architectural one. Compounding the problem: Splunk's audit logging records 'app installed successfully' but not the individual file paths written during installation. Even organizations with comprehensive Splunk logging have no first-party evidence trail for detection or reconstruction. This means compensating controls must focus on file integrity monitoring of `$SPLUNK_HOME/etc/` rather than Splunk-native logging. The unresolved question that changes the post-exploitation narrative: can you overwrite existing files in `$SPLUNK_HOME/etc/` or only write to previously nonexistent paths? This determines whether authentication configuration replacement is direct or requires planted files plus a Splunk restart.

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