For PHP this happens before your script starts. PHP reads the body, turns urlencoded forms into $_POST, splits multipart bodies into fields and files, applies limits such as post_max_size and max_input_vars, and runs handlers such as the session upload progress handler. Only then does application code run.
That ordering is the catch. A bug in parsing runs before any login check, CSRF check or maintenance mode, so protections inside the application cannot stop it. Settings changed later also come too late: ini_set() and .user.ini apply after PHP has already parsed the request. And parsers disagree. PHP accepts some multipart bodies that a WAF cannot parse, and its multipart parser is looser than a simple line-based matcher, since it tolerates folded headers and missing spaces.
In October 2026, PHP said that the mod_php attack on CVE-2026-109618 completes before any application code runs, through an oversized form field name that exhausts memory during parsing. For CVE-2026-109619, the session upload progress callback fires on any POST endpoint before application code, and researchers described exploit bodies of only about 450 bytes. ModSecurity rules published for the flaws reject bodies that ModSecurity cannot parse, because PHP may still read them.
Set parsing-related settings in php.ini, the pool or the server configuration. Block request shapes your application never uses, for example multipart bodies, at the web server or edge. Never judge a body by its Content-Length header, since chunked and HTTP/2 requests may not have one, and keep the PHP patch in place as the real fix.