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.