CVE-2026-9203 is a server-side request forgery in MarkLogic that can be exploited with low-privilege authentication to reach cloud metadata services (AWS IMDS, Azure instance metadata, GCP metadata endpoint). The critical takeaway is not the SSRF itself — that's a well-known vulnerability class — but what becomes accessible when low-privilege authentication is the only barrier.
Most organizations design access controls around a blast-radius assumption: low-privilege users can only reach low-value targets. This CVE collapses that assumption. A low-privilege MarkLogic account can now fetch cloud instance metadata, which contains temporary credentials for the instance profile. Those credentials often permit significant lateral movement — spawning resources, accessing S3 buckets, querying managed databases. The low-privilege foothold becomes a cloud infrastructure compromise.
The metadata endpoint protections that cloud providers deploy rely on signals like request origin validation or path restrictions. This exploit bypassed those checks, likely by presenting as a legitimate internal request rather than an external attacker. That bypass mechanism — application-layer validation being used as a proxy for network-level trust — is the pattern you should audit across other services running on the same cloud instances.
For immediate action: verify whether your MarkLogic instances have IMDS enabled and whether the instance profile grants excessive permissions. If you cannot patch immediately, network-level controls take precedence — enforce IMDSv2, attach instance profiles with explicit deny statements for metadata access from MarkLogic, or use security groups to block metadata IP ranges from MarkLogic-bound traffic.
The EPSS score of 0.00212 likely reflects deployment prevalence as much as exploitability. Many organizations have already neutralized this class of attack through infrastructure hardening (IMDSv2, instance profile restrictions, network ACLs). Treat this CVE as a forcing function to audit which of your cloud workloads still rely on application-layer authentication as the sole metadata service barrier — because infrastructure-level controls are what will protect you when the next SSRF in the same category emerges.