So, were any big sites popped by the PHP2Shell vulnerability?
Looks like my hosting provider upgraded overnight without issue. Yet I was firmly told that unless patches were made in the first 15 minutes a Botnet army would compromise everything.
1 Boost
0 Likes
@Edent can someone please explain (or point to an explanation) of why 4 is so significant? I've seen loads of knowing jokes about it which seem to imply that PHP designers did something very silly involving the number 4, but I must have missed the OP that explains what this silly thing it. So I'm seeing loads of punchlines and not getting the joke!
4 is actually a completely unrelated security disaster, that got kind of snowed under by the PHP thing: https://en.wikipedia.org/wiki/EMudhra#2026_intermediate_certificate_compromise
@Edent it's just like some people consider old Windows versions radioactively unusable the day after they're declared EOL by Microsoft.
I have PHP 5.4 running on one of my servers. Can't really update it because it also runs old Debian and because I'm not rewriting my old scripts that use the older mysql_* functions which were removed in favor of the new "mysqli" API in later versions. So I changed php.ini settings as recommended and *hopefully* that's it.
@grishka @Edent Having been a serious AI skeptic in the early days, one of the key things that won me round was discovering how Claude Code was really good at tedious things like version updates! It's much better at reading changelogs than I am, and then looking at a codebase and identifying any things you might have to fix when going from version X.Y to Z.W of a given platform. Long before I used it to write any new code, I was using it for this. (1/2)
@Edent I was managing this process at my work yesterday across several hundred PHP sites and we put WAF rules in place very early - attempts at attacks started *before* the patches were available based on the AI-generated PoCs that came out during the day/night before.
I think news sites and governments pushing the 'take your sites down' line actually helped.
edit: also I don't think a lot of the wave of attempts actually were functional exploits :)
@Edent I do also think that it's a bit harder to exploit than it could have been - my understanding is that you had to hit the same PHP worker with at least two requests in order to successfully attack it, and that's harder than it sounds on a site of any scale.
We have multiple containers backing each of our sites (and there's no LB session stickiness), and each container runs many workers, so the chance of getting the same worker before it recycles is relatively low?
This seems like a good explainer of the issue.
https://eliastaylor.com/noexploit/
There isn't an easy exploit for this PHP vulnerability