Progress MarkLogic Server EUVD-2026-97514

Exploitation requires (1) valid authenticated access to MarkLogic Server at low privilege (PR:L) and (2) the server deployed on a cloud platform where an internal metadata/credential service is reachable from the server's network position - the impact described (access to internal cloud services and cloud credentials) is specific to cloud-hosted deployments. The flaw is limited to Linux-based MarkLogic 12.x before 12.1.0 and 11.x before 11.3.7; non-cloud or on-premises deployments without reachable internal cloud services gain no credential-theft payoff, and no unauthenticated path exists. No user interaction is required (UI:N).

This is a credible mid-to-high priority issue for organizations running MarkLogic in cloud environments, but not a drop-everything emergency. The vendor-supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, base 8.5) describes a network-reachable, low-complexity SSRF requiring only low-privilege authentication, with a scope change reflecting access to resources beyond the vulnerable component (internal cloud services and credentials). No EPSS score was provided, so exploitation probability cannot be quantified. The CVE is NOT listed in CISA KEV and no public POC is referenced, so there is no public exploit identified at time of analysis - this is a vendor-reported (security@progress.com) finding, which typically indicates coordinated disclosure rather than observed in-the-wild activity. No SSVC decision data was supplied. The key tension is between the high CVSS (driven by the scope change and cloud-credential confidentiality impact) and the real-world gating factor: an attacker must already hold valid authenticated access to the MarkLogic Server AND the server must be deployed in a cloud environment exposing an instance metadata endpoint. Absent those conditions, real risk is materially lower than the 8.5 suggests.

An attacker with valid low-privilege MarkLogic credentials abuses a server-side feature that fetches remote URLs, pointing it at a cloud instance metadata endpoint (e.g., 169.254.169.254) or other internal-only cloud service. The server makes the request on the attacker's behalf and returns the response, exposing IAM/cloud credentials that can then be used to pivot into the broader cloud account. No public exploit code is referenced, and the low attack complexity means a working request would be trivial to craft once authenticated.