lobsters score: 11 · tags: php, security
One thing I’ve been thinking about a lot over the years is how much context we throw away when we describe something as easy or hard without qualification. In a way, there’s no such thing as “easy” or “hard”, only “easy to (use/understand/do the basics/master)” or “easy for (someone with certain qualities)”. We just leave out or ignore those details, and hope people get the gist of what we’re saying. Most of the time it’s good enough, but often it causes confusion.
I do appreciate the observation that LLMs will accelerate the flood of bad POCs and misinformation after each vulnerability is announced.
However, It seems like this post conflates how easy it is to write an exploit from scratch with how easy it is for someone to use the exploit once they’ve developed it.
Imagine an exploit that requires a very clever person to spend two days developing it, but then is usable against any PHP server with little to no modification. We really wouldn’t be reassured that it took two days to develop the first exploit.
I don’t think this post gives any real evidence about exploitability. It just shows that many people have failed to develop an exploit. But we care about the ones who’ve succeeded.
score 3 · canonical
Either way, the upside is that organizations are starting to take security more seriously and actually patching and taking servers offline until there is a patch. I think that’s a good thing. Of course the risk is that eventually it causes CVE fatigue and possibly a backlash where admins are throwing their hands up saying there’s nothing to be done anyway.
score 1 · canonical
A former PHP developer says they’ve looked at the patch and are worried that it’s going to be gappy—not because of a specific gap, but just because the approach requires finding a huge number of potential failures. https://social.noyu.me/@hikari/statuses/01M5FKSAZR531Y1PG1HHBCJ4YJ
score 1 · canonical
It’s wild to me that this is the fix. Why take the risk of having to find all those call sites just to keep the longjmp OOM handling working? Surely you’d just get rid of that longjmp and abort on OOM.
score 1 · canonical
Disclaimer: I don’t understand the timelines and/or the CVS disclosure process at all
It looks like this became widespread knowledge before PHP was actually able to ship a patch/fix.
Should something of this magnitude not be fed to the PHP security team first so a security release can coincide with the announcement to the wider public? Or was info just get leaked?
score 1 · canonical
For those wondering how the coordinated disclosure of php2shell broke down in the last few days:
Timeline:
- Some incorrect, non-technical details leaked about the CVEs, so
- PHP moved up the announcement a day, then
- One of the bug finders, Calif, mistakenly published their PoC video, then deleted it, but
- The video gave just enough hints to LLMs to lead to new exploit attempts, though PHP sec team claimed they weren’t functional
- Finally, Chainguard provided new images with the fix 6 hours early, letting attackers study it while others were scrambling.
TBH, given the sheer scale, I don’t see any realistic scenarios where 70% of the world’s websites are updated before a single bad guy with an LLM makes an exploit. Responsible disclosure broke down, but I’m not sure how much difference a few hours would make to the long tail of vulnerable sites.
score 1 · canonical
TBH, given the sheer scale, I don’t see any realistic scenarios where 70% of the world’s websites are updated before a single bad guy with an LLM makes an exploit. Responsible disclosure broke down, but I’m not sure how much difference a few hours would make to the long tail of vulnerable sites.
That’s a good point. While I think Calif and Chainguard behaved badly (whether deliberate or not) it’s probably time to reconsider the value of “coordinated disclosure” at all, at least when the group of stakeholders is this large…
score 1 · canonical
Apologies if this should’ve been folded into the existing thread, but I felt that much of that is already bloated with speculation and such already, whereas this post has the actual technical details behind the CVEs.
score 3 · canonical
https://lobste.rs/c/dkmxpk could you add this too? it has a lot of the background from a release perspective which is worth showing i feel
score 1 · canonical
The PHP project page now has links to updated versions
https://www.php.net/archive/2026.php#2026-10-21-5
Security advisory: Critical remote code execution vulnerabilities, update now
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.
The vulnerabilities:
- RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
- RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
score 1 · canonical
Debian has a non-listed php update 8.4.27-1~deb13u1 from the security updates, but the CVEs themselves can’t be found in the issue tracker, so no idea whether it’s truly done or not.
score 2 · canonical
PHP 8.4.27 includes the fix for these CVEs, yes. (Speaking as PHP 8.4 RM, I just don’t have a hat for that.)
score 5 · canonical
As a corollary, the patches are now out and CVEs have been issued: https://www.php.net/archive/2026.php#2026-10-21-5
Released twenty minutes early, no less.
score 2 · canonical
brittle foundations. Ran into an unrelated example ten years ago https://blog.mro.name/2015/03/why-php-is-utterly-broken/
score 1 · canonical
Multiple large sites in the Netherlands taken offline, including the national e-ID system:
score 2 · canonical
The time to be deploying PHP applications in production is long over. At this point it should be considered malpractice.
score 1 · canonical
If anything, this vulnerability was more of a C one than a PHP one. As in, the problem was in the implementation of PHP itself, which is written in C. Of course, there are also tons of bugs in PHP code too, including your garden variety Wordpress CVEs. This is not that.
This one is very characteristic of C vulnerabilities: Because of C’s lack of memory safety, it’s very hard to prevent memory corruption bugs. The conditions required to trigger these can be arbitrarily complex, making them hard to find (this one was hidden in plain sight for 20 years). They usually result in the most severe consequences, often remote code execution (as in this case). And because of C’s foundational role in the ecosystem, the affected components tend to be deep down in the stack and used very, very widely.
Sure, you could respond that it’s not C’s problem, it’s just that the PHP developers (who are bad, because PHP is bad, unlike us, who are good) are just also bad at C. That might hold some water if nearly every other important C project wasn’t also running into these issues.
score 1 · canonical
this one was hidden in plain sight for 20 years
not precisely that one but the problem has been known for over 6 years. https://bugs.php.net/bug.php?id=78876 https://gist.github.com/cmb69/384d5f5bb6b2de834877348dcdbe3282
score 1 · canonical
WTF so if we find a similar bug in ruby then we ditch ruby, same for JS ?
I hope you never used or intend to use moodle, nextcloud, wikipedia, a forum, mailcow, mailchimp…
score 3 · canonical
PHP has a horrible security track record. This particular bug isn’t the reason to claim that, rather its history should be.
score 2 · canonical
Note that there’s apparent misinfo out there talking about a config change which allegedly makes this not exploitable. This is false according to Gina Banyard (PHP core developer): https://phpc.social/@Girgias/117476477429221001
The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.
score 1 · canonical
7:30 AM UTC, and it looks like it’s been independently discovered/leaked some time ago (at least several hours). Holding the release for coordinated disclosure doesn’t seem to have worked at all.
Haven’t seen a thorough explanation of the bug.
score 1 · canonical
No, a bug has been independently discovered. We don’t know if it’s the same bug. If it is, the people who discovered it don’t understand it completely. PHP core developers are saying that the proposed config change (
session.upload_progress.enabled = Off) doesn’t resolve the issue and the only fix is to upgrade.Going around on social media and claiming that it’s the same bug as what will be receiving a patch today is dangerous and leaves people with a false sense of security. From what I can tell, the only workaround before you can patch your systems is to turn off PHP.
score 1 · canonical
Ignoring the fact that this post is just terrible prose for a second, it’s also wrong. It might be talking about a real bug, but the proposed config change doesn’t fix the RCE that’s being patched today.
In short, it’s AI generated misinfo.
score 1 · canonical
every line reference in the original writeup
Ouch, it’s uncanny to see an AI-generated exploit page with an AI-generated write-up.
score 1 · canonical
See comment above: https://lobste.rs/c/qqk3t0
Everything is moving too fast. Time to batten down the hatches, have a pint, and wait for it all to blow over.
score 2 · canonical
I wonder if this is because someone was using LLMs to verify or originally discover the bug. In a talk by Greg KH I recently watched, he says LLMs demonstrably leak data to others, so projects can get hit with so-called “independently discovered” vulnerabilities in a short amount of time.
score 1 · canonical
If you have a PHP site with anything sensitive, you should probably turn it off until you’ve installed tomorrow’s patch. Last month another project that quietly opened a PR with a patch saw exploit attempts less than 10 minutes after becoming public. With this level of severity and popularity, I would expect the PHP vulnerabilities will be re-discovered and put to use overnight.
score 6 · canonical
As a side note, this is a great time to learn which sites are running PHP on the backend, if you didn’t already know their stack. I work at DeviantArt, and we’ve been serving a “down for maintenance” page all morning.
score 10 · canonical
There is already a POC that can compromise Wordpress going around. Assume threat actors are already exploiting this. Coordinated disclosure was handled incredibly badly.
score 1 · canonical
deleted by creator