CVE-2026-85971 in MarkLogic Server
Summary
by MITRE • 10/12/2026
Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 assign overly permissive operating-system permissions to certain log files, which could allow a local user to read or alter log data. The corrected default permissions apply to newly created and rotated logs; existing logs retain their current permissions until remediated.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Progress MarkLogic Server versions prior to 12.1.0 and 11.x releases before 11.3.7 represents a critical misconfiguration of file system access controls that undermines the integrity and confidentiality of operational logging mechanisms. This issue stems from an overly permissive assignment of operating-system permissions to specific log files generated by the application. In secure software design, log files often contain sensitive information such as authentication attempts, internal error states, configuration details, or user activity traces. When these files are created with broad read and write access rights, they become susceptible to unauthorized interaction by any local user account on the host system where MarkLogic is deployed. This flaw effectively bypasses the application-level security controls that might otherwise restrict who can view or modify internal operational data, creating a significant gap in the defense-in-depth strategy of the server infrastructure.
From a technical perspective, this vulnerability aligns with CWE-732, which describes improper assignment of permissions to critical system files. The root cause lies in the default configuration logic used during log file creation and rotation processes within these specific versions of MarkLogic Server. When new logs are generated or existing ones are rotated into archival states, the operating-system level permission bits are set too broadly, typically allowing group-read-write or world-readable attributes that exceed what is necessary for the application's normal operation. This misconfiguration allows any local user to not only read sensitive log entries but also alter them. The ability to modify logs is particularly dangerous as it enables an attacker to cover their tracks by deleting or changing audit trails after a compromise, thereby hindering forensic analysis and incident response efforts.
The operational impact of this vulnerability extends beyond simple data leakage. An adversary with local access can exploit these permissive permissions to perform log injection attacks, inserting false entries that could trigger automated alerts for benign activities while masking malicious ones. This capability directly supports the ATT&CK technique T1070, specifically sub-techniques related to Indicator Removal on Hosts such as clearing logs or modifying audit logs. By manipulating the integrity of these records, an attacker can evade detection mechanisms and maintain persistence within the environment without triggering security information and event management (SIEM) alerts that rely on log consistency. Furthermore, reading sensitive log data could reveal internal network topology, database structures, or credential hashes if they are inadvertently logged, facilitating further lateral movement or privilege escalation attacks against other systems in the enterprise network.
Remediation of this issue requires a two-pronged approach addressing both new deployments and existing installations. For newly created logs, upgrading to MarkLogic Server version 12.1.0 or later for the 12.x branch, or version 11.3.7 or later for the 11.x branch, will automatically apply corrected default permissions that adhere to the principle of least privilege. However, it is crucial to note that this upgrade does not retroactively fix existing log files on disk. Administrators must manually audit and correct the file system permissions of all current log directories and rotated log archives to ensure they are restricted to only those users or groups strictly required for operational maintenance. Implementing automated configuration management tools can help enforce these permission standards across the infrastructure, ensuring that any future log rotations adhere to secure defaults and preventing recurrence of this vulnerability in subsequent deployments.