I came across the link via https://mastodon.social/@CuratedHackerNews/117481600704689796
Last time I touched php it was ~20 years ago and maybe for a month. Could someone with actual php understanding weigh in?
Somehow, somewhere between the lines, my understanding was that there have been observances of the vuln being used in the wild before the 14 UTC. And that wasn’t from reading news sites
The bug is real, its exploitable but only if the server also has a very specific vulnerability in order for php to be exploited. Which kind of makes it a non exploit. And the author is backing that up by point out the php runs about 70% of the web and the exploit has been out for over 10 hours (when this was written), if this was a real “we are very fucked” bug, we would be hearing about all the fall out from this already and we have heard nothing.
The (quite funny actually) take away here is that the “smoking gun” demos that prove this exploit show that the server vulnerability was specifically mimicked before the exploit test was run.
According to the PHP Foundation the OOM vulnerability was originally found by the security audit they commissioned back in 2024.
They never fixed it because there was no working exploit at the time and also because all the fixes had important downsides and they went into decision paralysis.
I do believe that two years is plenty of time for someone to figure out a working exploit, especially with AI assists.
Bottom line, the timing of this recent debacle is centered around the moment that the PHP Foundation decided to finally eat crow, not around when the exploit was actually available. The embargo was just for spectacle. PHP circles are already spinning it as “see how important PHP is, how much of the internet runs on it, how it’s critical infrastructure”.
To be perfectly fair, we’ve come a long, long way from 20-30 years ago when most firewalls were static or at best heuristic.
Today you can integrate solutions like CrowdSec into your reverse proxy setup (which, let’s be fair, most people hosting things will be using to some extent), and transparently scans all requests for known exploit fingerprints.
Basically, if you’ve done the bare minimum of opsec, most likely your setup will be safe from being compromised, even if you’re running an exploitable version of the problem software/stack.
And that’s just a free and open source solution to securing your hosting - you can further deploy DPI based IDPs, analytics that spots irregular traffic patterns, especially in commercial environments, to protect against such attacks. It’s not a guarantee, but such layered security at the very least adds some deterrence.
This is dangerous misinformation. Both PHP bugs are real and together they are exploitable without the server having some other rare problem.
Thank you for coming my nerves, I have been seeing a lot of things on this some sensationalizing this as a big issue and some saying it was not really a big deal. I broke and went to see what of my homelab that really touched the WAN had php, I removed somethings and decided to risk it for someother things.