CVE-2026-76367 in SOAR
Summary
by MITRE • 08/20/2026
In Splunk SOAR versions below 8.6.0, a user who holds the "Incident Commander" Splunk SOAR role could store JavaScript in a note and run it in the browser of another user when that user opens the note. The stored Cross-Site Scripting (XSS) vulnerability is possible because Splunk SOAR can treat existing note content as Hypertext Markup Language (HTML) without sanitizing that content when the note format changes. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "Incident Commander" Splunk SOAR role should not be able to exploit the vulnerability at will. For more information see Manage roles and permissions in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) in the Splunk documentation.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/20/2026
A critical stored Cross-Site Scripting vulnerability exists within Splunk SOAR versions prior to 8.6.0, affecting users with the Incident Commander role. This flaw arises from an improper neutralization of user input during note processing, specifically when the format of a note is changed or rendered in the browser. The application fails to sanitize existing content that contains JavaScript code before treating it as Hypertext Markup Language for display purposes. Consequently, if an attacker successfully injects malicious script into a note field while possessing the necessary permissions, this payload remains stored within the system's database and executes automatically when another user views or edits the note in their web browser.
The operational impact of this vulnerability is significant due to its potential for session hijacking and unauthorized actions within the Splunk SOAR environment. By executing arbitrary JavaScript in the context of a victim’s authenticated session, an attacker can bypass same-origin policy restrictions to steal sensitive data such as authentication tokens, cookies, or personally identifiable information associated with security operations. Furthermore, the attacker could manipulate the user interface to perform unintended actions on behalf of the victim, potentially altering incident statuses, modifying playbooks, or exfiltrating confidential threat intelligence stored within the platform. This represents a severe compromise of confidentiality and integrity for organizations relying on Splunk SOAR for their Security Orchestration, Automation, and Response workflows.
From a technical classification perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting. The attack vector is classified under ATT&CK technique T1059, specifically Command and Scripting Interpretation via JavaScript, leveraging the browser environment to execute malicious code. Although the vulnerability requires an initial phishing step or social engineering component to trick a user into opening the compromised note, the persistence of the payload in stored notes makes it particularly dangerous compared to reflected XSS attacks. The requirement for specific role-based access means that while not every user can exploit this flaw immediately, any compromise of an Incident Commander account provides a high-value entry point for further lateral movement within the security operations center infrastructure.
Mitigation strategies must focus on immediate patching and enhanced input validation practices. Organizations running Splunk SOAR versions below 8.6.0 should upgrade to version 8.6.0 or later where this sanitization logic has been corrected to ensure that all note content is properly escaped before rendering as HTML. In addition to applying the vendor-provided fix, administrators should enforce strict role-based access controls to limit who can create and edit notes containing rich text formats. Security awareness training for users with elevated privileges is also recommended to reduce the risk of successful phishing attempts that serve as the initial delivery mechanism for this stored XSS payload. Regular audits of note content and implementation of Content Security Policy headers in the web application interface can provide additional layers of defense against script execution even if similar vulnerabilities are discovered in future updates.