Yeah, the specific setup is not vulnerable to PHP2SHELL. CLI server + 1 MiB cap + inert page + high memory limit removes all the possibilities from the two CVEs. It would just be collecting POCs for actually vulnerable setups.
I'm just an interested bystander, but this seems like a (near?) default nginx config. Is that accurate?
Inert files are unrealistic, normally you use PHP server to execute PHP code, which this website doesn't appear to do (only static files). And suppose you want to accept >1mb file uploads, that limit would get in your way. So it's not a good representation of a PHP application, but for other uses it's reasonable.
So why did the original warning put out by the PHP team say that the exploit didn't rely on the application code and simply having software like Apache mod_php running would be enough?
You can still trigger DoS. And these can be chained with other vulnerabilites. The expectation of a PHP server executing PHP code also could have been implied.
DoS is independent of the vulns though. From what I understand, you can craft a request of x size which consumes ~200x the memory on the server. Parallelize that and you can DoS servers with only a few GB of memory, even with the 1MiB Nginx limit.
I think we can agree the statement makes the implied assumption you still do have a reason to run PHP. It doesn't matter what application needs PHP, as long as it's an application needing PHP. Delivering a static webpage is not a reason to run PHP, that's webserver biz. I mean, c'mon, it's bug in the PHP backend, not the OS where the string "PHP" magically causes memory corruption. Something needs to be processes by PHP.