Cool research post introducing a few ModSecurity rule bypasses abusing different parser errors in the ModSecurity Code Rule Set. While those specific to ModSecurity are probably patched by now. In some cases the same sorts of parsing issues can occur on the backend.

1. Content-Type Confusion - This abuses the regex matching used to decide what body parser to use. A content-type header like application/x-www-form-urlencoded;boundary="application/xml" gets interpreted as XML because of the presence of application/xml in the header. Similarly using application/json will trick the parser into parsing as a JSON body. The XML case was most useful as ModSecurity would ignore comments in the XML allowing content to be smuggled through.
2. multipart/form-data parsing issues. The first issue presented isn’t actually an issue in ModSecurity but is a potential issue in the backend parser and whether or not they parse empty body sections correctly. ModSecurity does, but on some backends (the author calls out PHP here) the parser will continue over the empty body joining it with the next header and body until the next separator. The second issue was ModSecurity treating a single \n as a \r\n. Leading to parsing two (or more) parameters where most backends would only see one.
3. Charset Confusion (CVE-2022-39955). ModSecurity only looks at the first charset and blocks anything that isn’t utf-8. Using a Content-Type header of application/json;charset=utf-8;charset=utf-7 the author was able to smuggle in UTF-7 content that would be opaque to ModSecurity but decoded properly by the express backend.