As an outsider this was fun to watch. Namely, the dozens of l33t haxors including so-called "professionals" who claimed they'd be able to solve this in a jiffy with their magic exploits, yet couldn't.
stackghost · 2026-10-26 04:16:12 UTC
The only professional I saw making that claim was the CEO of trailofbits who is a former NSA TAO member and doesn’t have anything to prove by talking a big game.
It wasn’t that difficult of an exploit, to be honest. I myself am not the leetest of the leet but I was most of the way there, having been set back by the downtime and my time zone. It’s definitely a fiddly, tricky exploit as most memory exploits are but I think the initial alarm was justified.
While waiting for the server to come back up, it took me about 3 hours with LLM assistance to write a php2shell RCE for nginx and mediawiki on the same version of php as TFA.
The biggest win, as others have also observe, was the demonstration that there aren’t swarms of automated pwnbots out there that will insta-root your server.
Considering the amount of downtime, I think that flag got got pretty quickly.
shawabawa3 · 2026-10-26 06:44:15 UTC
> to write a php2shell RCE for nginx and mediawiki on the same version of php as TFA.
Ok but a mediawiki page is obviously not comparable
People were complaining that originally it was just using php to serve a static index.html file
It looks like after 18-19hours they updated it to serve a real .php file and it was hacked less than 2 hours after that
stackghost · 2026-10-26 20:23:16 UTC
>Ok but a mediawiki page is obviously not comparable
The attack is against the underlying php install, and is application-agnostic, I was merely duplicating the trailofbits POC.
FreakLegion · 2026-10-26 10:00:07 UTC
> there aren’t swarms of automated pwnbots out there that will insta-root your server
There are, they just didn't have a working exploit. Anyone with a honeypot can tell you attempts were widespread going back to early last week, but it wasn't until Saturday that we started to see successes.
niallmurphy-ie · 2026-10-26 06:09:10 UTC
The initial server setup wasn't realistic and it wasn't exploitable apparently.
synarchefriend · 2026-10-26 10:18:59 UTC
The OP shows that it was, in fact, solved in a jiffy (a few hours work done largely by an LLM) with a magic (generally applicable) exploit. Given that, I suspect the reputable security experts in the thread who claimed they could solve it were telling the truth.
FergusArgyll · 2026-10-26 02:54:31 UTC
This was good wholesome fun!
Some foundation should do this for future cve's
NorwegianDude · 2026-10-26 02:59:42 UTC
To be fair, the person who created the challenge stated that is was a fairly standard setup, replicating something outside a lab, but in reality is was something completely different, and not anywhere near how PHP is usually used.
It used the development server in PHP, and did not even run requests with fpm or mod_php. Instead, it used the built in dev server of PHP, and just proxied requests from nginx to the php dev server.
Literally the first thing on top of the PHP docs about the dev server used here is this:
"Warning
This web server is designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network."
That is not something people do, and it also explains why the site was down all the time, cause the dev server is super slow, as it's not meant for this in any way shape or form. A real setup would add a few zeros to the requests per second a server could handle.
So all in all, this was very pointless, as it was nothing like real php sites. A shame, cause a realistic setup woild be more interesting and relevant to answer the question of how hard is it really to gain RCE on a normal site.
tonymet · 2026-10-26 04:19:31 UTC
are you saying this lead to dos (and less competition)? or easier penetration?
At first glance, this wouldn't affect demonstration of the vuln.
weird-eye-issue · 2026-10-26 04:52:57 UTC
That's interesting because there were people complaining yesterday that this was a fully static website with no PHP involved lol
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.
HITCON CTF has a realistic php2shell challenge. Think it has ended up with 0 solves so far, not sure.
ffaccount2 · 2026-10-26 08:21:52 UTC
There are many PoCs online that work on realistic setups (like PHP docker image). If you're curious you can try to replicate it locally.
someothherguyy · 2026-10-26 10:17:16 UTC
there are a number of php docker images. some are insecure by default.
many php setups sit behind nginx, caddy, or other webserver with a max body size limit.
anyone following OWASP / similar guidelines was probably okay here (for this particular PoC path), if not using apache/mod_php, i would think.
rockdoe · 2026-10-26 08:44:02 UTC
The "realistic setup" used for this didn't have a php page on it initially.
I'm skeptical of the value of such setups, unless it's clear it's an out of the box setup, and we already know those are totally broken.
I don't understand who these people think they are really fooling. Is this some AI denial?
gewetensleegte · 2026-10-27 09:10:36 UTC
you've been posting about "AI denial" all over this thread, feeling incompetent?
rockdoe · 2026-10-27 17:48:25 UTC
This isn't even a good attempt at trolling, do better.
toast0 · 2026-10-26 16:43:33 UTC
> "It is not intended to be a full-featured web server. It should not be used on a public network."
Behind nginx or similar isn't exactly on a public network. I don't think I'd run it that way, but I could see someone else doing it if they read the docs a certain way.
Apparently the wallet key wasn't on the server, like some in the original thread suspected, but perhaps not due to maliciousness after all.
zeratax · 2026-10-26 06:34:00 UTC
between the challenge being updated to actually run php and this only like 2-3 hours passed
yreg · 2026-10-26 06:57:33 UTC
I believe this managed to prove something.
Namely that the vulnerability was not that easy to exploit, meaning that the myriads of servers that stayed unpatched during those initial days are probably not all members of botnets now. (Contrary to what the discourse might have made it seem like.)
Sir68k · 2026-10-26 07:53:11 UTC
I would take the opposite conclusion: the initial exploiting took _only_ 19 hours due the non-standard setup, but now the setup can be trivially exploited by tuning the PoC. By now, bad actors will probably have tools that can exploit most common setups.
yreg · 2026-10-26 10:20:01 UTC
So what portion of the unpatched servers is pwned now? What's your guess?
tim1994 · 2026-10-27 07:17:05 UTC
It took 2-3 hours, not 19. The first version was a static index.HTML file and was not exploitable. People found out and contacted the challenge author. After the fix was public it has been exploited in a couple of hours.
kennywinker · 2026-10-26 08:19:54 UTC
I was sick when the news about php2shell broke, so ended up leaving two of my personal sites that use php un-patched for about 48 hours until my fever broke and I patched them. I didn’t get hacked. Was I just lucky and so shouldn’t infer anything about how hard it is to actually make use of this vulnerability? Probably.
MartijnHols · 2026-10-26 08:51:24 UTC
Another theory is your server got compromised but they cleared their tracks. Not every hacker wants to make a quick few cents from a miner that gets shut down in a day or two.
rockdoe · 2026-10-26 08:40:35 UTC
It took about 2 hours to get taken over and that was with a setup that's sufficiently non-standard that existing PoC would've needed tweaking.
The fact that people are still in denial over this is crazy.
yreg · 2026-10-26 10:18:13 UTC
Where do you get the two hours from? Did this attacker spend two hours on it, after 17 hours of others failing to break in?
> The fact that people are still in denial over this is crazy.
Maybe you misunderstand what I say.
Imagine the tens of millions of personal or small business websites running php. What's your guess, what portion of the unpatched ones is already pwned? Is it 1%? 5%? 15%? 50%? 95%?
What would you guess?
krial · 2026-10-26 10:37:11 UTC
According to the tweet below, the server didn't actually run any PHP code for the first 17 hours.
I don't understand what the upside was supposed to be from denying it. This has been an exceptionally weird couple of days. Was it an anti-AI thing?
jdiff · 2026-10-26 11:42:56 UTC
Just outrage/security fatigue I believe.
yreg · 2026-10-26 12:32:11 UTC
For me the key question is whether tens of millions of random unimportant websites were mass-hacked by AI agents creating sleeper botnets.
If you think so then express it clearly, I'm interested in those thoughts.
–––
Apparently the challenge was dubious so I’m not sure what to draw from it in the end.
akerl_ · 2026-10-26 13:41:53 UTC
A bunch of folks tried to say the challenge was dubious at best and that the vulnerability was a legitimate concern, and were told by commenters here that they were fearmongering or shills.
Evidence has shown they were pretty spot on about the first part (the test originally served static html, the php code wasn’t actually as vanilla as described, and the bitcoin key wasn’t actually there).
I’d have hoped this kind of clear vindication on the first point might have caused folks to revisit their stance on whether to trust the expert stance on the second. But maybe I’ve been overly optimistic.
vikramkr · 2026-10-27 15:58:53 UTC
Based on how quickly the CTF was won - yeah that seems very reasonable.
billypilgrim · 2026-10-26 13:57:13 UTC
It’s been going on for far longer, people want to believe all OpenAI and Anthropic are doing is pure marketing. When the first Fable results were released, everybody was skeptical (which is rational), but with every third party confirmation of the capabilities they doubled down that this must be even more marketing instead of admitting that they were wrong. To the point that they are no longer skeptical but in pure denial about what is happening.
tptacek · 2026-10-26 18:37:20 UTC
The trap everyone seems to fall into is that the two claims can be true simultaneously!
rcxdude · 2026-10-26 14:32:47 UTC
I suspect so, and just a general blowback effect where if what people perceived to be the message is even slightly more dramatic than the reality then there's tendency for many to overshoot reality in the other direction.
I mean what is the world coming to when security researchers cannot release a writeup that is designed to look like slop, and starts with a bunch of cartoons with lame cyberpunk and matrix references, without being ridiculed for taking the piss ...
rcxdude · 2026-10-27 10:57:30 UTC
Not long ago the opposite would be true and hackers would be ridiculed by their community for being too sterile and corporate, and everyone else would be ridiculed for over-indexing on playful presentation as opposed to the meat of the technical issue.
thaumaturgy · 2026-10-26 18:57:29 UTC
For me (I host a lot of PHP...):
1. First I hear about it is a heads-up at 5:00 am 21st.
2. Available info then is pretty much, "omg, it's the end of the internet".
3. There are no specifics available on exploitable configurations.
4. Updates are not expected to be available for at least two more hours, so people start deciding to do the Madagascar "shut down everything" meme.
5. Cloudflare says they're seeing exploits in the wild, well, that's not great.
6. I shut down everything, including a national brand, because wtf else am I supposed to do at this point?
7. Updates become available at 0645. Fortunately, I don't run my entire infra on Docker, so I'm immediately deploying the updates to all configurations and bringing sites back online approximately in order of traffic volume.
8. Still no specifics on the exploit.
9. A million vibe-coded PoCs appear on GitHub ... and none of them work.
10. It's late morning local time on the 21st and I'm still bringing things back online, having taken the day off from my regular job.
11. Conversation starts to shift towards, "...oh, did we over-react? How exploitable is this exactly?"
12. Still no specifics available.
13. Somebody on the internet gets as fed up as I am with the whole chaos vortex of idiocy and stands up a site saying, "okay, here's some money if you can exploit it."
14. Hours pass.
15. Still no specifics available.
16. Zeitgeist becomes, "I guess it's not exploitable after all."
17. The test site gets 'sploited.
18. Finally somebody actually posts the damn specifics -- namely, the person that grabbed the $2k.
19. Late morning local time on the 26th, and the conversation becomes, "well, obviously this was exploitable!" <-- we are here
Coincidentally, I just started reading Crisis Engineering, which seems like an excellent and applicable book, but I'm not sure who to beat with it.
tptacek · 2026-10-26 19:00:27 UTC
I mean, it's clear you have a valid reason to be irritated, but that's not the concern I have here. What's worrying is people applying motivating reasoning to talk themselves (and others) into believing the vulnerability simply isn't a big deal, which is clearly false.
thaumaturgy · 2026-10-26 19:31:41 UTC
Yeah. I'm choosing to believe that those people just over-weighted some previous info and are under-weighting the latest, but I dunno.
There's not a chance in hell that even half of the world's PHP has been updated, so I would expect that if we start seeing large-scale exploitation, those people will change their opinion pretty fast.
Being totally burned out on AI hype myself, I'm somewhat sympathetic towards the folks that are still thinking of this as just another example of that.
gewetensleegte · 2026-10-27 09:16:41 UTC
> Being totally burned out on AI hype myself, I'm somewhat sympathetic towards the folks that are still thinking of this as just another example of that.
I mean, it was also that it was marketed in the media as a security apocalypse and unpatched servers would be falling within 15 minutes after the patch got released. This didn't happen. And that definitely warranted skepticism. There's been MUCH more severe vulnerabilities in the past that just went by without OpenAI's marketing making everyone go crazy about it.
Also, almost all information about it was dressed up in slop. Because OpenAI didn't want us to forget that AI was involved, somehow.
gewetensleegte · 2026-10-27 09:13:58 UTC
> believing the vulnerability simply isn't a big deal, which is clearly false.
you keep repeating this, also when people make very valid other criticisms, such as the hype causing government websites to be pre-emptively shut down -- do you believe this was warranted?
because that is the criticism.
nobody, including that "PHP vuln isn't so bad" blog article, which was VERY clear about this, said you shouldn't patch your servers
what's worrying is that you keep making up straw men, but why?
this isn't about the vulnerability, it's about OpenAI's Patch The Planet hype train
tptacek · 2026-10-27 11:08:45 UTC
OpenAI didn't find this vulnerability.
anonymous908213 · 2026-10-27 14:28:31 UTC
No, but they were part of the PR blitz. The lack of real-world exploitation + Calif commissioning a fucking webcomic made me skeptical. That's not fucking normal. Given what a huge marketing stunt it turned into, and 1000 vibe coded PoCs that aren't PoCs, it was at least in the realm of possibility that Calif huffed their own vibes too hard. If you want people to take security risks seriously, making them into a media spectacle promoting OpenAI is not the way to do it.
tptacek · 2026-10-27 15:20:24 UTC
What does Calif commissioning a web comic have to do with anything?
anonymous908213 · 2026-10-27 17:53:49 UTC
It, along with the press releases and the cutesy domain names registered, shows that this was clearly being played up as a marketing stunt, with planned coordination of such ahead of time. As soon as you begin to use the security incident to communicate a coordinated narrative about how amazing AI is, it's the most given thing in the world that some people will become skeptical of the severity of it and whether it isn't being played up as the most impactful security vulnerability ever found (per the press release claims) solely as part of an attempt to make the AI company sound more impressive.
AI company tells you their AI was used to find the biggest vulnerability EVER, with much fanfare. Zero cases of exploitation in the wild. Zero publicly demonstrated PoCs. It would almost be weirder to not be skeptical at that point unless you for some reason trusted everything a marketing department says implicitly.
> These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history.
See also the parable "Boy Who Cried Wolf" for more insight into the human condition.
akerl_ · 2026-10-26 20:18:36 UTC
It’s worth noting that while folks were getting busy with 11 and 13, plenty of experts in the field were saying ~“yes, we do have viable exploits here, but we’re not sharing them at this time. This is a big deal.” And that the person who spun up 13 spun up a static html page at first and also misrepresented how vanilla the stack was.
We could have skipped from 7 to 19 if folks had just taken seriously the guidance from experts in the field.
vikramkr · 2026-10-27 15:56:54 UTC
It was exploited within 2 hours of the server being fixed to be vulnerable it proved the exact opposite of shat you're saying
rockrroku · 2026-10-26 07:45:10 UTC
Does php2shell works with PHP-fpm nginx? I can’t truly replicate that poc locally.
someothherguyy · 2026-10-26 11:22:50 UTC
in theory.
many common nginx setups and hardening suggestions would make it very difficult to exploit. as well as any sort of distributed architecture that doesn't pin requests to clients.
there could be other undiscovered paths to exploit this vulnerability though. the PoC here uses the disclosed path for exploiting on patch day, minus mod_php.
stavros · 2026-10-26 08:13:42 UTC
I actually had GLM 5.3 run against the site on the day, but it was around 2 am and I was pretty sleepy by 3. GLM found the memory overflow vulnerability but I stopped it before it could continue into retrieving something useful from it.
In retrospect, I should have just given it a /goal and let it run overnight.
pwython · 2026-10-26 11:20:10 UTC
I used Kimi K3.1 Pro to figure it out as soon as cloudlandsdev put php-version.php live. The exploit worked just like this in a local Docker lab. But the terms page of the contest prohibited "resource exhaustion," so it stopped there. Showing Kimi the PoC, it says:
"The winning chain deliberately used per-request memory exhaustion, which appears to violate the literal no-resource-exhaustion rule, although the organizer accepted the win."
someothherguyy · 2026-10-26 11:30:36 UTC
it doesn't sound like you understand what you are doing?
krzyk · 2026-10-26 16:01:55 UTC
Why? He clearly explained it, rules prohibited resource exhaustion literally, which is funny because it prohibited to do the exploit it was asked.
krzyk · 2026-10-26 12:34:27 UTC
Yeah, each agent stumbled upon this. While one of those CVS IS memory exhaustion.
Comments
It wasn’t that difficult of an exploit, to be honest. I myself am not the leetest of the leet but I was most of the way there, having been set back by the downtime and my time zone. It’s definitely a fiddly, tricky exploit as most memory exploits are but I think the initial alarm was justified.
While waiting for the server to come back up, it took me about 3 hours with LLM assistance to write a php2shell RCE for nginx and mediawiki on the same version of php as TFA.
The biggest win, as others have also observe, was the demonstration that there aren’t swarms of automated pwnbots out there that will insta-root your server.
Considering the amount of downtime, I think that flag got got pretty quickly.
Ok but a mediawiki page is obviously not comparable
People were complaining that originally it was just using php to serve a static index.html file
It looks like after 18-19hours they updated it to serve a real .php file and it was hacked less than 2 hours after that
The attack is against the underlying php install, and is application-agnostic, I was merely duplicating the trailofbits POC.
There are, they just didn't have a working exploit. Anyone with a honeypot can tell you attempts were widespread going back to early last week, but it wasn't until Saturday that we started to see successes.
It used the development server in PHP, and did not even run requests with fpm or mod_php. Instead, it used the built in dev server of PHP, and just proxied requests from nginx to the php dev server.
Literally the first thing on top of the PHP docs about the dev server used here is this: "Warning This web server is designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network."
That is not something people do, and it also explains why the site was down all the time, cause the dev server is super slow, as it's not meant for this in any way shape or form. A real setup would add a few zeros to the requests per second a server could handle.
So all in all, this was very pointless, as it was nothing like real php sites. A shame, cause a realistic setup woild be more interesting and relevant to answer the question of how hard is it really to gain RCE on a normal site.
At first glance, this wouldn't affect demonstration of the vuln.
Nitter mirror: https://nitter.netbub.com/LiveOverflow/status/21144120728052...
many php setups sit behind nginx, caddy, or other webserver with a max body size limit.
anyone following OWASP / similar guidelines was probably okay here (for this particular PoC path), if not using apache/mod_php, i would think.
I'm skeptical of the value of such setups, unless it's clear it's an out of the box setup, and we already know those are totally broken.
I don't understand who these people think they are really fooling. Is this some AI denial?
Behind nginx or similar isn't exactly on a public network. I don't think I'd run it that way, but I could see someone else doing it if they read the docs a certain way.
Apparently the wallet key wasn't on the server, like some in the original thread suspected, but perhaps not due to maliciousness after all.
Namely that the vulnerability was not that easy to exploit, meaning that the myriads of servers that stayed unpatched during those initial days are probably not all members of botnets now. (Contrary to what the discourse might have made it seem like.)
The fact that people are still in denial over this is crazy.
> The fact that people are still in denial over this is crazy.
Maybe you misunderstand what I say.
Imagine the tens of millions of personal or small business websites running php. What's your guess, what portion of the unpatched ones is already pwned? Is it 1%? 5%? 15%? 50%? 95%?
What would you guess?
https://x.com/LiveOverflow/status/2114412072805208237
If you think so then express it clearly, I'm interested in those thoughts.
–––
Apparently the challenge was dubious so I’m not sure what to draw from it in the end.
Evidence has shown they were pretty spot on about the first part (the test originally served static html, the php code wasn’t actually as vanilla as described, and the bitcoin key wasn’t actually there).
I’d have hoped this kind of clear vindication on the first point might have caused folks to revisit their stance on whether to trust the expert stance on the second. But maybe I’ve been overly optimistic.
https://calif.io/php2shell/#patch-the-planet
I mean what is the world coming to when security researchers cannot release a writeup that is designed to look like slop, and starts with a bunch of cartoons with lame cyberpunk and matrix references, without being ridiculed for taking the piss ...
1. First I hear about it is a heads-up at 5:00 am 21st.
2. Available info then is pretty much, "omg, it's the end of the internet".
3. There are no specifics available on exploitable configurations.
4. Updates are not expected to be available for at least two more hours, so people start deciding to do the Madagascar "shut down everything" meme.
5. Cloudflare says they're seeing exploits in the wild, well, that's not great.
6. I shut down everything, including a national brand, because wtf else am I supposed to do at this point?
7. Updates become available at 0645. Fortunately, I don't run my entire infra on Docker, so I'm immediately deploying the updates to all configurations and bringing sites back online approximately in order of traffic volume.
8. Still no specifics on the exploit.
9. A million vibe-coded PoCs appear on GitHub ... and none of them work.
10. It's late morning local time on the 21st and I'm still bringing things back online, having taken the day off from my regular job.
11. Conversation starts to shift towards, "...oh, did we over-react? How exploitable is this exactly?"
12. Still no specifics available.
13. Somebody on the internet gets as fed up as I am with the whole chaos vortex of idiocy and stands up a site saying, "okay, here's some money if you can exploit it."
14. Hours pass.
15. Still no specifics available.
16. Zeitgeist becomes, "I guess it's not exploitable after all."
17. The test site gets 'sploited.
18. Finally somebody actually posts the damn specifics -- namely, the person that grabbed the $2k.
19. Late morning local time on the 26th, and the conversation becomes, "well, obviously this was exploitable!" <-- we are here
Coincidentally, I just started reading Crisis Engineering, which seems like an excellent and applicable book, but I'm not sure who to beat with it.
There's not a chance in hell that even half of the world's PHP has been updated, so I would expect that if we start seeing large-scale exploitation, those people will change their opinion pretty fast.
Being totally burned out on AI hype myself, I'm somewhat sympathetic towards the folks that are still thinking of this as just another example of that.
I mean, it was also that it was marketed in the media as a security apocalypse and unpatched servers would be falling within 15 minutes after the patch got released. This didn't happen. And that definitely warranted skepticism. There's been MUCH more severe vulnerabilities in the past that just went by without OpenAI's marketing making everyone go crazy about it.
Also, almost all information about it was dressed up in slop. Because OpenAI didn't want us to forget that AI was involved, somehow.
you keep repeating this, also when people make very valid other criticisms, such as the hype causing government websites to be pre-emptively shut down -- do you believe this was warranted?
because that is the criticism.
nobody, including that "PHP vuln isn't so bad" blog article, which was VERY clear about this, said you shouldn't patch your servers
what's worrying is that you keep making up straw men, but why?
this isn't about the vulnerability, it's about OpenAI's Patch The Planet hype train
AI company tells you their AI was used to find the biggest vulnerability EVER, with much fanfare. Zero cases of exploitation in the wild. Zero publicly demonstrated PoCs. It would almost be weirder to not be skeptical at that point unless you for some reason trusted everything a marketing department says implicitly.
> These findings rank among the most severe vulnerabilities discovered in PHP, and arguably in software history.
See also the parable "Boy Who Cried Wolf" for more insight into the human condition.
We could have skipped from 7 to 19 if folks had just taken seriously the guidance from experts in the field.
many common nginx setups and hardening suggestions would make it very difficult to exploit. as well as any sort of distributed architecture that doesn't pin requests to clients.
there could be other undiscovered paths to exploit this vulnerability though. the PoC here uses the disclosed path for exploiting on patch day, minus mod_php.
In retrospect, I should have just given it a /goal and let it run overnight.
"The winning chain deliberately used per-request memory exhaustion, which appears to violate the literal no-resource-exhaustion rule, although the organizer accepted the win."
echo 'PID: ' . getmypid();