I know, I know. It's all you're hearing about. That, and the number
4.Don't get me wrong, there's clearly a bug here and it really does matter. But this is not easy to exploit. It is certainly nowhere near as eay as Log4Shell/Heartbleed/RoRYaml etc.
EDIT: Putting this up here so people read it. You should patch your servers anyway. There is a real vulnerability here, but exploiting it is significantly harder than people are making it out to be - it is certainly not as easy as e.g. log4shell.
Justify yourself, you lunatic!
I don't think this PHP vulnerability is that exploitable. I think that 5 years ago people would've understood this, but now people are being deluded by their LLMs telling them they have an exploit when they don't.
If you take a look at github right now, there are thousands, literally thousands, of "PoC" exploits for this vulnerability. One thing you'll notice about all of them though, is that they do not work against a vanilla PHP instance.
Go ahead, stand up a php server you think is vulnerable in Docker and then run the PoC yourself. Don't get your LLM to do it. No. Run the script, yourself. The exploits don't work.
...
This matches my experience; I tried some of the PoCs and couldn't get them to work without some pre-engineering.
Obviously, I applied/checked mitigations on all of my servers, and then patched them when the patch was available. The severity of this exploit, if usable, is very significant. But it's nowhere near as easy nor as universal as it was advertised as being.
Elias compares the PHP CVE to several other "bad" ones, but the thing that it most reminded me of, in terms of its potential damage, was Code Red (that's going back a way!). That's the kind of "scale" of damage it could have caused, but multiplied up by 25 years of Internet growth. But in reality... of course it could never have been that bad, because... it's just not a case of some universal clever payload.
It's serious, and you should have already patched for it. But this is not how the world ends.
0 comments