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
From the very little I’ve researched, a DoS with it isn’t hard but for RCE one needs to know some pointers inside… doable if you assume it’s Debian or something then just download a bunch of versions locally and try them.
I remember someone on hacker news saying they were able to dump the whole database from their server, I cannot know if that s true but I don’t think everybody panicked for nothing
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.
the exploit has been out for over 10 hours
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.
The PHP vulnerabilities (yes there is more than one) are relatively easy to exploit if you can fiddle with what requests your server receives (easy).
The DNS exploit requires someone to figure out how to man-in-the-middle your connection. While that is trivial for governments, it is much less likely to be done by purely bad actors, simply for how hard “internet” integration is and how visible the problem ends up.
Both are big problems, but only one of them is continually exploitable, as the DNS issues have been largely resolved even before the very public disclosure.
What do you mean “DNS exploit”? Neither 109618 nor 109619 mention dns in the exploit path…
The eMudhra CA certificate breach.
What does that have to do with the PHP vulns?
