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.
CVE-2026-76335
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an authenticated user who does not hold a role with the edit_manager_xml capability could write a malicious Splunk Web Manager Extensible Markup Language (XML) configuration. When the same user opens the affected Splunk Web Manager page, Splunk Enterprise runs attacker-controlled operating-system commands as the user account running Splunk Enterprise. The vulnerability is possible because Splunk Web does not require the edit_manager_xml capability before accepting Splunk Web Manager XML configuration changes.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysisThe application evaluates attacker-influenced input as code, handing them a way to run logic inside the process. Depending on the runtime this can escalate directly to remote code execution. Remediation means removing dynamic evaluation of untrusted input and replacing it with safe, data-driven alternatives.
General guidance for the code injection class — the official description and references above are authoritative for this specific CVE. Want a bespoke review and a reviewed fix? Ask our team →
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data>= 9.4.0, < 9.4.14>= 10.0.0, < 10.0.9>= 10.2.0, < 10.2.6>= 10.4.0, < 10.4.2CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped9.4.1410.0.910.2.6
Upgrade to Splunk Enterprise 10.4.2 (or 10.2.6, 10.0.9, or 9.4.14) or later
- 1. Identify current Splunk Enterprise version by navigating to Settings > Server Settings > Server Information in Splunk Web, or by running: splunk version
- 2. Plan upgrade to a fixed version: 10.4.2 or higher, 10.2.6 or higher, 10.0.9 or higher, or 9.4.14 or higher
- 3. Review Splunk upgrade documentation and perform a backup of Splunk Enterprise configuration and app directory
- 4. Download the appropriate Splunk Enterprise fixed version from splunk.com
- 5. Stop Splunk Enterprise service: splunk stop
- 6. Install the upgraded version using the Splunk upgrade installer for your operating system
- 7. Start Splunk Enterprise service: splunk start
- 8. Verify the upgrade was successful and Splunk Web is accessible
Generated from the published advisory — verify against the referenced sources before acting.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-76335 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesThis 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.
Practitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-76335 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data