ModSecurity CVE-2026-52747

Exploitation requires that the target application (1) is protected by ModSecurity/libmodsecurity earlier than 3.0.16, (2) accepts multipart/form-data request bodies, (3) enforces detection rules that inspect the ARGS or ARGS_POST collections, and (4) runs a backend that preserves embedded CR/LF in form-field values so its parsing diverges from ModSecurity's - the payload's malicious effect must specifically depend on a line break that ModSecurity removes but the backend keeps. It is unauthenticated and remote (CVSS PR:N/AV:N/UI:N, AC:L), so no credentials or user interaction are needed. What limits exploitation is the detection-gap nature of the flaw: it only matters where ModSecurity is the relied-upon control for the affected parameter, where a rule's match genuinely hinges on a preserved newline, and where the backend does not itself normalize away the same line break; it does not by itself grant code execution, disclose data, or affect requests sent as non-multipart content types.

This is a genuine security-control-bypass with a wide blast radius rather than a high-CVSS-but-low-impact issue: the CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N correctly captures a network-reachable, low-complexity, unauthenticated condition whose scope change (S:C) reflects that the harmed component is the protected backend, not ModSecurity itself, with high integrity impact and no confidentiality or availability loss. No EPSS score, KEV entry, POC, or SSVC decision data was supplied, so real-world exploitation frequency cannot be quantified from the input; absence of a KEV listing means there is no confirmation of active exploitation. The practical severity is modulated by a key dependency the CVSS score does not express: exploitation only yields impact when the defender actually relies on ModSecurity to inspect ARGS/ARGS_POST and when a rule's true/false decision hinges on a preserved line break, so the effective risk is a function of the deployed rule set and the specific backend's line-break handling rather than a universal RCE. Net: treat as a real priority for anyone using ModSecurity 3.x as a primary control, but recognize the impact is a detection gap, not direct code execution.

An attacker submits a crafted multipart/form-data POST to an application fronted by ModSecurity, placing a malicious payload (for example an injection string whose dangerous syntax is split by an embedded newline) inside a non-file form field. ModSecurity strips the line break before writing the value to ARGS/ARGS_POST, so the CRS or custom rule that would have flagged the payload sees a benign-looking single line and passes the request, while the backend reassembles or interprets the original bytes and executes the intended attack. No POC is referenced in the available data, and the low attack complexity plus lack of required authentication make delivery trivial.