CVE-2026-85961 in MarkLogic Server
Summary
by MITRE • 10/12/2026
On Azure deployments, Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 may record security-sensitive authentication information in diagnostic logs under certain configurations. An attacker with access to the affected logs could use this information to obtain unauthorized access to protected cloud resources.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified involves a critical misconfiguration or implementation flaw within Progress MarkLogic Server versions 12.x prior to 12.1.0 and version 11.x prior to 11.3.7, specifically in environments deployed on Microsoft Azure. The core technical issue lies in the logging mechanism of the application server, which inadvertently captures security-sensitive authentication data into diagnostic log files under specific configuration settings. This behavior represents a failure to properly sanitize or exclude sensitive credentials from output streams that are intended for operational diagnostics rather than security auditing. When such logs are generated, they may contain plaintext passwords, session tokens, API keys, or other credential material required for authenticating users and services within the MarkLogic ecosystem.
From an industry standard perspective, this vulnerability aligns with CWE-532, which is defined as Information Exposure Through Log Files. This classification highlights that sensitive information was exposed via log files in a way that could be exploited by attackers to compromise system security. Furthermore, the exploitation of this flaw maps directly to MITRE ATT&CK technique T1078, specifically Valid Accounts, and potentially T1530, Data from Cloud Storage Objects if the logs are stored in accessible Azure Blob storage or similar diagnostic repositories. The presence of credentials in log files creates a direct pathway for privilege escalation and unauthorized access, as these artifacts often persist longer than active sessions and may be retained by system administrators or automated monitoring tools without adequate protection.
The operational impact of this vulnerability is severe due to the cloud-native context of Azure deployments. Diagnostic logs are frequently aggregated into centralized logging solutions such as Azure Monitor Log Analytics or sent to external SIEM platforms for analysis. If these log ingestion pipelines do not implement strict data loss prevention rules or redaction policies, the sensitive authentication information becomes widely accessible within the organization's infrastructure. An attacker who gains access to any system with read permissions on these logs can extract valid credentials. These credentials can then be used to authenticate against MarkLogic services, potentially granting the attacker administrative privileges depending on the account associated with the leaked data. This could lead to unauthorized modification of database contents, exfiltration of sensitive enterprise data stored within MarkLogic, or further lateral movement across the Azure environment using compromised service principals or user accounts.
Mitigation strategies must focus immediately on restricting access to diagnostic logs and remediating the root cause in the application configuration. Administrators should audit all log storage locations associated with MarkLogic instances, including local disk paths and cloud-based logging destinations, ensuring that only authorized personnel have read access. It is imperative to rotate any credentials or secrets found within these logs immediately to invalidate potentially compromised authentication material. For long-term remediation, Progress recommends upgrading to version 12.1.0 or later for the 12.x branch, or version 11.3.7 and later for the 11.x branch, as these releases address the logging behavior that exposes sensitive data. Additionally, organizations should implement log redaction policies at the infrastructure level using Azure Monitor diagnostic settings to filter out patterns resembling passwords or tokens before logs are stored or forwarded, thereby reducing the attack surface even if similar vulnerabilities exist in other components of the stack.