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.

• weird-eye-issue

  today at 4:52 AM

  That's interesting because there were people complaining yesterday that this was a fully static website with no PHP involved lol

  • nodja

    today at 5:51 AM

    It was https://x.com/LiveOverflow/status/2114412072805208237

    Nitter mirror: https://nitter.netbub.com/LiveOverflow/status/21144120728052...

  • unsnap_biceps

    today at 5:24 AM

    https://news.ycombinator.com/item?id=50234254

        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.

• decidu0us9034

  today at 5:45 AM

  HITCON CTF has a realistic php2shell challenge. Think it has ended up with 0 solves so far, not sure.

  • rockdoe

    today at 8:44 AM

    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 really fooling. Is this some AI denial?

  • ffaccount2

    today at 8:21 AM

    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.

• tonymet

  today at 4:19 AM

  are you saying this lead to dos (and less competition)? or easier penetration?

  At first glance, this wouldn't affect demonstration of the vuln.

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.)

• rockdoe

  today at 8:40 AM

  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.

• Sir68k

  today at 7:53 AM

  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.

• kennywinker

  today at 8:19 AM

  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.

This is already linked by it's author in the Steal My Bitcoin thread (585 points, 458 comments) https://news.ycombinator.com/item?id=50224916

between the challenge being updated to actually run php and this only like 2-3 hours passed

• cluckindan

  today at 7:20 AM

  [flagged]

Does php2shell works with PHP-fpm nginx? I can’t truly replicate that poc locally.

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.

• today at 7:58 AM

• niallmurphy-ie

  today at 6:09 AM

  The initial server setup wasn't realistic and it wasn't exploitable apparently.

• stackghost

  today at 4:16 AM

  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

    today at 6:44 AM

    > 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

Related: https://x.com/JamesPavur/status/2114501212313653696

Apparently the wallet key wasn't on the server, like some in the original thread suspected, but perhaps not due to maliciousness after all.

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.

This was good wholesome fun! Some foundation should do this for future cve's