CVE-2026-76374 in AD LDAP App
Summary
by MITRE • 08/20/2026
In versions below 2.3.8 of the AD LDAP app for Splunk SOAR, a user who holds a role with permission to run actions could cause sensitive Active Directory response data to be written to a persistent debug log file by triggering write operations through the app. 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).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in versions of the AD LDAP app for Splunk SOAR prior to 2.3.8 represents a significant information disclosure risk stemming from improper handling of debug logging mechanisms within the application's interaction with Active Directory services. This flaw allows an authenticated user, provided they possess a role that grants permission to execute actions or commands via the platform, to inadvertently or intentionally trigger write operations that expose sensitive data. The core technical issue lies in the app's configuration and implementation of its internal logging subsystem, which fails to adequately sanitize or suppress debug-level output when processing responses from Active Directory Lightweight Directory Services (AD LDS) or standard LDAP queries. Consequently, detailed response payloads containing directory entries are persisted to a persistent log file on the underlying system rather than being discarded after use or masked appropriately for non-debug environments.
From an operational perspective, this vulnerability enables unauthorized access to sensitive organizational data stored within the Active Directory infrastructure. The exposed information can include user attributes such as email addresses, phone numbers, job titles, departmental affiliations, and potentially hashed passwords or security identifiers depending on the specific query executed and the permissions of the service account used by Splunk SOAR for LDAP authentication. This exposure violates fundamental principles of data confidentiality and least privilege, as users with standard action-execution privileges are able to retrieve information that may exceed their intended scope of access based solely on the verbosity level of the logging mechanism. The persistence of this data in log files further exacerbates the risk by creating a long-term attack surface where attackers can review historical logs to build comprehensive profiles of the organization's personnel and infrastructure, facilitating social engineering attacks or lateral movement within the network.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-209: Generation of Error Message Containing Sensitive Information, as well as CWE-532: Insertion of Sensitive Information into Log File. The exploitation path is consistent with ATT&CK technique T1078: Valid Accounts, where an attacker leverages legitimate credentials and permissions to access resources they should not be able to view, specifically through the mechanism of log file analysis which falls under data exfiltration techniques such as T1560: Archive Collected Data or direct reading of system files. The impact is particularly severe in regulated environments where compliance frameworks like GDPR, HIPAA, or PCI-DSS require strict controls over personal and sensitive data handling to prevent unauthorized disclosure.
To mitigate this vulnerability, organizations running Splunk SOAR with the AD LDAP app must immediately upgrade to version 2.3.8 or later, which addresses the improper logging behavior by ensuring that debug-level details are not written to persistent storage unless explicitly configured for development purposes in a secure environment. Administrators should also review existing log files on affected systems and securely delete any logs containing sensitive Active Directory response data generated prior to the patch application. Furthermore, it is recommended to implement strict access controls around log file directories using operating system-level permissions to restrict read access to only those users who require visibility into debug information for troubleshooting purposes. Regular auditing of logging configurations across all integrated apps should be conducted to ensure that verbose output does not leak sensitive context data in production environments, thereby maintaining the integrity and confidentiality of the security operations platform's interactions with external directory services.