No working exploit exists for the PHP vulnerability everyone is panicking about
There isn't an easy exploit for this PHP vulnerability
A PHP core team member called the bug cataclysmic, and GitHub now hosts thousands of PoCs for it. But none of them work against a vanilla PHP instance. Most rely on a local-file-inclusion prerequisite that already lets an attacker read /etc/passwd, and many were generated by LLMs that quietly patched the test server to make the exploit succeed. Ten hours in, with the whole industry looking, there is still no real exploit chain.
One really amusing thing in common with most of these "PoC"s is that they lean on "LFI", or local-file-inclusion, to make the vulnerability.
- nallerooth
This is such a strange claim from someone trying to sound knowledgable in the field of cyber security (maybe they are, I have no idea who this person is). Even if the exploit would be difficult to use properly, it's not like there's a lack of groups out there trying.
Anyone serious about this would consider the fact that a working PoC was reported to the PHP security team. They confirmed the vulnerability and started making a lot of noise about the severity of it, by reporting 2 CVEs and pushing the patch to Linux distros ahead of the official patch release.
Trying to understand what the message of the post is all about, I flipped the whole thing around in my head - and the message is basically "you don't need to upgrade your servers". Which is something someone with a working exploit would say. Or it's just noise on the Internet.
- hn773746483
Social media and "cybersecurity experts" had a big role in this. Stuff like "EU SAYS THIS IS A URGENT VULNERABILITY" and even the Prime Minister of Japan doing a nighttime PSA. They cite "the experts" posts on social media about the initial advisory, while the very same so-called experts share google search AI output mitigation strategies. None of these organizations or bodies had any details other than what was on the advisories and social media. (e.g "CVSS 10, that's bad!!")
To me, it seems more more akin to broadpwn, technically severe, wide scope (millions of iphones), yet will never be a one-size-fits-all-PWN-button.
Even in the age of AI, I don't think this is going to be weaponized down the line like how Eternalblue was... but I'm not the social media cybersec guy with 15000 followers, so don't take my words at face value ;)
- apexalpha
This was absolutely exploitable. The fact 1000 not-working PoCs exist does not invalidate the one that does.
Sure maybe not on a vanilla install but most people don't install Php, they use a pre-made container or a platform using Php under the hood.
Yesterday I simply wasn't confident in the security anymore and the data in my database is important enough to go offline for a few hours.
- tibbar
Two things can be true: it's a real, exploitable CVE 10, and it's hard enough to construct that you need a good harness + verification process to keep your LLM from cheating. So, the exploit may not be easy to construct, but it doesn't actually require the artificial settings that the OP implied.
> What we demonstrated
> Pre-authentication RCE on WordPress, Drupal and Joomla
- nemothekid
For me, what was strange is there were no write-ups on how the vulnerability actually worked. It really does feel like a lot of people went "Claude found a bug, and Claude says it's dangerous" but no one actually verified how exploitable it actually is? Not to say its worth ignoring, but compared to Heartbleed (where exploits had to be written by hand) there are a lot fewer active PoCs.
- kgeist
I ran 2 PoCs from GitHub today: one indeed expected Local File Inclusion (LFI) to already be present (so it's just LFI with extra steps), and the other one didn't work at all out of the box without some modifications (although I used the same Docker images and all). The second PoC did trigger a real stale write bug in the end, but it didn't demonstrate actual RCE; it just triggered a stale write. And then I wondered, is this the first time ever that the PHP runtime has had a memory corruption bug? I doubt it (I remember a few years ago we had random crashes in production under high load due to an opcache bug). And if it's not the first memory corruption bug in the PHP runtime, why is it being proclaimed the worst vulnerability in years?
- nickysielicki
Docker images from Wordpress, joomla, and drupal were all exploitable.
- rectang
According to "Today's PHP Security Release, and How We're Strengthening PHP Security" discussed at https://news.ycombinator.com/item?id=50182987
* Regarding one CVE, "Remote code execution was also confirmed on PHP-FPM through application-level code paths."
* Regarding the other CVE, "A use-after-free and worker crash were confirmed, and the reporter demonstrated remote code execution against a real-world application running on Apache with mod_php."
Since those exploits exist, I expect that LLMs will duplicate them soon.
- easterncalculus
Related LiveOverflow video about fake exploits going around https://www.youtube.com/watch?v=7CiZmq2llDg
That said, OP is basically full of shit. This is absolutely exploitable and people are going to just assume the platform and ABI and spray it against the internet, particularly hoping for mod_php.
- 0x1F8B
If they're so confident this isn't exploitable this person should stand up a very basic nginx running php-fpm server running in an exploitable version of PHP and invite people to exploit it.