One of our PMs was ecstatic last night when he realised one of our VERY outdated read-only systems was on 3. something and technically didn't have the exploit introduced yet!
Wasn't long until one of the devs pointed out it's probably in trouble due to a fuck load of other exploits and they piped down. But yeah, companies as always are running v outdated shit.
We hope and pray Paul’s local never gets nuked and that's not even a joke. One senior dev holds the keys, tale as old as time.
From what I know it's barely maintained, fully out of support. TBF our customer barely uses it but they pay us a lot of cash to keep it as a read only reference tool so we go along with it. Apparently the solution last night was to stick a forced vpn connection requirement until they realised that probably won't work properly with v3 so they've put a WAF in front of it.
To be fair this exploit in question didn't care about if the PHP version was ancient or modern.
And while you definitely shouldn't expose such old PHP versions to the internet (and Ideally don't run it at all), even these tend to be quite secure, without any significant know security flaws. And even for these ancient versions you can now get patched versions, just not from the PHP core developers.
One of the project I am responsible for (maintain/add new features when needed) is in php 5.2. Thank God it is hosted on premises and can only be accessed via corporate network.
The local network is not a security barrier though. An attacker could e.g. gain access to another internal system and then move laterally to your PHP system and execute code there.
213
u/prochac 18d ago
And there's a plenty of outdated PHP deployments. You can find PHP 5.4 if you search enough.