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.
The site is not vulnerable to PHP2Shell because it doesn't actually run any PHP code. It just serves static files. The static file handler does not call code that PHP2Shell exploits. Every request leads back to the same static page.
> (AI) "A static handler (nginx’s static path, or php_cli_server_begin_send_static) just sends bytes; it never enters the PHP request lifecycle, so php_request_startup() never runs and the Zend executor/session/multipart parser the chain needs is never initialized."
The author is trying to prove their point that PHP2Shell is hard to exploit. But it's unrealistic because PHP servers usually run PHP code at some point.
Yep. It had to add a Dockerfile to build MediaWiki using vulnerable versions but it's that, a compose file, and a Python file. To be clear it still has a lot of the limitations of the other POCs, but it does work.
Yes, it was actually using php2shell. Not a mediawiki vulnerability. It was the easier and less resilient variant of php2shell, but still a real POC. I'm confident that it could also do Wordpress if tasked to.
I have a working php2shell RCE against a stock nginx+mediawiki1.45.1+php8.4.26 docker container now. Wrote it with LLM assistance while watching Formula 1.
Yep. I pointed an agent at the Twitter post about the "working exploit that gets a shell on an unmodified MediaWiki installation.". 5 minutes later it spins up a stock MediaWiki and proves its POC. It modified someone else's POC from Github, but that's still trivial.
Everyone knows that MediaWiki is exploitable. The story running around is exactly that this is generally exploitable even for simple apps serving static content like this.
https://cursor.com/blog/typescript-sdk
reply