<security hat>
Sounds like you are arguing in favor of keeping this bug. An attacker could use it to move laterally once behind whatever proxy/WAF limited the content body size.
</security hat>
Fair presumption but no, I agree it should be fixed. I just don't agree with the authors idea of how important it is to fix it, as it's highly unlikely to be exploitable in the wild.
Even without any proxies/WAF, PHP is always run (except in development environments with `php -S localhost:4124`) behind a web server, usually apache or nginx. Not sure about apache, but nginx defaults to a limit of 1MB for the request size (via `client_max_body_size` https://nginx.org/en/docs/http/ngx_http_core_module.html#cli...) and I can imagine apache have a similar default as well. Even if you allow requests to carry 1GB of data, this is still not exploitable, and if you have that large requests anyways, you usually find another way of doing the transfer than using plain HTTP requests.
Understood! The config conditions for this exploit are a little bit reassuring but from a historical perspective, there is likely to be a related exploit found with different conditions.
Even without any proxies/WAF, PHP is always run (except in development environments with `php -S localhost:4124`) behind a web server, usually apache or nginx. Not sure about apache, but nginx defaults to a limit of 1MB for the request size (via `client_max_body_size` https://nginx.org/en/docs/http/ngx_http_core_module.html#cli...) and I can imagine apache have a similar default as well. Even if you allow requests to carry 1GB of data, this is still not exploitable, and if you have that large requests anyways, you usually find another way of doing the transfer than using plain HTTP requests.