An unauthenticated attacker who can read the HTML source of a page that embeds a Splunk report can recover session material from it and reach the data behind that report. Where the report owner holds the admin role, that extends to administrative actions on the Splunk instance. Splunk fixed the flaw, CVE-2026-76312, on 19 August alongside two near-identical access control failures in the same feature. All three carry a CVSS score of 9.4 and none of them require credentials.
They arrived inside a much larger release. Splunk and Atlassian together shipped fixes for more than 250 vulnerabilities in the same week, a figure SecurityWeek reported on 20 August and one that has circulated widely since. The number tells you very little. Every one of Atlassian’s 172 sits in a third-party library and Atlassian’s own bulletin assesses them as presenting non-critical risk in its products. What warrants attention is the 60 flaws Splunk found in its own code.
Sixty Flaws in Splunk’s Own Code
Splunk advisory SVD-2026-0801, published 19 August, lists 60 vulnerabilities in Splunk Enterprise and its bundled apps. Five are remote code execution. CVE-2026-76319 lets a low-privileged user without the fsh_manage capability run code through Federated Search bundle selection. CVE-2026-76313 reaches the same result by uploading a malicious knowledge bundle and letting distributed search pick it up. Both score 8.8.
CVE-2026-76253, also 8.8, is the one worth reading twice. A user holding any role with the schedule_search capability can run arbitrary SPL at the highest system privilege and read every credential in the credential store. That capability is handed out freely in most deployments because scheduling a search is ordinary analyst work.
Two flaws need no authentication. CVE-2026-76316 lets anyone who can reach the Splunk management port register a crafted Deployment Server client identity carrying a stored SPL pipeline, which runs when an administrator opens the Add Data workflow. CVE-2026-76355 leaks information through an Edge Processor service endpoint with no credentials at all. Fixed versions are 10.4.2, 10.2.6, 10.0.9 and 9.4.14.
Upgrading Alone Does Not Close Two of Them
Splunk flags two CVEs that need configuration changes on top of the upgrade and this is the detail most patch summaries drop. CVE-2026-76338 allows an attacker holding a trusted distributed search private key to forge an administrative session token because the token endpoint falls back to shared local key material when a request is not signed. Closing it means setting strictPeerNameValidation to true in authentication.conf on every node in the distributed environment, then restarting.
CVE-2026-76352 needs scripted_lookup_raw_write_enforcement set to block in limits.conf under the lookup stanza again followed by a restart. Install the new version, skip those two steps and the deployment stays open.
The Automation Broker Trusts a Header
Splunk SOAR carries its own set. CVE-2026-76356 lets an unauthenticated attacker spoof the source IP address in a request to an Automation Broker notification endpoint and execute arbitrary code on the SOAR host. Rapid7 describes the cause plainly: the Automation Broker treats a client-supplied source IP header as proof that the request came from the local system.
CVE-2026-76357 covers remote code execution through path traversal in the SOAR REST API. Both are fixed in SOAR 8.6.0. Splunk Enterprise Security needs 8.6.1 for two separate high-severity issues, an SPL injection through the REST API and a privilege escalation through search macro permissions.
Splunk’s AI Tooling Shipped With Deserialization Bugs
The apps advisory, SVD-2026-0808, tops out at 9.1 and reads like a catalogue of what happens when new surface ships quickly. The Splunk MCP Server app has remote code execution through deserialization of untrusted data, tracked as CVE-2026-76404 and fixed in version 1.2.1. Splunk AI Toolkit has the same class of flaw in its model loading REST API plus hard-coded credentials in container connections and six further access control failures.
Splunk’s suggested mitigation for most of these is to turn the app off. For AI Toolkit that also kills its SPL commands and model operations and breaks the Splunk App for Data Science and Deep Learning wherever it depends on them. Upgrading is the cleaner route.
Atlassian’s Numbers Do Less Than They Look
Atlassian’s bulletin of 18 August covers 162 high-severity and 10 critical-severity issues across Bamboo, Bitbucket, Confluence, Crowd, Fisheye/Crucible and Jira resolving roughly 109 unique CVEs. Every critical entry carries the same footnote, the flaw sits in a non-Atlassian dependency and Atlassian’s application of that dependency presents a lower, non-critical assessed risk. The company is talking its own severity down rather than up which is the more credible direction for a vendor to move. It also matches how Atlassian handles genuine emergencies which get a separate Critical Security Advisory outside the monthly schedule.
The vintage of some entries is harder to shrug off. Confluence is being cleared of CVE-2021-44906, a minimist flaw scored 9.8 and published five years ago. Jira is clearing CVE-2023-45133 in @babel/traverse. Bitbucket is clearing CVE-2022-3517 in minimatch. These are not fresh discoveries, they are a backlog being worked off.
One flaw in the bulletin is not a dependency issue. CVE-2026-21582 is broken authentication and session management in Crowd and Jira Data Center, scored 8.8, and Crowd is the product that brokers identity for everything else in the stack. Patch that one first. Fixed versions are Crowd 7.2.2 or 7.2.3, Confluence 10.2.15 or 9.2.23 LTS, Jira 11.3.10 or 10.3.24 LTS, Bitbucket 10.4.2, 10.2.6 or 9.4.23, Bamboo 12.1.10 or 10.2.22, and Fisheye/Crucible 4.9.13. Most are marked Data Center only.
Eight Days From Patch to KEV in June
No exploitation of any August flaw has been reported as of 21 August, and neither vendor has flagged one. That is worth stating plainly rather than manufacturing urgency that the evidence does not support. It is also worth remembering how fast the position moved the last time Splunk shipped a fix for an unauthenticated flaw.
Splunk patched CVE-2026-20253 on 10 June. watchTowr Labs published a technical write-up and proof-of-concept code on 12 June. Researchers observed exploitation from around 15 June. On 18 June the Splunk Product Security Incident Response Team confirmed limited exploitation in the wild, and CISA added the CVE to its Known Exploited Vulnerabilities catalogue the same day giving federal agencies until 21 June to patch. Eight days from vendor patch to federal deadline.
Upgrade Splunk Enterprise to 10.4.2, 10.2.6, 10.0.9 or 9.4.14, SOAR to 8.6.0 and Enterprise Security to 8.6.1. If you use embedded reports and cannot schedule the upgrade this week, set allowEmbedTokenAuth to false in server.conf, which shuts the two 9.4 dispatch archive flaws today. Then find out whether anyone in your organisation has published a page with a Splunk report embedded in it.
References
- Security Hardening Release for Splunk Enterprise August 2026
- Security Hardening Release for Splunk SOAR August 2026
- Security Hardening Release for Splunk Apps and Add-ons August 2026
- Atlassian, Splunk Patch Dozens of Critical, High-Severity Vulnerabilities
- SVD-2026-0603 Unauthenticated File Operations in Splunk Enterprise
- CISA: Splunk Enterprise Flaw Actively Exploited, Patch by Sunday
This post is also available in:
Svenska
Related News
Critical Flaws in Belgian eID Software Exposed Millions of Bank and Government Users
Critical security vulnerabilities in Belgium's national eID middleware exposed users across eight of the country's ten largest banks and more than 60 government agencies to…
August 10, 2026 Swiss Government SharePoint Breach Hits 200 Accounts Through Unpatched Servers
Attackers breached the Swiss federal government's on-premises SharePoint servers and compromised approximately 200 user and technical accounts before the intrusion was detected. The Federal Office…
August 7, 2026 Fastjson 1.x Remote Code Execution Flaw Exploited With No Patch Available
There is no patch. That is the first thing to understand about the remote code execution vulnerability currently being exploited in Fastjson 1.x. Attackers are…
July 28, 2026 
