[chockchocschoir]

Even if someone wrote code like that, they'd have to have configured their web server to accept 4GB of input somewhere, which gets passed to that function. That adds another "rare +" instance, as most web servers ship with way lower defaults than that.

[spacemanmatt]

<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>

[chockchocschoir]

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.

[spacemanmatt]

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.