According to this post, one of the researchers was a former PHP security lead who already knew about the bug since 2004. So I'd assume they would be taken as credible by the current team https://calif.io/php2shell/
As I mention elsewhere (https://bugs.php.net/bug.php?id=78876) I'm very confused. 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? But then the report makes less sense.
> 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.
Assuming that it could have been spotted in their inbox, amongst a probable flooded of LLM slop like a number of security mailing lists for open source projects that I know of. We've all seen the impact on open source github issues, hackerone etc. The same is happening to standard email disclosure paths.
> 1 August 2026: 2 days after OpenAI invites Calif to join its “Patch the Planet” initiative, Ryan Austin finds the RCE paths, tweets a cryptographic hash on 5 August, and submits the bug and working RCE proof-of-concept to PHP between 11 August and 14 August.
I'm surprised by CGI. The vulnerability description talks about a second request being affected by corrupted state from an earlier request. But I thought CGI only processes one request per process?
There were OSS implementations of that but MCP came with anthropic backing and won.
Like VHS and Betamax, sometimes you just have to accept that marketing wins over engineering purity.
reply