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.
lemmyvore@feddit.nl 17 minutes ago
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”.