PHP2Shell discussion
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.
The PHP foundation has a lot to say about how this all went down, including the period of discovery, fixing, and the leak: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-ho... The leaking happened in stages Tuesday. Three most notable moments: * first folks were just saying that high severity PHP flaw was coming down the pipe, the CVE identifiers were blogged, scores (correct and wrong) were given * around 2:30pm Winnipeg time the PHP foundation made a pre-annoucement and moved up their release time to Wednesday morning (Winnipeg time) * around 3pm Winnipeg time the security firm Calif which had a key role in the discovery published their video on X "mistakenly". They pulled it down but the internet does not forget and started re-posting. (by evening even I was using a Google Drive link to re-post it). This can now be found embedded in their post https://calif.io/php2shell/ . Was pretty weird with all the dancing anime and blur effects going on, folks could have easily gone down the rabbit hole of asking if it was real... though by that point the PHP foundation had already told folks the sky was falling. Charitable explanation is that they felt there was enough out there already that they could start bragging and then realized they were saying too much (more details than PHP Foundation) and so they yanked the post. I've gone into less charitable, speculative explanations elsewhere, though none of them involve money... On balance, I'm more grateful for the work the Calif folks did in the responsible research and disclosure pipeline which took months of work than upset by their incremental indiscretion in the final day. It seems there were a lot of pretty tight lips until the nearly the end of the runway. This vulnerability was just a little too big to have a perfect embargo, way too many "critical" people had to be given advance notice and so way too many people were in the know prior to Tuesday. Mark Jenkins
On 2026-10-22 Mark Jenkins via Roundtable wrote:
rabbit hole of asking if it was real... though by that point the PHP foundation had already told folks the sky was falling.
Ya, I've been finding out more, and it might be even worse than first thought. Early reports are look for OOM errors in your logs, maybe weird session stuff too. I saw both on one of my (big) boxes, at 2pm. Other logs & fs look clean. It looks like nothing happened. But surely the box was probed. Now it turns out there are exploit patterns that are possibly trivial to do with PoC code everywhere that use the new 8.4 upload_progress* feature... that the geniuses at php decided to make on by default, so everyone's 8.3 php.ini instantly grants access to this bug. And these patterns do not leave any 500 or OOM or weird error footprints! Nothing! Just crazy wild unlimited execution of whatever you want (as the php user) with no trace anywhere. If we had execve audit on (we don't because it's like 1000 every second much of the day) maybe we could see something and know for sure. But we didn't. Thinking about it now... but then you need to have it feed offsite or the good hackers will just edit/delete the audit log after 5 mins of being in the system. And worst of all... the attackers could just use php instructions instead of exec'ing shell... and if they do that, no audit except for syscall audit will catch it either! And that I know for a fact my system cannot handle (100k a second?). And since php has full-featured file function, and remote protocol stream functions, one could copy every readable file out to a remote IP without any execve trace anywhere! Ouch. The better question now is why a new feature that no one will use until they learn about, and when they learn about it can easily enable it, would be turned on by default. I'll probably never use that feature. First fail. (Ya, it's only half the CVE's problems, but still...) The second is how come the programming is getting so shoddy at PHP? They're so busy *forcing* everyone to be typed, and changing after 25 years what-equals-what, that maybe they've lost the main plot. I hope someone over there is admitting they royally messed up. It's ironic that a feature meant to add to security (hit memory usage limiting) turned out to be the security hole. And something is majorly wrong with Fedora's sec push infrastructure because RH9, AL9, Deb13, and F44 got fixes immediately in the afternoon, but F43 is **still** crickets. It's stuck in koji limbo even though it says "passed". You have to run a funky dnf --advisory=FEDORA-2026-d5f8446449 to get it. Yes, F43 is fully within its support window (less than a year old). Crazy.
participants (2)
-
Mark Jenkins -
Trevor Cordes