Hacker News Reader

Comment by randomblock1 | Hacker News Reader

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.

View on HN

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?

https://www.php.net/archive/2026.php#2026-10-21-5

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.

What advantage would that give an attacker here?

The front page is index.php

Reply on news.ycombinator.com