CVE-2026-76376 in AWS IAM App for SOAR
Summary
by MITRE • 08/19/2026
In versions below 2.1.9 of the AWS IAM app for Splunk SOAR, a user who holds a role with permission to run actions could expose sensitive AWS credentials by invoking an action that accepts the credentials parameter, because the 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).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in AWS IAM app versions prior to 2.1.9 for Splunk SOAR represents a critical information disclosure flaw rooted in improper credential handling within the application's user interface logic. The core technical deficiency lies in the failure of the software to classify specific input parameters as sensitive data types, specifically passwords or secrets. In secure software design, any field intended to accept authentication credentials such as AWS access keys and secret tokens must be programmatically flagged so that the rendering engine applies appropriate obfuscation techniques, typically masking characters with asterisks or dots during display. Because this flagging mechanism was absent for actions accepting a generic credentials parameter, the application treated these sensitive inputs as standard text fields, resulting in their exposure in cleartext within the graphical user interface and potentially in associated logs or API responses depending on how Splunk SOAR processes action outputs by default.
From an operational perspective, this flaw allows any authenticated user with permission to invoke actions that require AWS credentials to view those credentials without restriction. In a typical Security Orchestration, Automation, and Response (SOAR) environment, multiple users often share access to playbooks or automated workflows. If one user can inspect the parameters of another user's action execution history or configuration, they gain immediate read-only access to high-privilege AWS account keys. This undermines the principle of least privilege and compromises the confidentiality guarantee expected in enterprise security operations centers where sensitive cloud infrastructure credentials are routinely managed through such platforms. The impact is severe because exposed AWS credentials can be directly exploited by attackers to assume IAM roles, access S3 buckets, launch unauthorized instances, or pivot into other parts of the cloud environment, leading to potential data breaches and service disruption.
This vulnerability aligns with CWE-522, which describes Insufficiently Protected Credentials, as well as CWE-798, Use of Hard-coded Credentials if the credentials were inadvertently stored in a way that made them retrievable via this UI flaw. Furthermore, from an adversary behavior perspective, it facilitates reconnaissance and credential harvesting activities consistent with MITRE ATT&CK technique T1078, specifically Valid Accounts or Cloud Accounts, where attackers seek to obtain legitimate authentication material to maintain persistence or escalate privileges without triggering immediate detection mechanisms associated with brute-force attacks. The lack of masking also violates general security best practices for user interface design that mandate the protection of sensitive data at rest and in use within administrative consoles.
To mitigate this risk, organizations must immediately upgrade the AWS IAM app for Splunk SOAR to version 2.1.9 or later where the parameter classification logic has been corrected to ensure credentials are masked appropriately during display. In addition to patching, administrators should audit existing playbooks and action configurations that utilize credential parameters to identify any potential historical exposure of sensitive data in logs or UI history views. It is also recommended to rotate all AWS keys associated with accounts managed by the affected app versions as a precautionary measure, assuming that some credentials may have been viewed by unauthorized parties during the period when the vulnerability was present. Implementing strict access controls on who can view action execution details and enabling audit logging for credential-related actions further reduces the attack surface and supports forensic analysis in the event of future incidents.