CVE-2026-76310: Improper Access Control through Embedded Report REST API Requests in Splunk Enterprise
In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user who has an embedded report token could download the associated search job dispatch archive, recover session material, and use it to access all relevant data available to the report owner and affect system integrity, including by performing administrative actions when the owner holds the "admin" Splunk role. The vulnerability is possible because embedded report access does not block Representational State Transfer (REST) API dispatch archive download requests. For more information see Additional configuration for embedded reports (https://help.splunk.com/en/splunk-enterprise/create-dashboards-and-reports/reporting-manual/9.1/report-management/additional-configuration-for-embedded-reports) and About configuring role-based user access (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.4/manage-splunk-platform-users-and-roles/about-configuring-role-based-user-access) in the Splunk documentation.
Security readout for executives and security teams
Plain-English summary
Someone holding an embedded report token could retrieve hidden session material without authenticating. That material may expose everything the report owner can access and permit actions with the owner’s authority. If the owner is an administrator, the attacker could perform administrative actions. Impact includes major data disclosure, unauthorized changes, and limited availability effects.
Executive priority
Treat this as an urgent upgrade and exposure-review issue. Prioritize internet-accessible or externally shared embedded reports and any report owned by an administrator. Even without confirmed active exploitation, the low-complexity, unauthenticated path and potential administrator-level impact justify expedited remediation.
Technical view
Splunk Enterprise improperly permits embedded-report access to REST API requests that download a search job dispatch archive. An unauthenticated token holder can recover session material from that archive and assume the report owner’s relevant access. The issue affects versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14.
Likely exposure
Exposure requires Splunk Enterprise in an affected version and possession of a valid embedded report token. Risk increases when tokens are publicly shared, broadly distributed, or associated with reports owned by highly privileged users. Reports owned by administrators create the greatest potential impact.
Exploitation context
The CVSS 3.1 score is 9.4, reflecting network access, low complexity, no authentication, and no user interaction. The supplied sources do not establish active exploitation, and the CVE is not identified as CISA KEV. Public exploit availability is not established by this source bundle.
Researcher notes
The access-control failure is specifically the absence of blocking for REST API dispatch archive download requests through embedded-report access. The archive can disclose reusable session material. Available evidence does not specify token discovery methods, observed attacks, indicators of compromise, or mitigations beyond fixed version thresholds and referenced vendor guidance.
Mitigation direction
Upgrade affected branches to 10.4.2, 10.2.6, 10.0.9, or 9.4.14, respectively, or later supported releases.
Prioritize systems using embedded reports, especially reports owned by administrators or other highly privileged accounts.
Review the Splunk advisory and embedded-report configuration guidance for any environment-specific safeguards.
Validation and detection
Confirm every Splunk Enterprise instance and compare its version with the fixed release for its branch.
Inventory embedded reports, their token distribution, report owners, and each owner’s assigned roles.
Review relevant logs for dispatch archive downloads associated with embedded-report access.
Investigate unexpected activity performed under report-owner sessions, prioritizing owners with administrative privileges.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-284: Authorization and privilege behavior lookup
Authorization weaknesses can support privilege escalation and valid-account review, depending on exploit path. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
2Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: yesTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-284 · source CWE mapping
Improper Access Control
Improper Access Control represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.