I believe it's not exploitable. People say that it's obviously easy when you know the exact config. So can you proof it's even possible? I am pretty outspoken about php2shell being realistic to exploit, so I am happy to independently verify to everybody that it is a realistic setup. You can reach me @LiveOverflow on Twitter or so.
OP confirmed that the server was initially serving only an index.html. In that configuration, the vulnerable code path is never reached — it requires a .php file.
OP added php-version.php roughly 18–19 hours into the experiment (I'm not sure of the exact timing), so that period should be subtracted from the publicly displayed challenge duration.
Based on my external fingerprinting, I now believe the setup should actually be exploitable!
However, the server is being absolutely hammered with requests and crashes. Making it significantly harder to pull off. This is imo still an unrealistic target. If you are not taking the top 1% PHP websites, then they will have long periods (1 minute) of no traffic.
If someone manages to pull off a working exploit under these conditions, that would be crazy to me.
Yes! Was serving pure html through PHP before 13:00-ish UTC when I added that page. From the traffic, it seems plausible that some people have an theoretical exploit path through PHP's HTML server itself, without relying on PHP functions, but no one has pulled it off quite yet.
Wait what? You're saying you believe php2shell is "realistic to exploit" but that the site owner has to be the one to do the exploit to prove to you that you're correct?
Where did the OP confirm that? All I saw was OP satisfying the haters by putting a page that explicitly uses PHP. However, people were reporting seg faults on PHP prior. Can't do that if PHP isn't accessible right?
Ive been pretty skeptical of your coverage as well, and you're in the OpenAI daybreak program and huffing and puffing about how great OpenAI is while having 900k subs, seemingly only talking up OpenAI products...
OpenAI and others are infesting the influencer space with what is basically dark money, not saying you're one of the guys on the take but I just don't trust any large influencer atm who only talks positively about OpenAI (or any lab).
I guess you can prove us AI cyber doubters all wrong with this CtF tho.
Not gonna defend the OpenAI shilling, but the guy recently had a pretty brutal tragedy in his personal life and I assume the AI content is just a low effort move to keep the channel and marketing for his business afloat. The lack of elaborate educational content may be rather a symptom of personal resource exhaustion and struggle, than popular enshittification. Time will tell, but maybe cut him some slack for the moment.
If it's nginx + fpm + "empty" index.php, it's a meme and not exploitable.
edit: looks more like nginx + cli-server. But the 1MB nginx body limit is annoying. Why is nobody setting up these CTF servers with a setup people actually say would be easy to exploit. Like a LAMP stack.
This is easy to exploit for example:
`docker docker run -d --rm -p 0.0.0.0:80:80 wordpress@sha256:c96e9e9a8ead2fea02f05469b356134da45681aaefa0f961a87653d58c462794` (basically `wordpress:7.1.3-php8.5-apache` with vulnerable php version 8.5.11)
I think the point is it is hard to claim that this exploit is the "end of the world", if it is trivially defeated by the default setup. Almost every deployment of php is going to be fronted by apache or nginx, and the default client_max_body_size for nginx is 1m.
I didn't say it's "end of the world". I am just saying it's an insane vulnerability.
It's not easily defeated by the default setup. Quite the contrary, the default setups are great. Typical apache + mod_php is the easiest to exploit. For example:
- Docker image `php:8.5.11-apache` is easy to exploit.
- Or the WordPress blog I installed with Digital Ocean template in 2023.
> It's not easily defeated by the default setup. Quite the contrary, the default setups are great. Typical apache + mod_php is the easiest to exploit.
But apache + mod_php hasn't been the default setup for a very long time, that's what people are trying to tell you. Given your expertise, you must know that already. So I have to conclude that you're arguing in bad faith because it's the only setup you can break.
The first comment in that page literally says "the preferred method is now fastcgi" and links to PHP-FPM. This comment is 13 years old, and I personally haven't seen mod_php in the wild for a long time. PHP-FPM is also the default configuration in both Red Hat and Debian and in most operating systems derived from them.
Hi LiveOverflow, I'm Elias and you made a video reply to my blog post. Why did you delete my comment on your video? (EDIT: Youtube fucked with my comment, not LiveOverflow! Editing to put this at the top of the thread so that it is read)
Your second exploit that you slopped out - after someone pointed out your first exploit depended on reading the container's memory via `/proc/pid/..` - also depends on an extremely contrived thing outside of a lab.
To get around the fact that you need to hit the same php worker over and over again (this is another way the LLMs were stacking the deck in their exploits; so many of the exploits online had php running with one worker - which is an unbelievably unrealistic precondition. That, and with ASLR off, lol.), you hold WORKERS-1 connections open indefinitely (lol) and then need to sequentially, and stably, hit the same php worker for 10-30 seconds.
Of course, luck is not a security boundary, everyone should still patch their servers.
But how is it a realistic precondition to have a server in which you are the *only* person making requests for 30 straight seconds? Even a single googlebot pinging the website would fuck your heap grooming up, let alone regular users, or another person trying the exploit out! Similarly, Holding WORKERS-1 connections open indefinitely so that you can isolate one php worker is extremely unrealistic in practice.
Yes. this is a vulnerability, it is bad. No, it is not easy to replicate in real world conditions. The LLM gets you an "exploit" locally. How on earth did you not extrapolate from the LLM decieving you the first time, and think for some reason the second time the conditions were 100% truthful? Did you even read the stdout from the exploit you wrote?
I really like your work man, you're a great inspiration, but what the fuck are you doing? And why delete my comment pointing this out?
I am not deleting any comments ever. I just checked, YouTube held your comment as "likely spam". I accepted it now and pinned it, I always appreciate it when sb is reaching out with a reasonable comment!
It is an absolutely slopped exploit, hahaha, I fully agree. But that was exactly my point. Memory corruption exploits over the internet have been historically extremely difficult. And it took many days of building a PoC. And this is clearly different now. And of course there are a lot of practical challenges, but that does not make it unrealistic vulnerability to exploit.
> But how is it a realistic precondition to have a server in which you are the only person making requests for 30 straight seconds?
I think it's VERY realistic. My random blog from 2023 https://raisistance.com has hours or days without requests. I think a majority of (old) PHP sites barely anybody visits. And there are tons of random company or government website without any requests at night or so. Also depending on the setup, there ar methods to deal with concurrent traffic. For example Apache (see here: https://x.com/LiveOverflow/status/2113555517339480284).
I think it's clear so far that it's not mass-exploitation material. But once you are more targeted and have a random LAMP stack, it becomes very realistic.
Would you setup a random vulnerable php version from Docker image like `php:8.5.11-apache` on a server, put a flag there, and give me the IP? For me this is a realistic setup and it's fairly easy to exploit.
Hey, good to hear that it was just YouTube holding the comment. I really thought you deleted it which was audacious. I'm now much less mad :P.
I think we can set up something interesting here, I'd be down to set up a little "PHP2Shell Olympics" as we change preconditions and see how well the exploits fare. I am pretty sure our opinions of "this can be exploited, and LLMs can aid a rapid exploit of previously-complex ASLR nonsense" and "it's difficult to do memory corruption over the internet; php2shell is not a log4shell moment" are mutually compatible.
My contact details are on the bottom of the blog post.
Really, your request log is empty for hours at a time? I find that hard to believe. Even old blog sites still get an insane amount of bot traffic. I have sites that are only barely in googles index and it’s pretty rare to see anything less than 1 req/s (99% bot traffic)
Yes! Even my own stuff sometimes goes a few hours to a day without a single request, the internet is either very slow and dead or super active, no in-between, I think it heavily depends on who indexed you and how big your site looks like or maybe identified stack (for vuln crawlers, i'd wager if they see a wordpress marker they'd put you on some list to get retried by the swarm) or something.
My datamining project for a game for example, that noone besides me and 2 friends use, gets thousands of requests per second, because all the AI bots found it and try to index every single page (thousands of ssr pages) and they repeat the requests when my cache-control headers expire (ie: when i consider the old page stale), so it's an endless stream (I dont mind the challenge of serving all of these at high performance xD).
My main website, in the same domain (not a subdomain), barely gets any requests, it only has the one main index page with a single link to the datamining subdomain, that's about it.
From my raisistance.com blog 10 October 2026 00:05:56–25 October 2026 09:25:02 UTC:
- 95.3% of seconds had zero logged requests
- 11,582 of 22,159 complete minutes (52.3%) had no requests. The longest quiet stretch was 27 minutes 26 seconds.
- 3,283 continuous quiet stretches lasted at least 120 seconds. Together they totalled 225 hours 27 minutes 27 seconds—61.0% of the logged timespan.
- Excluding Apache’s internal dummy connections: 3,305 qualifying stretches totalled 227 hours 1 minute 51 seconds—61.5% of the timespan.
- Of 38,389 seconds with exactly one request, 14,692 contained an Apache ::1 internal dummy connection. Others included homepage visits, WordPress login requests, crawlers, and scanner probes.
All the "working" php2shell exploits on GitHub and X are like that. There are ZERO publicly available RCE exploits for php2shell that actually work remotely on production deployments.
All of these RCE PoCs are local and rely on unrealistic setups because LLMs couldn't achieve RCE without resorting to reward hacking.
Well usually you have a PHP application actually doing something, not just serving static files. If it's just static files, PHP2Shell isn't really a thing.
