So you may have heard about the new PHP2Shell PHP vulnerability already, or seen outages of web sites. As a guy who looks after maybe a dozen boxes with php this isn't a fun thing to wake up to. Strangely, Fedora 44 got an update pretty fast (though mirrors can take hours to days to get the file!), I don't see one for F43 yet (I'm on all the mailing lists, so I'll know when it's pushed). Not sure what Fedora is thinking. 43 is under full support still. RH9 / AL9 got the update immediately, as it appears Deb 13. I'm looking to pool ideas on hack detection. There's not much on the web/AI about that yet. Right now I'm looking for odd code-500 HTTP response codes, especially on POSTs. As well as memory-exhausted errors in the php log files. So far maybe 1 box seems to have been targeted, of course the "biggest" one I work on. I'm now doing rpm -Va type checks. As for damage, it may turn out better that all I run is php-fpm, not mod-php. Maybe. It might be harder to jig the hack to hit through the cgi interfaces. Maybe. And one thing no one mentions is all the hacker can do is get shell-type access as the same user as your php-fpm process. For me that's "php-fpm". Still bad as they could steal all the php source code, db passwords, etc; and possibly use that to then dump & steal all the db data. That would NOT be good for any company. They could also replace php source code with hacker stuff to have a backdoor for later. This is where git integrity checks can be really handy! However, it's not root, so that's good. They'd have to combine it with a root escalation, and if your server is kept updated they'd need a fresh zero-day for that. Please, anyone else working on this issue, add in more ideas for hack detection and fingerprints. The sparse info out there right now makes it sound like you can't even count on an "out of memory" error in the log. Ironically, even running/enforced selinux or apparmor wouldn't help at all here, except for maybe keeping them from steal /etc/passwd (which has no passwords...), and of course stopping them from trying to priv escalate. Also, apparently they've known of the hack for a while -- at least more than the few hours it took them to rush out the fixes. They chose to sit on it until someone leaked the hack? Also, wouldn't that indicate a mole inside the php dev sphere who leaked, probably for $$? None of this is good.