CVE-2026-85952 in MarkLogic Server
Summary
by MITRE • 10/12/2026
Affected Linux-based Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 contain a server-side request forgery vulnerability that could allow an authenticated attacker to access internal cloud services, potentially resulting in unauthorized access to cloud credentials.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The identified security flaw resides within Progress MarkLogic Server versions running on Linux-based operating systems, specifically affecting 12.x releases prior to version 12.1.0 and 11.x releases prior to version 11.3.7. This vulnerability is classified as a server-side request forgery, commonly referred to by its acronym SSRF. The core technical deficiency lies in the application's insufficient validation of user-supplied input when constructing outbound HTTP requests. An attacker who has successfully authenticated to the MarkLogic Server can manipulate these inputs to direct internal service calls toward unintended destinations. Instead of communicating solely with intended external or local endpoints, the server is coerced into making requests to internal cloud infrastructure services that are typically not exposed to public networks but remain accessible from within the application's execution environment.
The operational impact of this vulnerability is significant due to its potential for privilege escalation and data exfiltration through credential theft. By leveraging SSRF, an authenticated attacker can probe the internal network topology and interact with metadata endpoints or cloud provider APIs that are running on localhost or private IP ranges associated with the hosting infrastructure. This interaction allows the attacker to retrieve sensitive information such as access keys, secret tokens, and other authentication credentials stored in environment variables or instance metadata services. The compromise of these cloud credentials can lead to unauthorized access to broader cloud resources, including storage buckets, database instances, and compute engines, effectively bypassing perimeter security controls that rely on network segmentation to protect internal assets from authenticated application users.
From a classification perspective, this vulnerability aligns with CWE-918, which defines Server-Side Request Forgery as a weakness where a web server receives a URL or similar request from an upstream component and retrieves the contents of it without ensuring that the request is being sent to the expected destination. Furthermore, in the context of the MITRE ATT&CK framework, this behavior corresponds to techniques involving Cloud Infrastructure Discovery and Credential Access, specifically T1580. The exploitation path typically involves the attacker identifying endpoints within the MarkLogic API or administrative interface that accept URL parameters without rigorous sanitization, thereby enabling them to craft malicious payloads that redirect traffic to internal cloud metadata services such as AWS Instance Metadata Service (IMDS) or Azure Managed Identity endpoints.
Mitigation strategies must prioritize immediate patching and defensive configuration changes. The primary remediation is to upgrade the MarkLogic Server installation to version 12.1.0 or later for the 12.x branch, or version 11.3.7 or later for the 11.x branch, as these releases contain fixes that enforce stricter input validation and restrict outbound request destinations. In environments where immediate patching is not feasible, network-level controls should be implemented to block outbound traffic from the MarkLogic server hosts to internal cloud metadata endpoints unless explicitly required by application logic. Additionally, implementing strict egress filtering rules can prevent SSRF attacks from reaching sensitive internal services. Security teams should also audit existing configurations for any exposed administrative interfaces and ensure that authentication mechanisms are robustly enforced to limit access to only authorized personnel with the principle of least privilege applied to all API endpoints.