MarkLogic Server EUVD-2026-53426

Exploitation requires the MarkLogic HTTP App Server to be deployed behind a reverse proxy or load balancer whose HTTP request parsing differs from MarkLogic's, and the attacker must be able to send a crafted HTTP/1.1 request containing both a Content-Length and a Transfer-Encoding header to that front-end. No authentication or user interaction is needed (PR:N/UI:N) against a vulnerable pre-11.3.6 / pre-12.0.3 server. Limiting factors: a direct MarkLogic deployment with no fronting proxy (or a proxy that strictly rejects ambiguous CL+TE requests, closes connections, or does not reuse back-end connections) is not exploitable, and success depends on a specific parser mismatch and connection reuse to smuggle the prefix into a victim's request stream.

The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9.1) indicates a network-reachable, unauthenticated, high-impact issue, and the impact set (auth bypass, session hijack, credential theft) is severe. However, real-world exploitability is gated by deployment: request smuggling only works when a reverse proxy sits in front AND its HTTP parsing differs from MarkLogic's - so I judge attack complexity higher than the vendor's AC:L (see my assessed vector). No EPSS was provided, so widescale exploitation probability cannot be quantified; KEV=NO and no POC is referenced, so this is a high-severity issue without confirmed active exploitation. SSVC framing: exploitation = none observed, technical impact = total for the App Server, automatable = likely no (requires per-target proxy discrepancy tuning). Net: patch-worthy priority for anyone running MarkLogic behind a proxy, but not evidence of mass exploitation.

An attacker sends a single HTTP request to the MarkLogic HTTP App Server through its reverse proxy containing conflicting Content-Length and Transfer-Encoding headers, so the proxy forwards what it sees as one request while MarkLogic parses a hidden second request smuggled in the body. The smuggled prefix is prepended to the next legitimate user's request on the reused back-end connection, letting the attacker capture that user's credentials or session token or reach authenticated endpoints without valid credentials. No public exploit is identified at time of analysis, but the CL/TE desync technique is well documented and reliable once a parsing discrepancy is confirmed.