MarkLogic Server CVE-2026-9203

Exploitation requires an authenticated MarkLogic session with at minimum a low-privileged role (confirmed by CVSS PR:L); unauthenticated exploitation is not possible. The cloud credential-theft impact is contingent on MarkLogic being hosted on a cloud VM with a reachable IMDS endpoint (AWS IMDSv1, Azure IMDS, or GCP metadata server) - on-premises deployments without IMDS infrastructure are not exposed to the credential disclosure impact described in the advisory, though the SSRF bypass capability may still exist. The high attack complexity (CVSS AC:H) indicates exploitation is not trivially scriptable: the attacker must know the specific technique to bypass MarkLogic's existing IMDS protections, limiting opportunistic exploitation. No user interaction is required, and the attack is fully remote over the network.

The CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H scores 8.5 (High) and is internally consistent with the described vulnerability: network-reachable, requiring a low-privileged account, with high complexity due to the bypass of existing IMDS protections, and a scope change reflecting cloud environment impact beyond the MarkLogic process itself. Real-world risk is sharply bifurcated by deployment context: cloud-hosted deployments face the full C:H/I:H/A:H cascade (stolen credentials enabling arbitrary cloud API calls), while on-premises deployments without IMDS infrastructure are exposed only to the generic SSRF capability with reduced credential-theft impact. No EPSS data was provided; no CISA KEV listing is present; no public POC has been identified - active exploitation is not confirmed. Despite the absence of KEV listing, the credential-theft impact class (cloud account takeover) warrants treating this as a high operational priority for cloud-hosted MarkLogic environments.

An attacker with a low-privileged MarkLogic account crafts a URL-fetching request using the specific bypass technique that circumvents MarkLogic's existing IMDS filter, causing the MarkLogic process to retrieve http://169.254.169.254/latest/meta-data/iam/security-credentials/ and return the response to the attacker. The attacker extracts the temporary AWS access key, secret, and session token from the response, then authenticates directly to the AWS API to enumerate and exfiltrate data from S3 buckets, RDS instances, or other resources accessible to the host's IAM role.