> Looking at the PHP bug tracker the specific bugs were fixed. So my best guess is that the LLM was able to find alternative variants that still worked?
In the link from the comment to which you replied, buried deep below the comic strips and all that, there is this explanation which seems to confirm your guess:
> Right. We should explain from the start. My first step of finding if any long-lost siblings of Stefan's 2004 bug were still lingering in the codebase was to look for ways to exceed the memory_limit that allows us to throw a controllable fatal. I asked my LLM companion for help.
> The first useful finding was a way to bypass the smaller post_max_size barrier that normally prevents a request from delivering enough memory pressure to reach memory_limit. PHP compares post_max_size with the declared Content-Length before automatic POST parsing begins, but it does not enforce the same limit against the bytes it actually consumes. Apache can therefore pass a chunked HTTP/1.1 or lengthless HTTP/2 multipart request with no meaningful declared length. A configured input-decompression filter creates the same mismatch between the compressed length and the decoded stream.
> The second useful finding was a way to exhaust memory_limit with a multipart request that remains below post_max_size. An RFC1867 file-upload part with filename="" contains no file data, and PHP does not count it toward max_file_uploads. PHP still creates all six corresponding $_FILES entries: name, full_path, type, tmp_name, error, and size.
Might be your ISP's DNS censoring the domain name, it happens to me for different ones depending on whether I am in Spain or in Germany at the moment when I click the link.
It might work if you manually change the TLD part of the URL.
What I did was get the IP address when it worked and add it to "/etc/hosts" so it works when on another network.
In the link from the comment to which you replied, buried deep below the comic strips and all that, there is this explanation which seems to confirm your guess:
> Right. We should explain from the start. My first step of finding if any long-lost siblings of Stefan's 2004 bug were still lingering in the codebase was to look for ways to exceed the memory_limit that allows us to throw a controllable fatal. I asked my LLM companion for help.
> The first useful finding was a way to bypass the smaller post_max_size barrier that normally prevents a request from delivering enough memory pressure to reach memory_limit. PHP compares post_max_size with the declared Content-Length before automatic POST parsing begins, but it does not enforce the same limit against the bytes it actually consumes. Apache can therefore pass a chunked HTTP/1.1 or lengthless HTTP/2 multipart request with no meaningful declared length. A configured input-decompression filter creates the same mismatch between the compressed length and the decoded stream.
> The second useful finding was a way to exhaust memory_limit with a multipart request that remains below post_max_size. An RFC1867 file-upload part with filename="" contains no file data, and PHP does not count it toward max_file_uploads. PHP still creates all six corresponding $_FILES entries: name, full_path, type, tmp_name, error, and size.
> https://calif.io/php2shell/#you-said-oom-fatal
reply