CVE-2026-76378 in Secure Malware Analytics app for SOAR
Summary
by MITRE • 08/20/2026
In versions below 2.4.5 of the Cisco Secure Malware Analytics app for Splunk SOAR, a user who holds a role with permission to run actions could expose a sensitive sample password by invoking the detonate file action, because the action's sample_password parameter is not masked and is shown in cleartext in the user interface. The information disclosure is possible because the app does not mark the affected action parameter as a password. For more information see Run an action in Splunk SOAR (https://help.splunk.com/en/splunk-soar/soar-on-premises/use-splunk-soar-on-premises/8.6.0/use-the-command-line-interface-to-perform-tasks-in-splunk-soar-on-premises/run-an-action-in-splunk-soar-on-premises).
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The Cisco Secure Malware Analytics app for Splunk SOAR, specifically in versions prior to 2.4.5, contains a critical information disclosure vulnerability that stems from improper handling of sensitive credentials within the application's user interface. This flaw affects users who possess roles with permissions to execute actions within the platform. The core technical issue lies in the implementation of the detonate file action, which is designed to analyze potentially malicious samples by executing them in a controlled sandbox environment. To facilitate this analysis, the system requires authentication credentials for the target sample or associated services, captured via the sample_password parameter. However, the application fails to classify this specific input field as a sensitive credential type that requires obfuscation. Consequently, when an authorized user invokes this action through the graphical interface, the password entered into the sample_password field is rendered in cleartext rather than being masked with asterisks or dots. This behavior violates fundamental security design principles regarding the protection of authentication material and exposes high-value secrets to any individual who can view the execution logs or interact with the action configuration screen within that session.
From a technical perspective, this vulnerability represents a failure in input sanitization and output encoding practices specific to sensitive data fields. In secure software development, parameters designated for passwords must be explicitly flagged by the framework so that the rendering engine applies appropriate masking logic during display operations. The absence of this flagging mechanism means the application treats the password field identically to standard text inputs, thereby bypassing security controls intended to prevent accidental exposure. This oversight allows any user with access to view the action details or execution history to observe the plaintext value of the sample_password parameter. Such an occurrence is particularly dangerous in a Security Orchestration, Automation, and Response (SOAR) environment where multiple analysts may have visibility into automation playbooks and historical runs, increasing the attack surface for credential theft through social engineering or insider threats who might exploit visible logs to gain unauthorized access to external systems referenced by the malware analysis tasks.
The operational impact of this vulnerability is significant due to the nature of Splunk SOAR as a central hub for security operations. If an attacker gains access to a user account with sufficient privileges, they can not only execute malicious actions but also harvest sensitive passwords displayed in cleartext during routine operations. These credentials could belong to third-party threat intelligence feeds, sandbox environments, or internal systems being analyzed by the malware analytics tool. The exposure of these secrets enables lateral movement within an organization's infrastructure and potentially compromises the integrity of ongoing investigations if attackers can manipulate subsequent actions using stolen credentials. Furthermore, this flaw undermines trust in the automation platform’s ability to securely handle sensitive data, which is a cornerstone requirement for enterprise security deployments. It effectively turns routine operational activities into vectors for credential harvesting without requiring complex exploitation techniques or privilege escalation beyond what is already granted by standard role-based access controls.
This vulnerability aligns with CWE-256, an unencrypted storage of credentials, and more specifically relates to CWE-319, the use of cleartext password in a user interface where masking should be applied. In terms of adversary behavior as defined by MITRE ATT&CK, this flaw facilitates Credential Access techniques such as T1078 Valid Accounts or potentially aids in T1552 Unsecured Credentials if attackers monitor logs for exposed secrets. To mitigate this risk, organizations running affected versions must immediately upgrade the Cisco Secure Malware Analytics app to version 2.4.5 or later where the sample_password parameter is correctly configured as a masked field. Until the update is applied, administrators should restrict access to users who strictly require execution privileges and monitor logs for any unusual activity involving action invocations that might indicate exploitation attempts. Additionally, reviewing historical run data may reveal previously exposed passwords which should be considered compromised and rotated immediately according to organizational password policies. Ensuring that all sensitive parameters in SOAR apps are properly tagged as secrets is essential to maintaining the confidentiality of security operations infrastructure.