I feel like all "non-inner-circle people" here are taken for a laugh. OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix, and then leave the rest out to dry while they failed to properly contain it.
The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details. Specifically once the POC came online. Would have been significantly more useful than these polished blogs.
Perhaps I'm missing something here, but the costs (dev/sre time, missed sales, potential data leaks and hacks) of the way that this was handled is significant.
>OpenAI and these security companies sat on this for 2 months
these security companies reported it 2 months ago. it took a month for the php security team to acknowledge it and another month for the php team to develop & release the patch.
if you're going to be upset at anyone it should not be the reporters.
>The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details.
publishing the fix = publishing the security details.
This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails they get.
If I had details on a RCE like this I'd report it but if I got no response for a WEEK I'd be trying other venues.
I imagine more details will come out over the coming days, but it’s not uncommon for severity to be under-estimated in the beginning; and then “oh shit” as you dig deeper.
We don’t know when it went from a “memory safety issue” to “php2shell/RCE”.
Calif’s report is a little light on timelines, but reading between the lines, it seems they took a while to turn this into an actually exploitable vulnerability.
Finally, at least pre-LLM (and maybe a bit outdated now), responsible security disclosure norms is that you usually do wait for vendor (up to 90d) if there’s no signs of active exploitation. Even if it’s a RCE. Actually, especially if it’s a RCE.
The last thing you wanna do is go pinging random non-security PHP contributors or maintainers and have it leak with zero patch. That is truly the worst outcome.
Yes, this is bad, but also, it’s apparently been bad for decades; and it could’ve been much worse.
According to this post, one of the researchers was a former PHP security lead who already knew about the bug since 2004. So I'd assume they would be taken as credible by the current team https://calif.io/php2shell/
As I mention elsewhere (https://bugs.php.net/bug.php?id=78876) I'm very confused. Looking at the PHP bug tracker the specific bugs were fixed. So my best guess is that the LLM was able to find alternative variants that still worked? But then the report makes less sense.
Assuming that it could have been spotted in their inbox, amongst a probable flooded of LLM slop like a number of security mailing lists for open source projects that I know of. We've all seen the impact on open source github issues, hackerone etc. The same is happening to standard email disclosure paths.
>This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails
i highly doubt it. these are pretty big names in the security sector who have plenty of experience reporting high severity vulns.
If you provide forewarning, system administrators around the world in various time zones can get ready to update at the same hour the fix is released, which is very important. Being hours late is not acceptable for a vulnerability like this.
I think its unreasonable to expect reporters to do anything other than report the bug. Its not their software.
General industry practise (or at least google) is to wait 90 days of being ignored before trying something else. And google got hugely criticized in the beginning for only waiting 90 days. You are suggesting this person should only wait a week before going full disclosure? They would be crucified if they did that.
>if you're going to be upset at anyone it should not be the reporters.
Everyone is just upset by AI. So they want to blame the side that was involved with AI. It's like how cops automatically assume black people are criminals.
And that's not a bad thing. If it was, the the logical conclusion would be to never publish the fix and don't preemptively patch before active exploitation.
Say I release a fix. I'm some rando but I go out to the world and say I fixed an issue with php. Use my version instead! Not telling you what I fixed, it's a secret, just trust me.
It will take, with LLM help, attackers a couple hours, tops, to reverse engineer my fix into active exploitation. Meanwhile, I'm some rando so no one's even heard of me, people who do hear don't automatically trust me to install my fix, so very few people have my fix. Meanwhile, the exploit is out there thanks to me and people are getting their sites hacked thanks to me.
How is what you are describing any different than what happened today? Except the vulnerabilities were also explained. You can say that sites are getting hacked right now due to them releasing the security update.
>I'm some rando so no one's even heard of me
Why do think people need to have heard of you. If you are reporting this issue directly to distro maintainers, security companies, hosting companies, etc first you can help use their names as part of the marketing push to raise awareness.
2 months ago there was no patch and no possibility of a very quick patch. Releasing details then would have been very bad.
If you mean they should have released the patch as soon as it was done, it's true that it would have been before the bug was public... for about five minutes. When a warning a day or two before patch release works, it lets admins prepare to patch immediately and/or shut down their servers before the release time.
Even with the leak, admins still had warning and it was better than an unwarned official patch drop. Which itself is better than an unwarned unofficial patch drop. Which itself is better than an unwarned drop of exploit details.
We are talking about a hypothetical where a patch is made <2 months. With AI agents, I can 100% assure you it would take a max of a few days to pat CB and test a mitigation. Not months.
If you are warning people to turn off their servers. You might as well give them a patch at the same time.
1. The time it took to develop the patch doesn't matter. Nobody leaked anything during that period. It just needed to not be a huge length of time.
2. The time between the warning and the patch release is overall a good thing. In this case the secrecy failed halfway through and we only got a fraction of the benefit, but it was still better than "surprise and good luck with the imminent exploits, hope you weren't asleep!". If the secrecy hadn't failed it would have been much better.
3. There needs to be an official patch before releasing the details. Some random untrusted person publishing a patch has all the downsides of releasing the exploit but people can't safely install it fast.
You're confusing PHP the product with PHP the codebase. The former is what is the only relevant part in the security world, where a product is synonymous with its vendor (even FOSS).
The PHP maintainers have generated a certain amount of goodwill over their long service, which leads downstream consumers to trust their releases over every other packaging of "PHP the open source codebase".
Nonetheless, there are countless forks of that codebase, and there are other releases than the ones made by the PHP maintainers. Any particular downstream could switch to another source of releases if presented with a compelling enough reason.
So if Wiz produced their own patch to PHP, and Calif produced their own (slightly different) patch, and OpenAI produced their own, which version should I use, as a user of PHP? Should I manually merge them? Is Calif's better than Wiz's? Is OpenAI's better than Calif's? Are they complementary?
What's the other choice? OpenAI et al could have developed a patch (for all we know they did) but you need the PHP team's participation to get it out. The alternative would be to fork the project and put up a forked release with the fix, which would have been incredibly disruptive.
I'm glad they didn't do anything disruptive, then. Like wind the world's CIOs up into a frenzy of FUD and bring thousands of servers down in a coordinated panic attack synchronised to the minute.
Imagine if they had just patched the code and rolled it out with an advisory?! Oh my GOD! Won't someone think of Sam Altman and his huge pile of debt?!
Pre AI, silently publishing a fix to a security vulnerability was considered bad practice.
Post AI, Its efficiency pre announcing the exploit to bad actors until the official disclosure.
You can just watch the diff log of every open source project with a small local model, and look for anything that touches buffers, function pointers, or shell integration.
It could be an hour between release of a fix before the exploit starts attacking servers.
Guess what also could happen within an hour? A coordinated Internet wide panic that shuts down all vulnerable servers.
---
We actually have a recent example. OpenAI hack.
An undisclosed vulnerability fix to a image formal lib; packages into debian 12 running in a docker, used by imagemagic, used by discourse running OpenAIs user forum.
To handle the official solution and drive long term changes to reduce similar security bugs from happening again. The current PHP security team does not seem capable to promptly release a fix, so having a community fix first seems preferable.
Mitigating a bug and developing a proper solution that is maintainable long term and supports future changes being made to the software take different amounts of time to develop.
One concern with the current environment is that as soon as a release comes out for such an important open source project, people will immediately point bots at the release to look for changes that might be related to existing security issues. This means that putting out a quick out-of-band release is guaranteed to result in people racing to exploit the problem before many even know there is an update out.
Whether keeping the update quiet and including it in the next normal release, where there are more trees obscuring the wood that is the security concern, and announcing the bug a short time later once anyone using distro updates or otherwise keeping on top of things have updated, would be safer overall than what has happened today is up for debate. I can think of arguments in both directions.
--------
[1] which does have a slight whiff of AI marketing about it - would a human-found issue, without the option of a big AI company to claim some credit, have been handled differently?
This is not a "concern", this is literally what happens. Even prior to AI vulnerability scanning, release notes and diffs for any normal release or security patch of popular software were analysed and used to develop exploits, which could then be applied against non-upgraded instances. Nowadays, AI is doing this en masse and automatically producing exploits. And, as has been demonstrated, nowadays even the rumour of a major security bug is enough for people to find it, as people will immediately burn huge volumes of tokens looking for it.
Nor can you just keep it quiet and smuggle it out in a regular release as you suggest. For one thing, changes in important software are be linked to commits and have pull requests, reviews, etc. Changes without these will immediately raise suspicion, as either a malicious change snuck into a release, or as a "quiet" fix to a major vulnerability, completely undermining the purpose of keeping it quiet in the first place. Moreover, major vulnerability fixes cannot be "quiet", because the whole point is to get as many people as possible to upgrade as quickly as possible. If PHP (or whoever) push out a release containing a major security fix, but don't make this clear, then many people will be in no rush to upgrade, and will get pwned.
> This is not a "concern", this is literally what happens.
Sorry, I should have been specific: the concern is that this will happen faster than even the more fastidious admins (or daily or even hourly automated checks) will spot and apply updates.
> nowadays even the rumour
I think a lot fewer people would have paid attention at all without the rumour. Some ne'er-do-wells might have scanned a larger update for security issues otherwise, but I suspect most of those spending tokens on PHP this week would not have bothered had there just been a standard maintenance release that may or may not have included changes for a security issue that may (but probably not) have been so globally significant.
That is, at least in part, why the question of how to manage the release of updates like this is not a settled debate.
> then many people will be in no rush to upgrade, and will get pwned.
The worst case that we may be heading towards is that for any services on public facing infrastructure we might have to automatically apply updates with little or no time to verify, just to try be ahead of the ne'er-do-wells, with even superficial updates not mentioning the changes until a short time after to avoid giving clues to those who will scan for security issues if any such is mentioned (or nothing is mentioned - saying nothing about a security-only update only works if you say nothing about all updates, and you don't want to hold off on security-only updates on a slow moving project that might not have a non-security patch for quite some time).
It's not possible to publish a security patch for an open source software report without revealing security details anymore (and as of the past couple weeks I would not count on being able to do that for closed source binaries either). The moment you push publish everyone knows previous versions are compromised
You can't do secret releases, people will figure out what you added or changed.
But they could have accelerated the patch release once the embargo was broken and rumors of a PoC started going around. There was no need to wait 12+h today until the release.
Maybe the NSA ‘requested’ some time to use the exploit on some high value targets.
Sure, it’s PHP, but plenty of companies or organisations might have some PHP running somewhere; and once you’re in, lateral movement becomes a lot easier.
The NSA does not need to "request" time to use an n-day vuln. They have more 0-days than you can imagine.
They literally employ full-time Vulnerability Researchers doing nothing but 0-day discovery and PoC creation 24/7 to add to their horde. Plus contracting with the MIC for their full-time VRs for the occasional project.
Exactly. Something like this is often the NSA realizing one of their pet vulns is being exploited in the wild by someone “not them” and so they burn it.
> Over the past two months, we led a coalition of maintainers, researchers, and security providers to address critical vulnerabilities in PHP, an open-source programming language used to run websites and web applications.
And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
If I understood the timeline correctly, there was an announcement made somewhere that an RCE would be announce w/ a patch, and the internet just scanned the entire codebase, they really fumbled this for the sake of having a PR post for OpenAI.
On the other hand, I don't mind AI companies doing this sort of thing, I'm sure a lot of our internet infrastructure could benefit from these sorts of fixes and changes.
> And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
This is a pretty constant theme in the infosec industry. The idea is that you want to do the "responsible" thing and let all the major, multi-billion-dollar companies patch first, so you form a secret club. But then, you share a very juicy, gossip-worthy thing with hundreds of people and ask them to sit on it for weeks. And guess what happens: they don't. Having worked for a big tech company, I've been involved on a couple of processes of this sort, and they all suffered leaks.
And rest assured, we'll learn nothing and try the same thing again next month or next year. Because what's the alternative? If you 0-day everyone, you get more hate mail, not less. It's all of sudden about you, not the vulnerable code. Microsoft or Cloudflare calls you irresponsible when asked for a PR statement, industry bloggers bully you, etc.
Debian has, though only for current stable (updates for oldstable and oldoldstable apparently about to drop) which might imply they had no advanced access to the update so could not pre-test and release immediately upon the coordinated announcement.
Not true. I was able to `aptitude update` and `aptitude full-upgrade` before 10:00 AM EST (9:50 AM) and received the new php8.* packages and upgraded fine.
Still no update for ubuntu 20.04 which has support via ESM, even though the patch is available for php 7.4. There are a lot of people using older servers which still have ESM support.
PHP 8.5.4-0ubuntu1.5 (the fixed version for Ubuntu 26.04) has been downloadable for me via apt from security.ubuntu.com for about 30 minutes. Perhaps check to see that you're not using a different mirror?
This isn't a terribly uncommon method of 'discovery'. In maths and sciences there have been tons of papers that have highlighted something new but were never really connected to anything else and then largely forgotten. Later they are picked up by someone else and connected to a much bigger whole.
The bug you posted was patched and fixed 6 years ago, and none of the other bugs in the audit showcase that issue. Are you sure these are the right links?
So how does the exploit actually work? The best I can find is that they manage to use the corrupted generic decoder state to write a single pointer and associated PHP type information anywhere in memory, then immediately claim "this is RCE". Is that enough? From my (admittedly limited) understanding of such things, after writing code to the target memory you also need to be able to start actually running it. Or do they overwrite the PHP code (which is somewhere in memory) and then let the interpreter do its thing?
But it was withdrawn; now it says that it (CVE-2026-109618) is not an RCE and not even a CVE, apparently an addref call prevents the use-after-free. CVE-2026-109619 is still a memory safe bug, but they have no RCE for that one
One of the most common PHP based applications out there, therefore a good comms channel (via their forums and any mailing lists, both public and for people who have managed instances with them or are otherwise paying for support contracts) to make sure people are aware of the need to update. That would make the company one worth keeping in the loop, if only in one direction, I would have thought?
Fair point. I thought that had died down, though for some years I've not had reason to keep particularly informed about the state of WP so I could be missing a lot of hot gossip.
I wonder how early the domain was registered and when the first certificate was issued for it, whether you could’ve had advanced notice of this by watching the DNS records
Domain registration doesn't mean that much. Many similar domains are already registered, eg python2shell.com is 5k aftermarket but js2shell.com is unregistered. Might not be a bad investment to register the .com for all the top PLs.
This is obviously bad, but in my 20 years of hosting with PHP, I've never had to take the steps of taking down servers preemptively. It's not good, but honestly, and I think the way this was handled could leave a lot to be desired, I think this might be the "worst" we've had with PHP, and it took a while to get here.
FWIW this is the most mainstream vulnerability in the new era where everyone has access to AI agents that have the potential capability to find and widely exploit the vulnerability far faster than the past timeframes for disclosure and patching.
Turning on logging and seeing bots for the first time does not equate to novel or specifically crafted attacks. Web services get hit regularly by bots. A few dozen an hour is almost nothing for a public facing web service.
Yes, but seeing a few dozen of a new type show up within less of a day of the exploit being public is pretty mad. The usual probing is nothing special.
There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.
"The entire world should use 2x more compute" is not a real answer. You can do that on your own personal computer which has compute to spare. For servers, you're already paying for the relevant amount of compute to serve your thousands or millions of users, and every % of overhead matters at that scale. You are suggesting everyone allocates a 2x budget for server-compute, or I suppose you're only talking about hobby servers where people are running tiny workloads and had so little traffic it doesn't matter?
Large, well-optimized services are running at high CPU utilization all the time. But there's a long, long tail of services that are running well below 100% utilization almost all or all of the time, and it's not just hobby stuff. Vulnerabilities in those services are still real and can be very important, and trading some otherwise idle CPU time for an absolute shield against memory safety issues is a good idea. Even for some services that do have high CPU utilization it may be a good trade to pay for more CPU to get that shield in this new world.
In addition to what my sibling comments have said, there is also the advantage of pushing the ecosystem to safe and fast approaches as a whole. Imagine if the default was to run C/C++ software under Fil-C, if no other measures where taken by the developers, e.g. if the consensus interpretation for one of the current security regulations (NIS2 etc.) mandated it. There would then be an enormous incentive for software to provide faster alternatives to Fil-C, as there where 2x-4x speedups for the taking!
Come to think of it, I believe it would actually be a good idea to lobby for exactly that. Memory safety issues have been a plague in IT for far too long.
Running a parallel PHP-filc deployment at such times at even 2x costs would 100% be worth it. Especially that you'd only be focusing on web-facing deployments (and not background processors).
People keep defending PHP (as they have been for ages) saying things like "oh, it could happen to any platform, this one's just so popular so the odds are higher" but then you take a peek at the diff for this fix and realize that nothing has changed since Fractal of Bad Design was published a decade ago. PHP is a scourge and unfortunately a still too popular one. The best time to realize the only safe option is to stop using it was in 2010, the 2nd best time is now ..
yeah anyone wise migrated away from PHP ages ago. The fact it got lipstick on back with PHP7 doesn't make it a well designed programming language. At least in my experience the vast majority of PHP websites nowadays are old abandoned PHP5 projects, which aren't much worse than just slopping a rewrite in something else
It will take time if the PHP sites have a database with a business model built on PHP. But with agentic coding, at least it is easier. I already transferred all wordpress static sites to pure html.
For now this is just one person posting about it. Can be real, can be a mistake, can be a hoax. But if it's real, then OpenAI once again fudged up really bad.
Edit: and it's live now 1hour 43minutes after. Edit 2x: well I spoke too soon. not actually live - the 8.4.27 tag appeared, but it's still an empty shell with no amd64 image to build from. Maybe other architectures can be built from though. Ugh. Now we're at 2hours 24minutes in. I know process steps take time/can't be rushed, and I know people mean well and surely some are unappreciated for what they do. That said: this debacle is making me want to reassess my deployment pipeline choices.
how does Docker not yet have a new, official PHP image ready, given such a big heads up? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are 52 minutes past due. (posting comment again, because the other thread i posted in was marked as dupe.)
It went a few seconds ago. I was also surprised they didn't have advance access but thinking about it, with the whole thing being a public Github pipeline, it's unclear how they could have achieved it whilst simultaneously keeping the patch private. Is there precedent?
And now, at 2hrs 55mins past the PHP release, the amd64 image is available. Although it appears that the servers hosting the image are getting hugged to death because I can't actually download it.
Now they should be actually available and pullable! The only problem is that it took 3 hours with a huge security problem already exploited in the wild.
Not even $700 a month? Seriously, there must be thousands of highly profitable companies depending on this guy’s maintenance. Once this is all sorted, please hassle your employers to give something back to him!
Yeah this, I always see so much hate towards businesses for finding tax loopholes or not donating etc but people forget that businesses are made of individuals with their own often conflicting subgoals, but overall has to try to maximize profit so they will never voluntarily pay more tax than legal minimum or be philanthropic if they do not have to or do not benefit explicitly.
Thank you for calling this out. I absolutely rely on him so I decided to contribute $100/month even though I'm a solo dev with a business yet to see profit. But I absolutely rely on him for my server(s) PHP packages.
Speaking of, the PHP PPA was pretty unusable all day. I wonder, if this was just high demand or intentional attacks on launchpad servers to prolong the exploitation window.
It's not exactly uncommon, it's basically C's equivalent to exceptions. It lets you avoid having to do an extra error checking branch after every fallible operation and can quite significantly speed up the happy path of a language VM.
I know but I don't think the risks justify using this, as demonstrated here. "It's fine when it's used correctly" except it's so hard to use correctly. It completely messes up any analysis of codepaths because you have this "time travel" footgun that can bypass everything.
Exceptions aren't great for that either, but languages that feature them at least have the tooling and support features to make them work. C has no destructors or anything to handle exception unwinding cleanly. Scheme has call/cc, but scheme has a big runtime and garbage collector to deal with the fallout.
Let the branch predictor do its job and implement error checking properly, I say. If performance matters so much that you worry about pipeline flushes and icache thrashing, surely you wouldn't be using PHP anyway.
setjmp, longjmp and gets are 3 function I would absolutely ban in any C codebase I would be responsible for. Maybe strncpy too. and strtok. C is fun.
> It's not exactly uncommon, it's basically C's equivalent to exceptions.
longjmp is very uncommon, I don't recall seeing any high-quality C codebase using it, and if you want exceptions, you should pick a different language because longjmp doesn't really give you comparable semantics. It's basically saying "ok, computer, f--k my s--t up".
The fact that OOM conditions are an enduring source of exploitable vulnerabilities in PHP really should give everyone a pause. Like, that's not a thing in any sane project.
It's C's equivalent to exceptions, except without any of the stuff that might actually make exceptions safe and reasonable to use in other languages.
There's no automatic cleanup of anything, no built-in way to even register things for manual cleanup, and it doesn't even consistently save/restore the values of your local variables. A local variable that was mutated between the setjmp and longjmp may end up with the old value or the new value depending on where the compiler decided to store it. The documentation does mention this and says that you need to use the volatile keyword to avoid it, but in typical C fashion there's nothing to enforce this, it's just up to the programmer to remember it.
It is extremely uncommon in C codebases because it is extremely dangerous. It makes hazards like pointer arithmetic and manually-terminated strings look like a walk in the park by comparison.
I'm surprised by CGI. The vulnerability description talks about a second request being affected by corrupted state from an earlier request. But I thought CGI only processes one request per process?
Despite this coordination, WP-Engine (who's major business is hosting WordPress sites) is still on PHP 8.4.26 a full 2.5 hours after the patch is publicly available.
I'm checking by ssh'ing into my environment, and this is what I see as of 21:41 UTC, several hours after the patches were published:
wpe-user@MYENVIRONMENT.ssh.wpengine.net:~$ php -v
PHP 8.4.26 (cli) (built: Sep 23 2026 06:24:29) (NTS)
Copyright (c) The PHP Group
Built by Perforce Zend (www.zend.com)
Zend Engine v4.4.26, Copyright (c) Zend Technologies
with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies
I keep hoping for either a change in the version or the build date, but nothing yet. The incident status page says they're deploying, but there haven't been further updates about how far along they are.
They also have more to coordinate and manage. I don’t think it’s fair to frame it as them being bad at something. What they have to do is much harder, and it takes time.
When I’ve worked at small places, a security patch is bumping some versions and restating some servers.
I worked at a massive Rails shop for a decade and a big security bump meant mobilizing a team, coordinating updating dozens or hundreds of apps, all while maintaining platform stability and staying within SLAs. It’s a nightmare.
We have 4 servers with CloudWays. 2 of them are still not patched (20 hours since the patch was released). We cannot control the PHP version for our customers. Sucks to suck.
That partial stack trace linked above seems to match this GitHub issue, which has much more information: https://github.com/php/php-src/issues/24488 (double-free introduced in 8.5.12)
From what I can see, this causes a crash only, and isn't weaponisable. It's a use-after-free, but the reclaim window is zero by construction.
Is there anywhere good to get some sort of reliable stream of information about this possibility?
It's going to be pretty bad if we all panic to get the latest PHP up, and all confidently roll out our updated websites, just for them to still be vulnerable to something serious anyhow.
To be clear they said it “still works” and “ ok thinking more about this, there's no way this is the same vuln, this is another one.”
Meaning this specific bug the parent comment is talking about is not new in just these patched versions from today.
So delaying your updates today would mean you’re exposed to an actively exploited RCE and still exposed to the other memory corruption bug (which may or may not be an easily exploitable RCE) for an entire 2 or 3 days.
And from the sounds of it people are very actively exploiting this so waiting 24+ hours will practically ensure you’re hit.
lol this is the exact scenario where that’s an well idea. Maybe the patch is bad, but not patching for 2 days means your guarantees to be hit by the original issue
We are damned if we don’t and (often times) damned if we do
There is little difference between a tag and a branch in git. There is just the convention that tags reference the same commit forever, while branches move.
On github forks are part of the same physical repository. You could imagine that each logical repository is just a namespace for branches and tags, backed by the same physical repository.
I do consider the warning a bug if github, it should check both tags and branches for commits which are to be considered part of a logical repository.
GitHub uses this metaphor, and, as another commenter already aptly described, it could be nothing more than a fancy name for namespaced branches, on the server side.
On the client side, "forks" are usually different repository clones with different remotes and a "coincidentally" shared history.
But you can also map forked repos to multiple remotes of the same repository for example, instead of folders.
Assuming that forks would live in separate clones/blobs on the server is not really based on anything, so I think the warning is a good middle ground between explaining what forks are and how they handle them, and giving actionable advice.
It's also better suited for PR:
"Fork me on GitHub"
vs
"Branch and push your own clone on GitHub, using our shared blob optimizations".
I think the warning is clear and there's nothing misleading about it, but others have already pointed this out and git can be tricky.
It's so good at providing the right level of abstraction to everyone though, it seems!
Similarly, GitHub invented the term "Pull Request" (aka PR, lol).
Not a git-owned term.
But "merge request" isn't a Git primitive either!
And, with Forks and Pull Requesrs, GitHub made a particular workflow in Git approachable to anyone!
I love GitLab, but people get confused by Merges, myself included, so the GH-enabled workflow of favoring ff-only merges, without merge commits, with quadi-linear history, became the norm and helped Git succceed!
But I also appreciate being able to do all kinds of different workflows.
So PRs were positive-sum PR at the time, I'd say. When they became popular, I was still taught Subversion and CVS at uni, alongside Git as "the new thing". Ar that time, many people considered the older systems simpler, and pondered SVN as the most reasonable middle ground between CVS and the decentralized concept of Git!
It can mean either, it's a consequence of how github optimized their backend storage so a 100 forks of a repo initially take up the same space as 0 forks
> 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.
If only we could come up with a way to manage memory automatically. Alas, one can only dream.
I'm pretty sure this class of problem would exist in GC'd environments too unless they're configured to abort on OOM, in which case you'd still be dealing with denial-of-service.
In some environments OOM is a trappable exception, so it's possible that incorrectly authored code would trap the OOM and 'recover' with partially initialized data sitting on the heap. Hopefully it's a memory-safe language so that partially initialized data isn't RCE...
If LLM's are going to keep finding vulnerabilities of this magnitude, we'll be sure to face a computer worm event of unprecedented scale soon. Best be ready for the moment the lights turn off
Just pulled the new matomo that was published on dockerhub 26 minutes ago, thinking it has the patched PHP version:
# docker pull matomo:latest
latest: Pulling from library/matomo
Digest: sha256:6e63589d31ec653f78e029084d21488640fdbbd9a42c96c872098f42c8678a02
Status: Image is up to date for matomo:latest
docker.io/library/matomo:latest
# docker run --rm matomo:latest php --version
PHP 8.4.26 (cli) (built: Oct 21 2026 00:31:19) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.4.26, Copyright (c) Zend Technologies
with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies
The PHP build is from today, which is doubly misleading. 8.4.27 is the patched release, not 8.4.26. I wonder how many people will pull this image thinking they're good to go online again.
The "official" PHP Docker images turned out to be a shit show tody. Seems like many maintainers fell for it and published updates that aren't really updates.
I'm currently waiting for a new docker image for another project, and their maintainer noticed the old PHP versions in the freshly built images and is still waiting or working on releasing a new container build.
"Let's use this packaging some rando on the Internet built" is a strategy that is exactly as good as it seems, but that's the Docker ecosystem for you.
Packagers who actually understand the software put in good work to package that software in small and well maintained packages. Use them instead!
Fully agree. Moved to FrankenPHP's static build (which was ready very quickly) to get away from it. Don't intend to ever use the "official" images again.
I'm wondering if it's not just better to use plain Debian base images.
FROM debian:...
RUN apt install php ...
This will take longer on a cold build cache, and pins the PHP version to the current Debian version. But Debian once again proved very reliable to patch in time.
I had to build and deploy my own Nextcloud images earlier today. :( Not a big deal because docker, just obnoxious that this got released into the wild and was being actively exploited before patches were available everywhere.
Some have, but others are still showing "needs evaluation", and still no update for 20.04. I've just turned off php for now, as we only used it in a couple of places and won't be missed for a day or two.
What would happen if the director suddenly gets sick or decide not to come to work anymore? A lot of people assume that humans are reliable, they are not.
Exactly: limiting access is fine, lack of contingencies is not.
Some systems and services still only allow for one owner though (I'm not going to name names), which can be a big problem when MFA is mandated. From what the poster I responded to said, I'd be very surprised if that were the case for them though - just slightly daft policy.
One of my first boss called it the bus factor, not sure where the term comes from. What's the minimum number that need to get hit by a bus before it's impossible to keep things running. He used to say "you always have some bus factor, but it should never be one unless you're alone, otherwise you deserve whatever crap is going to rain on you someday".
I've found that to be incredibly true in my career.
My team rotates 1 sacrificial member every week to be on call with prod k8s access. It limits who can just push things to prod at any given time while making sure everyone on the team has experience. If someone is out sick or on vacation we do time trading, it works out for everyone.
I was fire-wardening at a carol service about 15 years ago (think ~850 year old gothic stone church with thousands of candles spread around on every available flat surface - looked amazing, potentially catastrophic).
I was sat near the back with a bucket of sand under my seat, and a guy sat in the middle of the row just across the aisle from me, who would have been around 40 or so, had a heart attack and died.
No warning, no history, just gone, and leaving a fairly young family behind. It was honestly shocking.
With AI agents, I've been using sites/services that are bot friendly and don't require MFA.
Not everything needs hyper security. Heck, I've given AI access to spend money on websites and my only restriction is that the websites limit the daily spend(website side... Although I guess a rogue AI could have changed it... )
So far Ubuntu LTS isn’t picking up the new packages for me via apt update, and Laravel Forge appears completely unresponsive as a result of being flooded by people trying to update their servers.
And I'm maintaining a box on 18.04 over here, and lo and behold its Pro subscription isn't showing up as active, so I couldn't get the update even if they do release it.
Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)
how does Docker not yet have a new, official PHP image ready, given such a big heads up? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are 27 minutes past due.
It would not be easy (or reasonable) to take a public build like that private to build a 'secret' image version, and I'm not sure GitHub even has the capability to do that. I would not trust a build pushed to Docker Hub separate from the established / public / auditable process they have in place.
All dependent (official) images need to go through the same process, so that makes it fairly problematic, and I think Docker needs to take a look at it for the future.
> I'm not a maintainer and can not merge this. Please wait until a maintainer has come around to look into this.
> This is merged, but I cannot find the image?
> After this PR has been merged, more steps are to be taken, including an upstream merge on docker-library/official-images and subsequent image builds. For a full description of the timeline, please refer to docker-library/faq#an-images-source-changed-in-git-now-what.
This issue with the "official" Docker images is the reason why (when I was still at SUSE) we switched to pushing releases ourselves to our own project and then eventually to our own registry.
This push for centralisation without the infrastructure to back it up has always been the most frustrating aspect of Docker Inc over the past >10 years I've worked on container runtimes.
Well they did specify "successfully." EITW is a pretty broad tag, just means attacker are probing servers. I'm not saying it's good but there are usually some pretty big caveats with remote-remote memory corruption, don't know if all the people dooming are aware of that
> Exploit portability and reliability depend on the PHP build, extensions, frontend behavior and allocator layout.
i just took down all my PHP sites for the last few hours. they’re proxied behind Cloudflare so i know there were mitigations, but infrastructure can’t be breached if it isn’t running!
Similar here, except I didn't want to actually shut down the servers, because then I can't patch them! My solution was to just turn off Nginx, which prevents anything from reaching PHP. Then I stuck a caddy server with a temporary config so we get actual 503 maintenance responses.
It seemed to be helpful for others too so I packaged it up, should work on most Nginx / Certbot servers. hopefully its useful: https://github.com/Indemnity83/popcorn
I once wrote a PoC for reading data off of a dead Open Compute Grand Canyon server that wouldn't boot by sneaking it off of the HDDs through a sideband through the BMC. Never say never.
>Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
I'm starting to suspect that they actually got the notice the same time we did, because if they got the patches there should be no reason it wasn't already built and ready to go (unless they're scared that "our build servers are public and everyone will know" so they literally held everything off until the release which seems so counterproductive as to be ... well, open-source silliness).
If you mean docker official images, it's just the "community" maintaining it, eg "some dudes". By no means should you consider it a mechanism to get timely security updates, I've seen horrible lag on that before.
Most of docker is like this. Images provided by volunteers, and not related to the project. Using docker images you don't maintain yourself, and at least don't upgrade yourself, is not the best recipe for security.
There are different approaches and it all comes down to who you trust. I don't think there's universal answer. If you have money, find image provider who's serious about security and hopefully they'll provide patches images quickly. Otherwise using Debian packages is a good default I think.
Honestly I don't even understand why so many docker images prefer to build software from sources, rather than just installing them from debian repositories.
And if you're using a docker package it's often JUST BECAUSE the host Debian/Ubuntu server is out of date for things you need, and Docker's the easiest way to "patch" that.
There are rare occasions when circumstances are more important than preserving an "EOL" designation. This appears to be one of those times where "official" centralized patches really should be made available for at least PHP5.6 and PHP7.4, and perhaps even 5.5 and all of 7.x. They're not covering themselves in glory by refusing.
Yes and in general lots of users being on unsupported releases should also cause som reflection why that is. E.g. maybe support periods are too short or there are too many breaking changes with new releases.
It looksl ike they released official patches at least for 7.4 though:
> Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
Yes and no, you have two setup, you're on LTS, it will be backported (done as I write than on Debian), not on LTS and you already have hundreds of unsafe stuff running anyway so it's just one more to the pile.
Yeah, I have a legacy site that is popular and doesn't make money with some outdated version of PHP that will not update. Maybe I need to install OpenClaw on it.
But yeah, with AI agents, I don't really understand the purpose anymore. Legacy WordPress or laravel sites?
If those place at using a LTS release of their OSes they will be patched quickly (Debian already has). If they're not, they're already screwed by a lot more than just PHP I guess.
Those websites can easily run in a php5 container, whilst the host os is up to date.
Websites depending on an older framework like Zend Framework or libraries like Doctrine 1 do not have a clear upgrade path and are stuck at php5 or have to basically start from scratch. php5 to the latest php8 is just a jump too big.
Why is the description of "RCE via OOM corruption" mentioning all these settings like memory_limit, post_max_size, max_input_nesting_level etc under "Mitigation" but not blocking multipart requests? Isn't that a solution?
The description of the vurnurability "Several multipart parsing problems" makes it sound like it is?
Yes, there have been decades of talk about this already—ensuring you isolate/jail the PHP-related processes and run them with an unprivileged user, etc.
I've created patched Dockerfiles for EOL PHP versions. The patch is obtained from official source trees.
I've also published the built images from them to GitHub Registry, but of course it's best to inspect any public repo/docker image before using them blindly.
I fail to see how that’s useful. Why would I care about the layers inside an image when I could just extract the entire filesystem inside. Even then it is not useful if we don’t have a culture of reproducible builds.
Fair, "inspect the image" was a bad way to put it.
What I meant was: don't trust prebuilt images from a stranger, including mine. I've provided them just as a convenience, the Dockerfiles and patches can be easily looked-through, and building them yourself is the safer option if you need these docker images.
Great that its out but if you depend on pecl for additional extensions and need to rebuild docker container it will probably fail because pecl is having issues for last few hours[1].
My hosting provider just informed me that they took down my website over this to "protect" me. It's a static website that does not use any php. But it's a generic LAMP hosting provider so they just took down all their hosted websites. I had it on my to do list to migrate that to cloudflare anyway. So, I guess I'll be doing that soonish now.
When every neighbour decides to leave their doors unlocked simultaneously,and the entire world knows it, maybe barricading the village is protecting you
Really makes me appreciate using language with exceptions and not that crazy "manually check if error handling is required - and do it everywhere". The fix adds:
Debian always seems to be the grown-ups. I'm a Linux novice so I couldn't get Nvidia drivers working on it but that's the only reason it's not running on my desktops.
Yes, it's pretty common with large open source projects in the server space. Makes sense when releasing a fix also means releasing information that will let others exploit the bug so users need to be prepared to install the update quickly or take other measures to protect themselves.
Many vendors do it, but on a set schedule "patch Tuesday" and some will release vague "mitigation steps" but honestly those usually come with the patch.
Tell them to take anything with PHP offline, so that it isn't available from the public internet. That is how Netcup and Contabo are handling Wordpress hosting until they've upgraded all affected packages.
There are already functional exploit scripts on GitHub, you can target any Wordpress site right now.
> We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
> 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.
Earlier versions are not fixed by PHP official and need vendor patching where available
> Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests." -Rasmus Lerdorf
Not sure how, but from the announcement: Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
Also, CGI PHP skips request cleanup on init failure.
I'm 90% sure CGI can't be exploited this way in default configuration with ASLR and 99% sure if PHP is configured with memory_limit=-1
That said, don't be an idiot and switch to CGI instead of patching. I'm like one of three guys running PHP in CGI mode and I'm vaguely satisfied I have the most resistant configuration.
The reason, BTW, I run PHP in CGI mode is so I can (moral equivalent of) suexec to a locked-down sandboxed environment that limits exploit blast radius. I could do the same with fcgi daemon, but the suexec is stateless, and roundcube doesn't need the performance.
In general, anything stateful or long-lived is just one more thing that can go wrong. One reason why the trend of turning everything into a persistent daemon drives me nuts.
PHP runs literally half the web. Half the web will not apply this patch in any reasonable amount of time (a huge portion will never). This is going to be absolutely catastrophic.
The union of hosters which will not update to this patch, and users who have not updated to the past 283762 CVE is literally the same circle. I think that maybe a couple new not infected machines will get infected with a cryptominer - the rest will just get one new miner fighting for resources
They should probably invent some sort of Crypto Miner Communication Protocol (CMPC) that will make the process easier for all miners out there. Let's hope most are not bad actor crypto miners who ignore the protocol though, we should strive for more good actor crypto miners.
So if I wanted to build a botnet, then it would be very easy ;).
Infiltrate vulnerable PHP sites. Install backdoor(s). Secure root access. Patch PHP to lock out script kiddies. Let it sit dormant until you need to launch attack
I think there's a lot to learn from the last twenty four hour's events. An absolute nuclear bomb of an exploit affecting every version of PHP back to 2012 (which nobody should be using of course, but I've worked in plenty of environments that are not up to date).
The thing that's annoyed me the most is the speculation and misinformation, filling in the gaps. Folks looked into the php-src and figured out one of the vulnerabilities, starting saying you should disable certain php settings and then core PHP developers on obscure mailing lists hinting this isn't enough.
Given how inexpensive it is for agents to scan popular OSS projects, disclosure needs to be more discrete and you cannot publish fixes to OSS before disclosure. People will be and are watching for this kind of thing already.
While the fix was not published I genuinely thought a quick service rewrite to some other stack (say Go) would make sense as a fix. (Assuming high integration test coverage )
...and If you have a server in a closet still running PHP 5 or 7, hosting that project you’ll rewrite “next quarter,” this might buy you some time: https://github.com/analogic/phpsafepass
I'll give a shoutout to Lithium Hosting. I was able to log in and update my PHP Pool per their custom control panel and switch all of my sites over to the latest fix: 8.5.12.
For those who can’t patch their PHP for a variety of reasons right now, here is a proxy I developed that can sit between nginx or apache and your PHP-FPM, to sanitize inputs and prevent this (and other) attacks:
I got downvoted heavily by other HNers for merely offering a solution to protect people’s legacy PHP servers. They said it should be deleted and “not worth working on”. The solution was free and open source but these downvoters commented as if it was worse than having your server PWNED. I still don’t understand why.
I have this slight suspicion this was not the last critical PHP apocalypse ... :(
Some web-services are back up again here in central Europe, but some
are not, which is very annoying. Kind of surprising to see how much
PHP is actually used. Hate it or love it, PHP really is very important
still - lots of the web depends on it.
> 8.1 and earlier Not patched: these versions have reached end of life and will not receive an official fix
I would not recommend using PHP. The PHP team keeps breaking backward compatibility and trying to introduce new features instead of focusing on fixing bugs and hardening the compiler.
What I've been feeling lately is that security vulnerabilities will inevitably keep being discovered, and I worry whether humans can ever patch all of them.
This is extremely damning for Cloudflare. I had a bunch of clients telling me Cloudflare is all they need to prevent this, and they want to get that on their site instead of upgrading PHP.
I have not seen confirmation Cloudflare is doing anything except playing whack a mole with certain request patterns. PHP Core Devs have been clear you need to upgrade. If this is true, it's disgustingly opportunistic that Cloudflare is using this critical security time to lie to people that they are safe.
It's great they are doing mitigations, but they admit themselves, in fine print, that this will not protect you from the vulnerability
Why is word circulating that you can just sign up for Cloudflare and be 100% protected from this? They are burying the leed and trying to get new customers, and it's working.
What I did on our WordPress boxes while waiting for distro packages (CVE-2026-109618 / CVE-2026-109619)
1. session.upload_progress.enabled = Off, in php.ini and as php_admin_flag in every FPM pool, so per-directory config can't turn it back on. It's one of the two confirmed consumers in GHSA-6wmf, and the validated FPM path depends on it. Almost nobody uses it, and the advisory suggests leaving it off even after patching.
2. Refuse multipart request bodies at the web server, before PHP parses them. All of the GHSA-w8hw out-of-memory strategies go through multipart parsing. On Apache it's a rewrite rule matching a Content-Type of multipart/form-data that returns 403. On Caddy it's a header matcher that responds 403. The cost: every browser upload breaks (media library, plugin zips, importers). Check your public forms first.
3. Check your SAPI. Both bugs have confirmed RCE against mod_php. FPM is narrower: the validated path needs upload_progress, and the early INI consumer only applies if your front end sends PHP_VALUE/PHP_ADMIN_VALUE. To check, grep your Apache, nginx and Caddy configs for it, and run apache2ctl -M | grep php.
4. pm.max_requests = 1 in the pools. A worker serves one request and exits, which breaks the stale-state chain: the "producer" and "consumer" requests must land on the same worker. It costs a fork per request.
5. Lower max_input_nesting_level and post_max_size, per the advisory.
6. Housekeeping that should already be done: no .php served from uploads directories, and remove any stray phpinfo.php. Scanners request it constantly, and it tells an attacker your exact build.
I’d rather just some sort of tag. Because sometimes it can be useful. This is a case where the community here can scrutinize the output and actually pull out useful data or steps or even starting points when information is coming in so fast for a developing story/issue
The (pretty obviously Claude'd) responses with actual steps you could take to mitigate were 1000% more useful to me than the "SHUT EVERYTHING DOWN WE'RE GONNA DIE" and the "stop posting AI slop" posts were, that's for sure.
It was your response. Of course you prefer your response.
The fact is you had no idea how useful or dangerous your advice was. PHP maintainers said to shut it down, how many people followed your advice instead? Did it work or just leave them vulnerable? Do you know?
Because you're heavily implying that the people who knew about the details of the vulnerability were panicking and thank god we had you with an LLM
People have been saying this for the past 16 years, but the reality is once a system is in production over time it becomes increasingly risky to replace it. Because over the life of a piece of software you make tons of small fixes, resolve bugs, adding customer-specific functionality, etc. that you'd completely overlook when planning our requirements for a rewrite. Which is a big problem when other systems are dependent on the software operating a specific way i.e. APIs, web services, and so forth. Not to mention the economics of a rewrite also has to make sense. Nobody is going to spend 2-3 years recreating what they already had and get no additional functionality out of it. Certain software basically has to get so bad that literally anything replacing it is better than what came before for replacing it to be the right approach.
People shouldn't be using PHP. I was shocked some security focused websites are even using it. I just hope there's nothing of value on their servers and that it's not connected to their internal network in any way. In my experience this is almost always the case because it makes maintenance and development easier but effectively exposes your entire organization to the internet.
That 70% of the internet still uses it is shocking to me. These organizations deserve to get burned badly. Let this incident be a warning to all of them!
PHP is not a particularly insecure language. It’s certainly more secure than something like C or C++. Certain PHP applications are known to have vulnerabilities often, like WordPress.
PHP is a memory-safe language. This vulnerability is a memory safety bug in the VM, which does happen from time to time. It happens with V8 (JS), Java, C#.
To me PHP has an aura of "unprofessionalism" around it. Many of the PHP solutions have been hacked together by amateurs who sought a solution for their own problem and by chance it became widely used.
The language itself was one big hack when it was created. It has improved somewhat but just like with C++ you can still use the C syntax that's at the core of it all.
This isn't the last we'll hear of PHP vulnerabilities because the exploits exist on multiple levels. Not just the language (runtime) but the solutions using it too.
I mean you’re just incorrect about the C++ vs C comparison here.
PHP is a memory safe language, just as memory safe as Java, C# and JS. The runtime itself has very few vulnerabilities and bugs, and is quite mature. There’s no “drop down into C” type thing in PHP, where you can just write unsafe code whenever you want. The closest thing is extensions, which operate on the runtime itself.
In the past 10 years, the PHP runtime has had little to no exploitable vulnerabilities. The V8 runtime has had much more. Mostly because their implementation is much more complex.
The PHP language was hacky in the very early days, but for over a decade now it’s been mature and professional. It’s basically just dotnet.
Can't we fingerprint the code in github and elsewhere and tell AI labs to not do security reviews on the code unless (A) someone is a legitimate security researcher or (B) someone is the owner of the code.
Yeah it sucks, but the alternative could be worse.
last I looked, automatic updates for wordpress meant letting the web server write to the document root, which may be on the same level of negligence as not updating quickly.
Plus, wordpress updating isn't going to help you upgrade php.
Know how recompilers are porting video games from one platform to another these days? That exact trick works just as well for finding vulnerabilities. Broadly.
1. Hey LLM, turn this binary into source code.
2. Hey LLM, see any glaring security issues with this source code?
So how is PHP being distributed in your funny world? Because I can tell you, even if you put it behind “register with your work email,” whoever seeks the binary will find it.
> Know how recompilers are porting video games from one platform to another these days?
They actually aren't. Most of the claimed cases of "recompilation" are just an emulator packaged into the same binary as the game so you can't tell it's an emulator, or are for projects that already had their source code available (in which case "porting" to WASM is trivial because all of the hard work is done by the people who write your-language-to-WASM compilers, and you just need to do a little bit of work to adjust your toolchain to use it). Everyone just takes slopshit at face value and shares clickbait without actually checking any of the work done. It's infuriating how empowering this software is for liars, honestly.
No, the entire world abandoned it when you realized it wasn't the perfect language. The rest of us are just role playing today basically. It's a bit of a lark, kind of like civil war reenactment.
Looks like a co-ordinated disclosure between Wiz, Calif and OpenAI:
https://www.php2shell.com/
https://www.wiz.io/blog/php2shell-php-rce
https://calif.io/php2shell/
https://openai.com/index/coordinated-disclosure-of-critical-... (not yet live)
https://thephp.foundation/blog/2026/10/21/todays-php-securit... (not yet live)
I feel like all "non-inner-circle people" here are taken for a laugh. OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix, and then leave the rest out to dry while they failed to properly contain it.
The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details. Specifically once the POC came online. Would have been significantly more useful than these polished blogs.
Perhaps I'm missing something here, but the costs (dev/sre time, missed sales, potential data leaks and hacks) of the way that this was handled is significant.
[1] https://github.com/php/php-src/security/advisories/GHSA-6wmf...
>OpenAI and these security companies sat on this for 2 months
these security companies reported it 2 months ago. it took a month for the php security team to acknowledge it and another month for the php team to develop & release the patch.
if you're going to be upset at anyone it should not be the reporters.
>The official interim fix for php8.5 [1] could have been published 24h ago, or even 2 weeks ago, without revealing any security details.
publishing the fix = publishing the security details.
This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails they get.
If I had details on a RCE like this I'd report it but if I got no response for a WEEK I'd be trying other venues.
I imagine more details will come out over the coming days, but it’s not uncommon for severity to be under-estimated in the beginning; and then “oh shit” as you dig deeper.
We don’t know when it went from a “memory safety issue” to “php2shell/RCE”.
Calif’s report is a little light on timelines, but reading between the lines, it seems they took a while to turn this into an actually exploitable vulnerability.
Finally, at least pre-LLM (and maybe a bit outdated now), responsible security disclosure norms is that you usually do wait for vendor (up to 90d) if there’s no signs of active exploitation. Even if it’s a RCE. Actually, especially if it’s a RCE.
The last thing you wanna do is go pinging random non-security PHP contributors or maintainers and have it leak with zero patch. That is truly the worst outcome.
Yes, this is bad, but also, it’s apparently been bad for decades; and it could’ve been much worse.
According to this post, one of the researchers was a former PHP security lead who already knew about the bug since 2004. So I'd assume they would be taken as credible by the current team https://calif.io/php2shell/
As I mention elsewhere (https://bugs.php.net/bug.php?id=78876) I'm very confused. Looking at the PHP bug tracker the specific bugs were fixed. So my best guess is that the LLM was able to find alternative variants that still worked? But then the report makes less sense.
Assuming that it could have been spotted in their inbox, amongst a probable flooded of LLM slop like a number of security mailing lists for open source projects that I know of. We've all seen the impact on open source github issues, hackerone etc. The same is happening to standard email disclosure paths.
These illustrations are neat but severely distracting given that each make a mountain out of a molehill.
>This really sounds to me like "they filled out some webform" or "sent an email to security@php that read like any of the ten billion we found vulnerability in your code please send money emails
i highly doubt it. these are pretty big names in the security sector who have plenty of experience reporting high severity vulns.
and they also have plenty of exposure to their motherships burning money on LLMs
I've said elsewhere I am sick to death of reading AI written "security disclosures". Even for genuine issues, it just saps my motivation to fix them.
That said, PHP team handled this poorly. How does letting everyone know so they can "prepare" help anyone at all. It just creates panic.
If you provide forewarning, system administrators around the world in various time zones can get ready to update at the same hour the fix is released, which is very important. Being hours late is not acceptable for a vulnerability like this.
And yet it seems all their forewarning did was lead to the proof of concept being leaked many 'valuable' hours before.
I think its unreasonable to expect reporters to do anything other than report the bug. Its not their software.
General industry practise (or at least google) is to wait 90 days of being ignored before trying something else. And google got hugely criticized in the beginning for only waiting 90 days. You are suggesting this person should only wait a week before going full disclosure? They would be crucified if they did that.
Are you victim blaming the reporter?
If you have a bad process, fix the process.
>if you're going to be upset at anyone it should not be the reporters.
Everyone is just upset by AI. So they want to blame the side that was involved with AI. It's like how cops automatically assume black people are criminals.
Why does the PHP security team need to acknowledge it and develop the fix? It's open source software.
If you want an orderly fast global rollout you need to have the maintenance team and distributors working together.
So anybody can just push out a new release of PHP?
Yes, someone could have published a safe version for people to use for the 2 months to get the actual fix done.
>Yes, someone could have published a safe version
this is basically the same as releasing a working exploit.
And that's not a bad thing. If it was, the the logical conclusion would be to never publish the fix and don't preemptively patch before active exploitation.
Yes it is.
Say I release a fix. I'm some rando but I go out to the world and say I fixed an issue with php. Use my version instead! Not telling you what I fixed, it's a secret, just trust me.
It will take, with LLM help, attackers a couple hours, tops, to reverse engineer my fix into active exploitation. Meanwhile, I'm some rando so no one's even heard of me, people who do hear don't automatically trust me to install my fix, so very few people have my fix. Meanwhile, the exploit is out there thanks to me and people are getting their sites hacked thanks to me.
That seems like a problem, no?
How is what you are describing any different than what happened today? Except the vulnerabilities were also explained. You can say that sites are getting hacked right now due to them releasing the security update.
>I'm some rando so no one's even heard of me
Why do think people need to have heard of you. If you are reporting this issue directly to distro maintainers, security companies, hosting companies, etc first you can help use their names as part of the marketing push to raise awareness.
> How is what you are describing any different than what happened today?
There was an official patch within a few hours. It probably would have been a lot longer.
And that was the screwup case. If today had gone correctly the official patch would have been out by the time the bug was public.
And in the situation where they released a security patch 2 months ago, there would be a security patch before the bug was public.
2 months ago there was no patch and no possibility of a very quick patch. Releasing details then would have been very bad.
If you mean they should have released the patch as soon as it was done, it's true that it would have been before the bug was public... for about five minutes. When a warning a day or two before patch release works, it lets admins prepare to patch immediately and/or shut down their servers before the release time.
Even with the leak, admins still had warning and it was better than an unwarned official patch drop. Which itself is better than an unwarned unofficial patch drop. Which itself is better than an unwarned drop of exploit details.
We are talking about a hypothetical where a patch is made <2 months. With AI agents, I can 100% assure you it would take a max of a few days to pat CB and test a mitigation. Not months.
If you are warning people to turn off their servers. You might as well give them a patch at the same time.
Let me try to split these concerns up:
1. The time it took to develop the patch doesn't matter. Nobody leaked anything during that period. It just needed to not be a huge length of time.
2. The time between the warning and the patch release is overall a good thing. In this case the secrecy failed halfway through and we only got a fraction of the benefit, but it was still better than "surprise and good luck with the imminent exploits, hope you weren't asleep!". If the secrecy hadn't failed it would have been much better.
3. There needs to be an official patch before releasing the details. Some random untrusted person publishing a patch has all the downsides of releasing the exploit but people can't safely install it fast.
Sort of by definition of open-source, yes. It's just that nobody downstream is likely to accept Joe Public's random fork of PHP.
You're confusing PHP the product with PHP the codebase. The former is what is the only relevant part in the security world, where a product is synonymous with its vendor (even FOSS).
I mean, it's all semantics at the end of the day.
The PHP maintainers have generated a certain amount of goodwill over their long service, which leads downstream consumers to trust their releases over every other packaging of "PHP the open source codebase".
Nonetheless, there are countless forks of that codebase, and there are other releases than the ones made by the PHP maintainers. Any particular downstream could switch to another source of releases if presented with a compelling enough reason.
Did start writing software this week?
So if Wiz produced their own patch to PHP, and Calif produced their own (slightly different) patch, and OpenAI produced their own, which version should I use, as a user of PHP? Should I manually merge them? Is Calif's better than Wiz's? Is OpenAI's better than Calif's? Are they complementary?
That does happen with downversion software. Red Hat may distribute a backported patch to some component which isn't the same as Canonical or Debian's.
Most users, who don't know the answer to your questions, rely on the distro to figure this out (and often pay good money for it).
They already were in communication with each other. They could have come together and decided on one that mitigates the issues they've found.
What's the other choice? OpenAI et al could have developed a patch (for all we know they did) but you need the PHP team's participation to get it out. The alternative would be to fork the project and put up a forked release with the fix, which would have been incredibly disruptive.
I'm glad they didn't do anything disruptive, then. Like wind the world's CIOs up into a frenzy of FUD and bring thousands of servers down in a coordinated panic attack synchronised to the minute.
Imagine if they had just patched the code and rolled it out with an advisory?! Oh my GOD! Won't someone think of Sam Altman and his huge pile of debt?!
Pre AI, silently publishing a fix to a security vulnerability was considered bad practice.
Post AI, Its efficiency pre announcing the exploit to bad actors until the official disclosure.
You can just watch the diff log of every open source project with a small local model, and look for anything that touches buffers, function pointers, or shell integration.
It could be an hour between release of a fix before the exploit starts attacking servers.
Guess what also could happen within an hour? A coordinated Internet wide panic that shuts down all vulnerable servers.
---
We actually have a recent example. OpenAI hack.
An undisclosed vulnerability fix to a image formal lib; packages into debian 12 running in a docker, used by imagemagic, used by discourse running OpenAIs user forum.
What would you have a security team for then?
To handle the official solution and drive long term changes to reduce similar security bugs from happening again. The current PHP security team does not seem capable to promptly release a fix, so having a community fix first seems preferable.
Mitigating a bug and developing a proper solution that is maintainable long term and supports future changes being made to the software take different amounts of time to develop.
Because...that's what the PHP security team does?
No one needs to use their work, or indeed PHP at all.
But that's why the PHP security team exists.
If it takes 2 months to do fix a massive security issue, it's best if someone else steps up to the plate to fix it.
I don’t think the parent would disagree.
But the PHP team is the one that got the security disclosure.
One concern with the current environment is that as soon as a release comes out for such an important open source project, people will immediately point bots at the release to look for changes that might be related to existing security issues. This means that putting out a quick out-of-band release is guaranteed to result in people racing to exploit the problem before many even know there is an update out.
Whether keeping the update quiet and including it in the next normal release, where there are more trees obscuring the wood that is the security concern, and announcing the bug a short time later once anyone using distro updates or otherwise keeping on top of things have updated, would be safer overall than what has happened today is up for debate. I can think of arguments in both directions.
--------
[1] which does have a slight whiff of AI marketing about it - would a human-found issue, without the option of a big AI company to claim some credit, have been handled differently?
This is not a "concern", this is literally what happens. Even prior to AI vulnerability scanning, release notes and diffs for any normal release or security patch of popular software were analysed and used to develop exploits, which could then be applied against non-upgraded instances. Nowadays, AI is doing this en masse and automatically producing exploits. And, as has been demonstrated, nowadays even the rumour of a major security bug is enough for people to find it, as people will immediately burn huge volumes of tokens looking for it.
Nor can you just keep it quiet and smuggle it out in a regular release as you suggest. For one thing, changes in important software are be linked to commits and have pull requests, reviews, etc. Changes without these will immediately raise suspicion, as either a malicious change snuck into a release, or as a "quiet" fix to a major vulnerability, completely undermining the purpose of keeping it quiet in the first place. Moreover, major vulnerability fixes cannot be "quiet", because the whole point is to get as many people as possible to upgrade as quickly as possible. If PHP (or whoever) push out a release containing a major security fix, but don't make this clear, then many people will be in no rush to upgrade, and will get pwned.
> This is not a "concern", this is literally what happens.
Sorry, I should have been specific: the concern is that this will happen faster than even the more fastidious admins (or daily or even hourly automated checks) will spot and apply updates.
> nowadays even the rumour
I think a lot fewer people would have paid attention at all without the rumour. Some ne'er-do-wells might have scanned a larger update for security issues otherwise, but I suspect most of those spending tokens on PHP this week would not have bothered had there just been a standard maintenance release that may or may not have included changes for a security issue that may (but probably not) have been so globally significant.
That is, at least in part, why the question of how to manage the release of updates like this is not a settled debate.
> then many people will be in no rush to upgrade, and will get pwned.
The worst case that we may be heading towards is that for any services on public facing infrastructure we might have to automatically apply updates with little or no time to verify, just to try be ahead of the ne'er-do-wells, with even superficial updates not mentioning the changes until a short time after to avoid giving clues to those who will scan for security issues if any such is mentioned (or nothing is mentioned - saying nothing about a security-only update only works if you say nothing about all updates, and you don't want to hold off on security-only updates on a slow moving project that might not have a non-security patch for quite some time).
It's not possible to publish a security patch for an open source software report without revealing security details anymore (and as of the past couple weeks I would not count on being able to do that for closed source binaries either). The moment you push publish everyone knows previous versions are compromised
You can't do secret releases, people will figure out what you added or changed.
But they could have accelerated the patch release once the embargo was broken and rumors of a PoC started going around. There was no need to wait 12+h today until the release.
“OpenAI and these security companies sat on this for 2 months”
I don’t think this what happened at all, and even less so to specifically call out OpenAI.
The issue was discovered using their model, it was disclosed, and the PHP team took months to address it. Eventually it leaked.
This is a process / people failure that does not involve the people responsible for discovering it.
this is the same tired conversation whenever coordinated disclosure happens
"we the people deserve to know about vulns on day 0"
oh yeah? and what happens when a 0 day is released?
it's the same ignorance over and over.
Php core security team decided who gets to know. The patch was huge it took that long.
See PHP foundation blog post on their timeline
Maybe the NSA ‘requested’ some time to use the exploit on some high value targets.
Sure, it’s PHP, but plenty of companies or organisations might have some PHP running somewhere; and once you’re in, lateral movement becomes a lot easier.
The NSA does not need to "request" time to use an n-day vuln. They have more 0-days than you can imagine.
They literally employ full-time Vulnerability Researchers doing nothing but 0-day discovery and PoC creation 24/7 to add to their horde. Plus contracting with the MIC for their full-time VRs for the occasional project.
Exactly. Something like this is often the NSA realizing one of their pet vulns is being exploited in the wild by someone “not them” and so they burn it.
> OpenAI and these security companies sat on this for 2 months
The PHP team knew about it since September 21st.
> OpenAI and these security companies sat on this for 2 months, decided for themselves who gets access to an early fix
Amazingly, AWS Linux has not been patched yet.
And then they proceeded to cripple any of my agents working on this.
> Over the past two months, we led a coalition of maintainers, researchers, and security providers to address critical vulnerabilities in PHP, an open-source programming language used to run websites and web applications.
And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
If I understood the timeline correctly, there was an announcement made somewhere that an RCE would be announce w/ a patch, and the internet just scanned the entire codebase, they really fumbled this for the sake of having a PR post for OpenAI.
On the other hand, I don't mind AI companies doing this sort of thing, I'm sure a lot of our internet infrastructure could benefit from these sorts of fixes and changes.
After the HN post came up, one security firm included "session.upload_progress.enabled", "session.use_strict_mode", and "php-fpm" in the SEO tags for their initial disclosure that a vulnerability existed. I imagine this was a good hint. https://web.archive.org/web/20261021005246/https://sansec.io... https://x.com/its5q/status/2112700519261032497
The somewhere was a loser on this very website https://daubois.dev/blog/cve-2026-109618-php2shell-rumors/
This post reads like pure slop to me
Honestly, who cares at this point?
The slop announcements are getting more annoying than the slop.
its helpful so i dont click on it
> And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
This is a pretty constant theme in the infosec industry. The idea is that you want to do the "responsible" thing and let all the major, multi-billion-dollar companies patch first, so you form a secret club. But then, you share a very juicy, gossip-worthy thing with hundreds of people and ask them to sit on it for weeks. And guess what happens: they don't. Having worked for a big tech company, I've been involved on a couple of processes of this sort, and they all suffered leaks.
And rest assured, we'll learn nothing and try the same thing again next month or next year. Because what's the alternative? If you 0-day everyone, you get more hate mail, not less. It's all of sudden about you, not the vulnerable code. Microsoft or Cloudflare calls you irresponsible when asked for a PR statement, industry bloggers bully you, etc.
They haven't even been able to release the patch on time. Ubuntu still hasn't it
Debian has, though only for current stable (updates for oldstable and oldoldstable apparently about to drop) which might imply they had no advanced access to the update so could not pre-test and release immediately upon the coordinated announcement.
Sury is up for all versions too
Not true. I was able to `aptitude update` and `aptitude full-upgrade` before 10:00 AM EST (9:50 AM) and received the new php8.* packages and upgraded fine.
Still no update for ubuntu 20.04 which has support via ESM, even though the patch is available for php 7.4. There are a lot of people using older servers which still have ESM support.
Patches have now landed for 20.04 and other earlier Ubuntu versions. https://ubuntu.com/security/CVE-2026-109618#status
Anyone using a non-default version from the semi-official PPA by Ondrej Sury is still waiting for an update.
The launchpad server is throwing 503 errors all over the place, so that's probably the reason for the delay. Sury's own repo has the fixes all right.
I had an email from usn recently
at 15:00 UTC, spot checking, Debian 13 has a fix, Ubuntu 26.04 has a fix with their own patch version number, Fedora does not.
Ubuntu: https://ubuntu.com/security/notices/USN-8948-1
Fedora package status: https://packages.fedoraproject.org/pkgs/php/php-fpm/
PHP 8.5.4-0ubuntu1.5 (the fixed version for Ubuntu 26.04) has been downloadable for me via apt from security.ubuntu.com for about 30 minutes. Perhaps check to see that you're not using a different mirror?
You're correct, I was looking for the upstream patch number.
I heard this was leaked several days early and that’s why folks seem to be on the back foot.
I’d press go too - if something this big was known to some but not all…
We’ll all get through together
Wiz is owned by Google and Argon gets the main credits. So difficult to tell these days. But AI is obviously useful here.
Edit: was looking Wiz post when citation was from OpenAI
Of course it's useful, but you can't absolutely not leak something as big as this.
surprising it took nearly a month to acknowledge the bug
August 24, 2026: Wiz Research reports the vulnerabilities to the PHP security team.
September 21, 2026: PHP acknowledges the reports and begins developing a coordinated fix.
Took them almost 7 years even. According to the Calif write-up it was already reported in 2019 (https://bugs.php.net/bug.php?id=78876) and 2024 (https://ostif.org/php-audit-complete/).
Lol wait so OpenAI's LLM to discover this vulnerability most likely just looked it up in an old forum post?
This isn't a terribly uncommon method of 'discovery'. In maths and sciences there have been tons of papers that have highlighted something new but were never really connected to anything else and then largely forgotten. Later they are picked up by someone else and connected to a much bigger whole.
It's only one piece in the full exploit chain.
That's what my agent did to find a UAF. It just took a public one from calif off the internet and found it still flagged asan.
That's how 90+% of script kiddy -type hackings happen, isn't it. That or publically available databases without a password.
AI is gonna make our stuff pretty robust, eventually. The transition phase might hurt a bit.
The bug you posted was patched and fixed 6 years ago, and none of the other bugs in the audit showcase that issue. Are you sure these are the right links?
No way to prevent this, says only language where this regularly happens
Criticals happen in other languages all the time. You are seeing this with PHP in the news because it's used on 70% of the Internet.
Sure, but this particular vulnerability could not have happened in a language like Rust.
https://fedi.katze.sh/@elise/117479383739450605
¯ \ _ ( ツ ) _ / ¯
LOL
PHP will always be the slop before AI.
Wiz Khalif AI
So how does the exploit actually work? The best I can find is that they manage to use the corrupted generic decoder state to write a single pointer and associated PHP type information anywhere in memory, then immediately claim "this is RCE". Is that enough? From my (admittedly limited) understanding of such things, after writing code to the target memory you also need to be able to start actually running it. Or do they overwrite the PHP code (which is somewhere in memory) and then let the interpreter do its thing?
I am curious about that, too
Here was a PoC: https://jackalsyn.com/posts/php-up-2026.html
But it was withdrawn; now it says that it (CVE-2026-109618) is not an RCE and not even a CVE, apparently an addref call prevents the use-after-free. CVE-2026-109619 is still a memory safe bug, but they have no RCE for that one
Why is WordPress out of that list? Isn't it the single major PHP installation in the whole Internet across hosted and self-hosted instances?
Well, WP is just a program written in PHP.
One of the most common PHP based applications out there, therefore a good comms channel (via their forums and any mailing lists, both public and for people who have managed instances with them or are otherwise paying for support contracts) to make sure people are aware of the need to update. That would make the company one worth keeping in the loop, if only in one direction, I would have thought?
Well, it would help if WP were actually controlled by one entity, but currently it's dominated by factions and infighting.
Fair point. I thought that had died down, though for some years I've not had reason to keep particularly informed about the state of WP so I could be missing a lot of hot gossip.
They have hosted instances as well though. Not sure their market share though.
Because the CEO of Wordpress has gone insane, basically.
Automattic is on the list, tho.
WordPress is down right now. A bit late for patching though ...
I agree, WordPress should be like the first thing they point out. I'd imagine most WordPress users don't even know it runs on PHP
> https://www.php2shell.com/
Boy, do I hate these PR websites masquerading as vulnerability reports. It's slop all the way down with these companies.
I wonder how early the domain was registered and when the first certificate was issued for it, whether you could’ve had advanced notice of this by watching the DNS records
Guess what, there are answers to that question! October 14, 2026 was the date the domain got registered.
Domain registration doesn't mean that much. Many similar domains are already registered, eg python2shell.com is 5k aftermarket but js2shell.com is unregistered. Might not be a bad investment to register the .com for all the top PLs.
WizCalif.. dude xD
Do they consider this an example of a "good" response?
It’s in-line with the rest of the pho eco system.
Yet it was leaked and I can't see a single "Here's this piece of code you can run to validate the fix actually works"
It's like slop for infosec markters
Thank you, Wiz Khalifa.
Related:
Today's PHP security release, and how we're strengthening security - https://news.ycombinator.com/item?id=50182987 - Oct 2026 (114 comments)
PHP2Shell: AI uncovers critical RCE in PHP - https://news.ycombinator.com/item?id=50180836 - Oct 2026 (146 comments)
PHP session.upload_progress heap UAF (CVE-2026-109618 / -109619) - https://news.ycombinator.com/item?id=50176077 - Oct 2026 (61 comments)
Security advisory: Critical remote code execution vulnerabilities, update now - https://news.ycombinator.com/item?id=50172041 - Oct 2026 (631 comments)
Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming - https://news.ycombinator.com/item?id=50167754 - Oct 2026 (60 comments)
This is obviously bad, but in my 20 years of hosting with PHP, I've never had to take the steps of taking down servers preemptively. It's not good, but honestly, and I think the way this was handled could leave a lot to be desired, I think this might be the "worst" we've had with PHP, and it took a while to get here.
FWIW this is the most mainstream vulnerability in the new era where everyone has access to AI agents that have the potential capability to find and widely exploit the vulnerability far faster than the past timeframes for disclosure and patching.
I'm legitimately surprised half the hostnames on the internet isn't serving ClickFix or whatnot payloads already.
The average phpBB or Wordpress, even if it's behind cloudflare, probably has a direct IPv4 that's not disabled.
I think some of the issues could have been avoided here, if they would not chase the PR and blog posts.
What's the "other way" that would be better in general?
The release should've been done sooner once it was clear the embargo was broken and people figured out the vulnerability.
Some issues covered here: https://thephp.foundation/blog/2026/10/21/todays-php-securit...
More proactive outreach and better coordination with key downstreams.
Giving me log4j vibes.
Much worse. Log4j was hard to exploit and worked only in specific condions. And it was bad. This is something else.
But log4j was also extremely painful to patch, since every application bundled the vulnerabile dependency.
This is a storm, but hopefully quick to blow over with a panic frency of apt update or docker build.
The immediate exposure is faar worse here though, since its by design internet facing code.
A college enabled logging on their server as soon as they saw the news, and got dozens of attempted requests against index.php.
Turning on logging and seeing bots for the first time does not equate to novel or specifically crafted attacks. Web services get hit regularly by bots. A few dozen an hour is almost nothing for a public facing web service.
Yes, but seeing a few dozen of a new type show up within less of a day of the exploit being public is pretty mad. The usual probing is nothing special.
log4j was indeed the last time the internet storm center went to threat level yellow (as it is today again)
Thanks to OpenAI, everything is a PR stunt.
Looks like there might be a second vulnerability: https://fedi.katze.sh/@elise/117479383739450605
There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.
"The entire world should use 2x more compute" is not a real answer. You can do that on your own personal computer which has compute to spare. For servers, you're already paying for the relevant amount of compute to serve your thousands or millions of users, and every % of overhead matters at that scale. You are suggesting everyone allocates a 2x budget for server-compute, or I suppose you're only talking about hobby servers where people are running tiny workloads and had so little traffic it doesn't matter?
A tiny minority of applications use a vast majority of compute.
If 97% of programs use 2x more compute, the total amount of compute used in the world will be nearly unaffected.
Exactly, my fleet of machines is usually idling at 10% CPU or less.
Large, well-optimized services are running at high CPU utilization all the time. But there's a long, long tail of services that are running well below 100% utilization almost all or all of the time, and it's not just hobby stuff. Vulnerabilities in those services are still real and can be very important, and trading some otherwise idle CPU time for an absolute shield against memory safety issues is a good idea. Even for some services that do have high CPU utilization it may be a good trade to pay for more CPU to get that shield in this new world.
In addition to what my sibling comments have said, there is also the advantage of pushing the ecosystem to safe and fast approaches as a whole. Imagine if the default was to run C/C++ software under Fil-C, if no other measures where taken by the developers, e.g. if the consensus interpretation for one of the current security regulations (NIS2 etc.) mandated it. There would then be an enormous incentive for software to provide faster alternatives to Fil-C, as there where 2x-4x speedups for the taking!
Come to think of it, I believe it would actually be a good idea to lobby for exactly that. Memory safety issues have been a plague in IT for far too long.
2x PHP is still cheaper than Python and many other languages which most people would consider fine for your typical webapp.
Yeah I'd rather they spend 2x on compute than leak my data
Running a parallel PHP-filc deployment at such times at even 2x costs would 100% be worth it. Especially that you'd only be focusing on web-facing deployments (and not background processors).
> The entire world should use 2x more compute" is not a real answer.
Not in general no, but it is for PHP. If you cared about a 2x overhead why are you using a language with 10x overhead (conservatively)?
The patches are very dirty (thousands of `if (ZEND_HAS_OOM()) { .. return failure`); my first reaction is they've probably missed something.
People keep defending PHP (as they have been for ages) saying things like "oh, it could happen to any platform, this one's just so popular so the odds are higher" but then you take a peek at the diff for this fix and realize that nothing has changed since Fractal of Bad Design was published a decade ago. PHP is a scourge and unfortunately a still too popular one. The best time to realize the only safe option is to stop using it was in 2010, the 2nd best time is now ..
yeah anyone wise migrated away from PHP ages ago. The fact it got lipstick on back with PHP7 doesn't make it a well designed programming language. At least in my experience the vast majority of PHP websites nowadays are old abandoned PHP5 projects, which aren't much worse than just slopping a rewrite in something else
It will take time if the PHP sites have a database with a business model built on PHP. But with agentic coding, at least it is easier. I already transferred all wordpress static sites to pure html.
Extremely embarrassing for OpenAI marketing. How did they not catch this?
For now this is just one person posting about it. Can be real, can be a mistake, can be a hoax. But if it's real, then OpenAI once again fudged up really bad.
"skill check"
*rolls 3"
"Your IPO gets delayed another month"
Meow!
Edit: and it's live now 1hour 43minutes after. Edit 2x: well I spoke too soon. not actually live - the 8.4.27 tag appeared, but it's still an empty shell with no amd64 image to build from. Maybe other architectures can be built from though. Ugh. Now we're at 2hours 24minutes in. I know process steps take time/can't be rushed, and I know people mean well and surely some are unappreciated for what they do. That said: this debacle is making me want to reassess my deployment pipeline choices.
how does Docker not yet have a new, official PHP image ready, given such a big heads up? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are 52 minutes past due. (posting comment again, because the other thread i posted in was marked as dupe.)
They even committed the fixed version to the repo, but it seems no images where pushed: https://github.com/docker-library/php/commit/e3eaff845f7a9f7...
Edit: Seems like GitHub has issues with merging PRs: https://github.com/docker-library/official-images/pull/22541
Ugh these comments on GitHub. Don't people know when it's best to just post nothing? "516 hidden items"
Have you ever experienced a "Reply-all storm"?
This is not the same? Reply-all is mostly just "please unsubscribe" or "why did I get this email". Here people try to be funny and "be part of it".
It went a few seconds ago. I was also surprised they didn't have advance access but thinking about it, with the whole thing being a public Github pipeline, it's unclear how they could have achieved it whilst simultaneously keeping the patch private. Is there precedent?
they have a long process with multiple build steps before the images reach the registry.
https://github.com/docker-library/faq#an-images-source-chang...
Images are there for docker now, but pecl has decided to have issues . ARGH
I have zero internal info, just guessing, but there's a PR from 5min ago asking to add someone as a reviewer for PHP images:
https://github.com/docker-library/official-images/pull/22544
Maybe the guy that has to click OK is asleep?
Yeah, I was very surprised to wake up just now and find docker still vulnerable.
And now, at 2hrs 55mins past the PHP release, the amd64 image is available. Although it appears that the servers hosting the image are getting hugged to death because I can't actually download it.
Yepp, we're seeing the Debian images now for 8.4.27
Out now!
https://hub.docker.com/_/php/tags
EDIT: 25min later, nope.
That's placeholders for images, you can't actually pull them yet.
https://hub.docker.com/layers/library/php/8.5.12-fpm/images/...
Any eta, when they will be available?
Now they should be actually available and pullable! The only problem is that it took 3 hours with a huge security problem already exploited in the wild.
Yep. That's a real issue. We took our applications offline until now.
They are being backfilled now starting from the 8.0 images it looks like.
Ondrej might appreciate some monetary love on a day like today.
https://www.patreon.com/cw/oerdnj
Not even $700 a month? Seriously, there must be thousands of highly profitable companies depending on this guy’s maintenance. Once this is all sorted, please hassle your employers to give something back to him!
Someone tell Ondřej to sell some self-published "guide to PHP" for $200 and we can easily expense that.
Yeah this, I always see so much hate towards businesses for finding tax loopholes or not donating etc but people forget that businesses are made of individuals with their own often conflicting subgoals, but overall has to try to maximize profit so they will never voluntarily pay more tax than legal minimum or be philanthropic if they do not have to or do not benefit explicitly.
Open source projects are severely undervalued.
Oh they are very valued, in the same way your privacy is.
While we're at it, please hassle employers to donate to OpenBSD so we don't get another heartbleed
Thank you for calling this out. I absolutely rely on him so I decided to contribute $100/month even though I'm a solo dev with a business yet to see profit. But I absolutely rely on him for my server(s) PHP packages.
Similarly Remi for the RedHat-derivative side of things: https://blog.remirepo.net (he's on vacation, but apparently is pushing updates now).
There is a one time option on his github as well for those who don't want to do subscriptions.
Dude even backported the fix to his 5.6->8.0 branches
Newest: 5.6.40-104 which has the CVE fixes.
Speaking of, the PHP PPA was pretty unusable all day. I wonder, if this was just high demand or intentional attacks on launchpad servers to prolong the exploitation window.
Advisories with the details are public:
https://github.com/php/php-src/security/advisories/GHSA-w8hw...
https://github.com/php/php-src/security/advisories/GHSA-6wmf...
>PHP uses longjmp()
Well off to a good start here.
It's not exactly uncommon, it's basically C's equivalent to exceptions. It lets you avoid having to do an extra error checking branch after every fallible operation and can quite significantly speed up the happy path of a language VM.
I know but I don't think the risks justify using this, as demonstrated here. "It's fine when it's used correctly" except it's so hard to use correctly. It completely messes up any analysis of codepaths because you have this "time travel" footgun that can bypass everything.
Exceptions aren't great for that either, but languages that feature them at least have the tooling and support features to make them work. C has no destructors or anything to handle exception unwinding cleanly. Scheme has call/cc, but scheme has a big runtime and garbage collector to deal with the fallout.
Let the branch predictor do its job and implement error checking properly, I say. If performance matters so much that you worry about pipeline flushes and icache thrashing, surely you wouldn't be using PHP anyway.
setjmp, longjmp and gets are 3 function I would absolutely ban in any C codebase I would be responsible for. Maybe strncpy too. and strtok. C is fun.
> It's not exactly uncommon, it's basically C's equivalent to exceptions.
longjmp is very uncommon, I don't recall seeing any high-quality C codebase using it, and if you want exceptions, you should pick a different language because longjmp doesn't really give you comparable semantics. It's basically saying "ok, computer, f--k my s--t up".
The fact that OOM conditions are an enduring source of exploitable vulnerabilities in PHP really should give everyone a pause. Like, that's not a thing in any sane project.
> I don't recall seeing any high-quality C codebase using it
Lua does. (though it does have the option to use C++ exceptions or MSVC stack unwinding instead)
It's C's equivalent to exceptions, except without any of the stuff that might actually make exceptions safe and reasonable to use in other languages.
There's no automatic cleanup of anything, no built-in way to even register things for manual cleanup, and it doesn't even consistently save/restore the values of your local variables. A local variable that was mutated between the setjmp and longjmp may end up with the old value or the new value depending on where the compiler decided to store it. The documentation does mention this and says that you need to use the volatile keyword to avoid it, but in typical C fashion there's nothing to enforce this, it's just up to the programmer to remember it.
It is extremely uncommon in C codebases because it is extremely dangerous. It makes hazards like pointer arithmetic and manually-terminated strings look like a walk in the park by comparison.
Not that uncommon for a language interpreter? Pretty sure MicroPython does some setjmp/longjmp for non-local returns.
Never use Ruby then.
Ruby even uses goto!
Lua as well
did I skim this correctly that with the mitigation shared this does not (yet) impact fpm-usage and classic CGI (vs. mod_php) is not impacted either?
No, every platform affected.
> Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
https://www.php.net/archive/2026.php#2026-10-21-5
I'm surprised by CGI. The vulnerability description talks about a second request being affected by corrupted state from an earlier request. But I thought CGI only processes one request per process?
Iirc one of the main performance tricks for CGI was to get processes to stay alive.
But there were two vulns - only the second required the two requests.
Despite this coordination, WP-Engine (who's major business is hosting WordPress sites) is still on PHP 8.4.26 a full 2.5 hours after the patch is publicly available.
https://wpenginestatus.com/incidents/969801
Could be backported?
I'm checking by ssh'ing into my environment, and this is what I see as of 21:41 UTC, several hours after the patches were published:
I keep hoping for either a change in the version or the build date, but nothing yet. The incident status page says they're deploying, but there haven't been further updates about how far along they are.It took 8 hours for CloudWays (DigitalOcean) to apply the patch. Big companies suck at responding to major stuff like this.
They also have more to coordinate and manage. I don’t think it’s fair to frame it as them being bad at something. What they have to do is much harder, and it takes time.
When I’ve worked at small places, a security patch is bumping some versions and restating some servers.
I worked at a massive Rails shop for a decade and a big security bump meant mobilizing a team, coordinating updating dozens or hundreds of apps, all while maintaining platform stability and staying within SLAs. It’s a nightmare.
We have 4 servers with CloudWays. 2 of them are still not patched (20 hours since the patch was released). We cannot control the PHP version for our customers. Sucks to suck.
Someone is saying there is a new vulnerability that works on the newest 8.5.12 https://x.com/_annieversary/status/2112933589943742598
That partial stack trace linked above seems to match this GitHub issue, which has much more information: https://github.com/php/php-src/issues/24488 (double-free introduced in 8.5.12)
From what I can see, this causes a crash only, and isn't weaponisable. It's a use-after-free, but the reclaim window is zero by construction.
This is false. Elise says:
11:12 UTC: “ERROR: AddressSanitizer: attempting double-free" from php 8.4.25”
11:44 UTC: “confirmed working on 8.5.10 too”
Thats before the 8.5.12 issue.
Mr. President...
... a second feline has hit the stack.
Is there anywhere good to get some sort of reliable stream of information about this possibility?
It's going to be pretty bad if we all panic to get the latest PHP up, and all confidently roll out our updated websites, just for them to still be vulnerable to something serious anyhow.
This is why I like to have a minimum age requirement on package releases. Something like at least 2 or 3 days.
To be clear they said it “still works” and “ ok thinking more about this, there's no way this is the same vuln, this is another one.”
Meaning this specific bug the parent comment is talking about is not new in just these patched versions from today.
So delaying your updates today would mean you’re exposed to an actively exploited RCE and still exposed to the other memory corruption bug (which may or may not be an easily exploitable RCE) for an entire 2 or 3 days.
And from the sounds of it people are very actively exploiting this so waiting 24+ hours will practically ensure you’re hit.
lol this is the exact scenario where that’s an well idea. Maybe the patch is bad, but not patching for 2 days means your guarantees to be hit by the original issue
We are damned if we don’t and (often times) damned if we do
Anymore on this, I'm upgrading to 8.5.12 now and don't want to still be vulnerable?
Click the associated tag:
> This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Glorious. Today of all days it would genuinely give me pause for caution.
edit: yeah, really not feeling that: https://github.com/php/php-src/compare/php-8.2.34..php-8.2.3...
Hopefully just a mistake? But looks like a botched release at the least
Same on the older few. I'm not sure I understand it though, seems strange you can have a tag for a commit that's only present in a fork?
Is it perhaps a bit misleading, and only means that there's no branch containing that commit?
There is little difference between a tag and a branch in git. There is just the convention that tags reference the same commit forever, while branches move.
On github forks are part of the same physical repository. You could imagine that each logical repository is just a namespace for branches and tags, backed by the same physical repository.
I do consider the warning a bug if github, it should check both tags and branches for commits which are to be considered part of a logical repository.
Git doesn't have a concept of "fork".
GitHub uses this metaphor, and, as another commenter already aptly described, it could be nothing more than a fancy name for namespaced branches, on the server side.
On the client side, "forks" are usually different repository clones with different remotes and a "coincidentally" shared history.
But you can also map forked repos to multiple remotes of the same repository for example, instead of folders.
Assuming that forks would live in separate clones/blobs on the server is not really based on anything, so I think the warning is a good middle ground between explaining what forks are and how they handle them, and giving actionable advice.
It's also better suited for PR:
"Fork me on GitHub"
vs
"Branch and push your own clone on GitHub, using our shared blob optimizations".
I think the warning is clear and there's nothing misleading about it, but others have already pointed this out and git can be tricky.
It's so good at providing the right level of abstraction to everyone though, it seems!
Similarly, GitHub invented the term "Pull Request" (aka PR, lol).
Not a git-owned term.
But "merge request" isn't a Git primitive either!
And, with Forks and Pull Requesrs, GitHub made a particular workflow in Git approachable to anyone!
I love GitLab, but people get confused by Merges, myself included, so the GH-enabled workflow of favoring ff-only merges, without merge commits, with quadi-linear history, became the norm and helped Git succceed!
But I also appreciate being able to do all kinds of different workflows.
So PRs were positive-sum PR at the time, I'd say. When they became popular, I was still taught Subversion and CVS at uni, alongside Git as "the new thing". Ar that time, many people considered the older systems simpler, and pondered SVN as the most reasonable middle ground between CVS and the decentralized concept of Git!
It can mean either, it's a consequence of how github optimized their backend storage so a 100 forks of a repo initially take up the same space as 0 forks
main (or master) is just another branch to git.
Correct. ..did you mean to reply elsewhere perhaps?
Yes sorry, missed the reply link
> 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.
If only we could come up with a way to manage memory automatically. Alas, one can only dream.
I'm pretty sure this class of problem would exist in GC'd environments too unless they're configured to abort on OOM, in which case you'd still be dealing with denial-of-service.
In some environments OOM is a trappable exception, so it's possible that incorrectly authored code would trap the OOM and 'recover' with partially initialized data sitting on the heap. Hopefully it's a memory-safe language so that partially initialized data isn't RCE...
If LLM's are going to keep finding vulnerabilities of this magnitude, we'll be sure to face a computer worm event of unprecedented scale soon. Best be ready for the moment the lights turn off
Just pulled the new matomo that was published on dockerhub 26 minutes ago, thinking it has the patched PHP version:
The PHP build is from today, which is doubly misleading. 8.4.27 is the patched release, not 8.4.26. I wonder how many people will pull this image thinking they're good to go online again.The "official" PHP Docker images turned out to be a shit show tody. Seems like many maintainers fell for it and published updates that aren't really updates.
I'm currently waiting for a new docker image for another project, and their maintainer noticed the old PHP versions in the freshly built images and is still waiting or working on releasing a new container build.
There is nothing official about these images.
"Let's use this packaging some rando on the Internet built" is a strategy that is exactly as good as it seems, but that's the Docker ecosystem for you.
Packagers who actually understand the software put in good work to package that software in small and well maintained packages. Use them instead!
Yeah, took me long enough to learn that. I just trusted the "official" badge.
Fully agree. Moved to FrankenPHP's static build (which was ready very quickly) to get away from it. Don't intend to ever use the "official" images again.
I'm wondering if it's not just better to use plain Debian base images.
This will take longer on a cold build cache, and pins the PHP version to the current Debian version. But Debian once again proved very reliable to patch in time.Those images are not even official. "Official" is just a misnomer in Docker.
If you need Docker to run PHP software you're beyond any help already.
Yeah, I really enjoyed messing with php.ini back in the day! Setting it juuuust right for every different project on my dear pet.
I barely use PHP these days, but Docker seems like a great place to put it.
Same goes for Wordpress indeed, which I'm waiting for.
I guess they were planning an update for today, for a moment the 8.2.35 threw me, but .35 is patched on 8.2, unpatched on 8.3 :)I had to build and deploy my own Nextcloud images earlier today. :( Not a big deal because docker, just obnoxious that this got released into the wild and was being actively exploited before patches were available everywhere.
https://ubuntu.com/security/CVE-2026-109618#status fixes have been back ported in Ubuntu LTS versions just now.
Some have, but others are still showing "needs evaluation", and still no update for 20.04. I've just turned off php for now, as we only used it in a couple of places and won't be missed for a day or two.
Patches have now landed for 20.04 and other earlier Ubuntu versions.
FML. Can't get in to update our servers because of MFA and our director, who gets the codes, isn't in
Great example of performative enterprise security practice that contributes to degraded security posture, I suppose. Best of luck.
What would happen if the director suddenly gets sick or decide not to come to work anymore? A lot of people assume that humans are reliable, they are not.
Exactly: limiting access is fine, lack of contingencies is not.
Some systems and services still only allow for one owner though (I'm not going to name names), which can be a big problem when MFA is mandated. From what the poster I responded to said, I'd be very surprised if that were the case for them though - just slightly daft policy.
This is where tooling like 1Password or Apple Keychain that lets you "share" MFA comes into play.
It doesn't allow sharing SMS, email or proprietary app based MFA.
Email is painfully easy to share. SMS may take some tricks (again, iMessage can be useful here).
Proprietary apps are a pita.
One of my first boss called it the bus factor, not sure where the term comes from. What's the minimum number that need to get hit by a bus before it's impossible to keep things running. He used to say "you always have some bus factor, but it should never be one unless you're alone, otherwise you deserve whatever crap is going to rain on you someday".
I've found that to be incredibly true in my career.
If you're optimistic you call it the "vacation or lottery" factor - if Bob wins the lottery tonight, will our shit still work tomorrow?
And if the answer is no, well, then Bob just got Hotel California'd and can check out but can never leave.
Help Bob; help yourself.
https://en.wikipedia.org/wiki/Bus_factor
We call it the HB3 (Hit By Bus Binder). Aka keep a document containing what to do if someone of your team gets hit by a bus.
My team rotates 1 sacrificial member every week to be on call with prod k8s access. It limits who can just push things to prod at any given time while making sure everyone on the team has experience. If someone is out sick or on vacation we do time trading, it works out for everyone.
Have lived this when a seeming healthy mid-30s man dropped dead. Nightmare.
Implemented a lot of “just in case” policies after that, which seemed obvious but oh well.
Yeah, it happens.
I was fire-wardening at a carol service about 15 years ago (think ~850 year old gothic stone church with thousands of candles spread around on every available flat surface - looked amazing, potentially catastrophic).
I was sat near the back with a bucket of sand under my seat, and a guy sat in the middle of the row just across the aisle from me, who would have been around 40 or so, had a heart attack and died.
No warning, no history, just gone, and leaving a fairly young family behind. It was honestly shocking.
Use the exploit to gain access, then upgrade
Let's hope he didn't go skydiving. Seriously, you need to improve your processes.
where do you work? >:)
With AI agents, I've been using sites/services that are bot friendly and don't require MFA.
Not everything needs hyper security. Heck, I've given AI access to spend money on websites and my only restriction is that the websites limit the daily spend(website side... Although I guess a rogue AI could have changed it... )
So far Ubuntu LTS isn’t picking up the new packages for me via apt update, and Laravel Forge appears completely unresponsive as a result of being flooded by people trying to update their servers.
And I'm maintaining a box on 18.04 over here, and lo and behold its Pro subscription isn't showing up as active, so I couldn't get the update even if they do release it.
Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)
In-place! Sporty! Good luck! :-)
Same, I'm spamming the apt update and so far nothing on 22.04 or 24.04 lts
I realised that my linode and ovh vm's point at local mirrors not direct to ubuntu, I guess that's why the delay
Yeah, Linode still hasn't updated their mirror. Vultr has though.
Edit: Linode just updated its mirror.
I'm finally getting Ubuntu updates now (both on 22.04 and 26.04 that I've tested so far -- edit: 24.04 as well confirmed).
They had plenty of time to prepare for the release, what a shit show
Does anyone know how long it takes for the ondrej/php repo to be patched usually?
I installed the updates 18 minutes ago, they're live.
Definitely not available yet, launchpad says last builds are from 2026-10-12
use packages.sury.org instead
follow https://packages.sury.org/php/README.txt
Sury's own website and launchpad description are really misleading as to what to use, thanks for pointing to it
They were because I installed them
Ondrej has already said "deb.sury.org will carry packages as they are built".
https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecom...
You can see them building here, it looks like most should be ready within the next few minutes:
https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
how does Docker not yet have a new, official PHP image ready, given such a big heads up? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are 27 minutes past due.
Yes, it's embarrassing for Docker. Makes me wish I still had the classic LAMP stack.
A PR was posted within a minute or two of PHP's source code update. Then within a minute of the PR's CI job completing, it was merged, and the build took a while but is now complete: https://github.com/docker-library/php/actions/runs/396158697...
It would not be easy (or reasonable) to take a public build like that private to build a 'secret' image version, and I'm not sure GitHub even has the capability to do that. I would not trust a build pushed to Docker Hub separate from the established / public / auditable process they have in place.
This is just the first step. See here for the full process: https://github.com/docker-library/faq#an-images-source-chang...
All dependent (official) images need to go through the same process, so that makes it fairly problematic, and I think Docker needs to take a look at it for the future.
Ah, indeed... I thought the GA push was the final step but there's another manual process between that and updating the Docker Hub image tags: https://github.com/docker-library/official-images/pull/22541
It should definitely have a 'high impact' workflow that bypasses some of those manual steps.
It would however be reasonable to expect a maintainer to be available to start the CI faster than 30 minutes after the PR was created.
The maintainer isn't getting paid enough to react with that much speed.
Docker have been carrying a broken python build for months.
they are wanting people to pay for the hardened version.
Does anyone know the ETA on the official php:* docker images? I think they only released patched 8.6 RC containers for now.
The PR with the update is here: https://github.com/docker-library/php/pull/1694
Looks like we need to be patient:
> Why is this not merged yet?
> I'm not a maintainer and can not merge this. Please wait until a maintainer has come around to look into this.
> This is merged, but I cannot find the image?
> After this PR has been merged, more steps are to be taken, including an upstream merge on docker-library/official-images and subsequent image builds. For a full description of the timeline, please refer to docker-library/faq#an-images-source-changed-in-git-now-what.
This issue with the "official" Docker images is the reason why (when I was still at SUSE) we switched to pushing releases ourselves to our own project and then eventually to our own registry.
This push for centralisation without the infrastructure to back it up has always been the most frustrating aspect of Docker Inc over the past >10 years I've worked on container runtimes.
one of the more entertaining PRs I've seen
Enough spam comments to create a huge blacklist of misbehaving github users.
Might have to wait for the github outage to be resolved first :D https://www.githubstatus.com/
How about the Ondrej PPA repos for Ubuntu?
They're updated for all versions
Has there yet been any signs of any service actually being successfully hacked due to the vulnerability?
I'd expect agents to be hacking hundreds of thousands of websites as we speak.
They'll of course install a backdoor and patch the exploit so others can't come in. They won't deface the website, so there won't be signs.
Watchtowr reports yes, but doesn't say where exactly right now: https://watchtowr.com/intelligence/php-cve-2026-109618-faq/#...
Well they did specify "successfully." EITW is a pretty broad tag, just means attacker are probing servers. I'm not saying it's good but there are usually some pretty big caveats with remote-remote memory corruption, don't know if all the people dooming are aware of that
> Exploit portability and reliability depend on the PHP build, extensions, frontend behavior and allocator layout.
This is the real question here. So much panic right now.
i just took down all my PHP sites for the last few hours. they’re proxied behind Cloudflare so i know there were mitigations, but infrastructure can’t be breached if it isn’t running!
Similar here, except I didn't want to actually shut down the servers, because then I can't patch them! My solution was to just turn off Nginx, which prevents anything from reaching PHP. Then I stuck a caddy server with a temporary config so we get actual 503 maintenance responses.
It seemed to be helpful for others too so I packaged it up, should work on most Nginx / Certbot servers. hopefully its useful: https://github.com/Indemnity83/popcorn
If you're using Nginx why not just stop php-fpm? Then static parts still work and you can have whatever error response you want from Nginx.
Now I need to get the cute name for a vm vulnerability that attacks offline servers ...
awake2death or something
I once wrote a PoC for reading data off of a dead Open Compute Grand Canyon server that wouldn't boot by sneaking it off of the HDDs through a sideband through the BMC. Never say never.
>Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
Hard to deploy if you also install extensions from PECL right now (probably slammed).
same here.
`[00:06:03.209] pecl install -f amqp igbinary redis imagick` :sad_face:
Yeah I got repeated error for igbinary (and then find out I didn't use redis in this project and could remove it).
yeah, not surprising but not great
switch to PIE
Is Pie (which I learned about it today) a painless migration from PECL?
My only experience is within Docker images, but yes. Replace the pecl call with the equivalent pie call and you are done.
Disclosure: I'm a PHP core team member and also contributed some code to PIE.
6 lines of dockerfile changed for me, no issue.
Interview with two of the discoverers: Breaking Down PHP2Shell with Sagi Tzadik (Wiz) & Thai Duong (Calif)
https://www.youtube.com/watch?v=lfEtbrz4-zY
Still no release for Ubuntu... They are already half an hour late. Debian got the patch almost immediately...
The builds are there: https://launchpad.net/ubuntu/+source/php8.5/8.5.9-0ubuntu2.1
https://launchpad.net/ubuntu/+source/php8.3/8.3.6-0ubuntu0.2...
https://launchpad.net/ubuntu/+source/php8.1/8.1.2-1ubuntu2.2...
but nothing shipped yet by their mirrors, unlike debian.
even the security.ubuntu.com mirror doesn't have it yet
Now they have finally shipped it.
Ubuntu probably started working on a rust based replacement instead: rphp.
Why are they so slow. My Archlinux is already updated, but I still have to wait because of this.
curl -fsSL https://packages.sury.org/php/README.txt | bash
This adds Ondřej Surý's PPA to your system so you can upgrade the packages.
Just make sure to have the ca-certificates fixes already...
Why do people still use Ubuntu?
They gave away CDs 20 years ago for free. Cooool.
Fedora is best for desktop.
Debian for servers that never need updates (but I even use Fedora for server now adays)
Desktops don't need updates either ;)
Debian on the desktop is the best computer decision I ever made
if it makes you feel any better, the official dockerhub images aren't ready yet either.
They had almost a full day to prepare for this...
I'm starting to suspect that they actually got the notice the same time we did, because if they got the patches there should be no reason it wasn't already built and ready to go (unless they're scared that "our build servers are public and everyone will know" so they literally held everything off until the release which seems so counterproductive as to be ... well, open-source silliness).
If you mean docker official images, it's just the "community" maintaining it, eg "some dudes". By no means should you consider it a mechanism to get timely security updates, I've seen horrible lag on that before.
Most of docker is like this. Images provided by volunteers, and not related to the project. Using docker images you don't maintain yourself, and at least don't upgrade yourself, is not the best recipe for security.
(It's pretty trivial to build your own)
> If you mean docker official images, it's just the "community" maintaining it, eg "some dudes".
This is false. The Docker Official Images team (i.e. the folks with write access to the docker-library/* organization) are Docker employees.
"Official" docker images are maintained by "The Docker Community", not by the company. It literally says so on the php "official" image.
I wasn't aware of that. So I guess it's generally better to just use plain debian images and just install the required packages with apt.
There are different approaches and it all comes down to who you trust. I don't think there's universal answer. If you have money, find image provider who's serious about security and hopefully they'll provide patches images quickly. Otherwise using Debian packages is a good default I think.
Honestly I don't even understand why so many docker images prefer to build software from sources, rather than just installing them from debian repositories.
> I don't even understand why so many docker images prefer to build software from sources, rather than just installing them from debian repositories
Because Debian uses older relases and a lot of custom patches. One example: Nodejs still doesn't have Typescript support in the Debian packages.
Distribution packages vs. official build from source has both pros and cons.
And if you're using a docker package it's often JUST BECAUSE the host Debian/Ubuntu server is out of date for things you need, and Docker's the easiest way to "patch" that.
welp, I guess I should have done my research into what "docker official images" actually means.
Debian has had the patch for days, as have other main distros, and tested and prepared the release. That's why it was instant.
Unclear why Ubuntu is lagging.
Apparently about 40% of PHP apps are still on PHP 7 and 5...
There are rare occasions when circumstances are more important than preserving an "EOL" designation. This appears to be one of those times where "official" centralized patches really should be made available for at least PHP5.6 and PHP7.4, and perhaps even 5.5 and all of 7.x. They're not covering themselves in glory by refusing.
Yes and in general lots of users being on unsupported releases should also cause som reflection why that is. E.g. maybe support periods are too short or there are too many breaking changes with new releases.
It looksl ike they released official patches at least for 7.4 though:
> Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
https://github.com/php/php-src/tree/PHP-7.4-CVE-2026-109618-...
That's going to give a lot of people a moment of reflection about whether or not they want to continue using PHP.
Yes and no, you have two setup, you're on LTS, it will be backported (done as I write than on Debian), not on LTS and you already have hundreds of unsafe stuff running anyway so it's just one more to the pile.
I would think most people that are stuck on EOL PHP probably don't have a choice
Yeah, I have a legacy site that is popular and doesn't make money with some outdated version of PHP that will not update. Maybe I need to install OpenClaw on it.
But yeah, with AI agents, I don't really understand the purpose anymore. Legacy WordPress or laravel sites?
If those place at using a LTS release of their OSes they will be patched quickly (Debian already has). If they're not, they're already screwed by a lot more than just PHP I guess.
Those websites can easily run in a php5 container, whilst the host os is up to date.
Websites depending on an older framework like Zend Framework or libraries like Doctrine 1 do not have a clear upgrade path and are stuck at php5 or have to basically start from scratch. php5 to the latest php8 is just a jump too big.
I see Debian has packages.
5.6.40-104+0~20261021.134+debian12~1.gbp7401dd
7.4.33-31+0~20261021.121+debian12~1.gbpe9c428
Sury released backports for older versions, as always hes incredibly reliable.
CISA published an advisory half an hour ago:
https://www.cisa.gov/news-events/alerts/2026/10/21/critical-...
And there were people who thought Project Glasswing was a stunt.
Why is the description of "RCE via OOM corruption" mentioning all these settings like memory_limit, post_max_size, max_input_nesting_level etc under "Mitigation" but not blocking multipart requests? Isn't that a solution?
The description of the vurnurability "Several multipart parsing problems" makes it sound like it is?
No, it’s not a solution, it’s only one example proof of concept on how to exploit the vulnerability, there are more.
I blocked multipart uploads in addition to adjusting post_max_size, etc
blog that was helpful to me: https://www.vincentschmalbach.com/cve-2026-109618-and-cve-20...
Does anybody know when Amazon Linux 2023 will get this release?
Thread here: https://github.com/amazonlinux/amazon-linux-2023/issues/1148
Is there some reason the biggest company on earth who likely had advanced notice of this cannot put out a patch?
Yeah, really disappointing that they are so slow here, compared to open source maintainers and volunteers.
PPA packages on LaunchPad being built here: https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
Versions: 8.2.35 8.3.36 8.4.27 8.5.12
Now are available in the php-src github
can't find it.
Check the tags:
https://github.com/php/php-src/tags
I was under the impression that this sort of bug is fairly common in both php and common php frameworks?
I thought the real lesson was "assume your web server is compromised if you use php, and try to make sure php doesn't touch anything too critical"
I'm struggling to see any reason to use PHP in the first place if it can run without access to private data.
At that point I would not need a backend.
Yes, there have been decades of talk about this already—ensuring you isolate/jail the PHP-related processes and run them with an unprivileged user, etc.
It's usually scripts that can write to /tmp and run unrelated stuff with web user rights. This seems more involved.
Why is the official source (php.net) marked as [dupe] https://news.ycombinator.com/item?id=50180943
and not the github mirror?
Looks like the docker images are struggling in the Jenkins queue: https://doi-janky.infosiftr.net/
If open source has these vulnerabilities, imagine proprietary ones.
I've created patched Dockerfiles for EOL PHP versions. The patch is obtained from official source trees.
I've also published the built images from them to GitHub Registry, but of course it's best to inspect any public repo/docker image before using them blindly.
https://github.com/a-nych/php-eol-backports
One can inspect a GitHub repo sure but how can one usefully inspect a docker image provided by someone on the internet?
Usually by extracting the layers and looking through them. There's dive (https://github.com/wagoodman/dive) for making that easier.
I fail to see how that’s useful. Why would I care about the layers inside an image when I could just extract the entire filesystem inside. Even then it is not useful if we don’t have a culture of reproducible builds.
Fair, "inspect the image" was a bad way to put it.
What I meant was: don't trust prebuilt images from a stranger, including mine. I've provided them just as a convenience, the Dockerfiles and patches can be easily looked-through, and building them yourself is the safer option if you need these docker images.
Great that its out but if you depend on pecl for additional extensions and need to rebuild docker container it will probably fail because pecl is having issues for last few hours[1].
[1] https://status.php.net/
It says pecl.php.net recovered but downloading source for extensions ends up with 504 most of the time.
My hosting provider just informed me that they took down my website over this to "protect" me. It's a static website that does not use any php. But it's a generic LAMP hosting provider so they just took down all their hosted websites. I had it on my to do list to migrate that to cloudflare anyway. So, I guess I'll be doing that soonish now.
When every neighbour decides to leave their doors unlocked simultaneously,and the entire world knows it, maybe barricading the village is protecting you
who is your hosting provider ??
apt-get update + apt-get upgrade fixes it on Debian, but not on Ubuntu for now
Add Sury's repo and update from there: https://packages.sury.org/php/README.txt
You can on ubuntu change to use ondrej/php and update now
I've been trying to update my (noble 24.04) server and an apt update is not showing the 8.5.12. It looks like the binary has been built but not updated in the index http://ppa.launchpad.net/ondrej/php/ubuntu/dists/noble/Relea... (last update 14 yet. https://launchpad.net/~ondrej/+archive/ubuntu/php/+build/338... suggests it finished at ~ 17:00 UTC
Though quite possibly I'm missing something ;)
---------------
edit: as I was typing the index was updated. So, as far as I can tell only just now (18:20 UTC) was it available for updating!
https://github.com/php/php-src/commit/01a40e89fbfc499936e3b0...
What everyone is looking for.
Gosh. Let's hope they didn't miss a place.
What an absolute unit of a security patch. What's the chance that this was sufficiently reviewed and doesn't add new vulnerabilities?
Really makes me appreciate using language with exceptions and not that crazy "manually check if error handling is required - and do it everywhere". The fix adds:
all over the codebase.It says "3 days ago". The tag is 2 days old.
I assume it just got pushed?
Yeah… it was patched in the source 3 days ago. Check the linked GHSA.
debian trixie just rolled updates.
Debian always seems to be the grown-ups. I'm a Linux novice so I couldn't get Nvidia drivers working on it but that's the only reason it's not running on my desktops.
Can confirm. Just updated to fixed version
when's bookwarm coming?
packages are building:
https://buildd.debian.org/status/package.php?p=php8.2&suite=...
Already, including backports to 7 and 5.
Is there a curl command I can use to test if the vulnerability is fully patched on a server (not merely mitigated) without causing any harm?
Note I want it to work with the backports too, not just the latest version.
Gentoo has it updated.
While the patches are being merged for the official docker images, perfect time for a github outage! https://downdetector.com/status/github/
Code example for the exploits https://github.com/david-alvarez-rosa/php-rce
Available for Trixie :) (https://lists.debian.org/debian-security-announce/2026/msg00...)
Have we ever seen the "get ready for a security release tomorrow" email before?
https://www.php.net/archive/2026.php#2026-10-20-1
Yes, it's pretty common with large open source projects in the server space. Makes sense when releasing a fix also means releasing information that will let others exploit the bug so users need to be prepared to install the update quickly or take other measures to protect themselves.
Many vendors do it, but on a set schedule "patch Tuesday" and some will release vague "mitigation steps" but honestly those usually come with the patch.
They have to backport this fix or else leave a large part of the internet broken.
Trying to install this update but it appears that Launchpad doesn’t have the bandwidth for half the world to all update at the same time.
I’m not especially technical, but I have clients with WordPress websites. Can anyone perhaps put in a sentence or two what I need to suggest they do?
Tell them to take anything with PHP offline, so that it isn't available from the public internet. That is how Netcup and Contabo are handling Wordpress hosting until they've upgraded all affected packages.
There are already functional exploit scripts on GitHub, you can target any Wordpress site right now.
Shut the sites down until you are able to update to the latest PHP patch for your version.
You need to update the PHP version, which is usually done by the hosting provider.
Just a note to say thank you to all of the above commenters, appreciated
A bit too early for the announced coordinated release, no?
Their earlier comment said
> We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.
https://www.php.net/archive/2026.php#2026-10-20-1
Good point, at least now Debian has shipped the patched packages.
Two minutes before the announced 1400UTC? Or have I forgotten how to math?
More like >10min early. It's close, but given today’s speed of agents..
Question: is the 7.4 patch sufficient (the one after 7.4.33 that we have to build from source?)
Seems like they finally decided to release it after so many people had access. What happened to security as a priority.
So this only affects 8.2 are other patches coming?
https://www.php.net/archive/2026.php#2026-10-21-5
> 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.
Earlier versions are not fixed by PHP official and need vendor patching where available
exactly why I asked, because those builds for 8.5.12 are not available yet
How does this not have a CVSS of 10?
Anyone know if Microsoft updates azure web-app built-in php runtimes fairly quickly in this sort of scenario?
Looks like the upgrade instructions for PHP 8.3 for Fedora 39 and earlier are not working ... yikes.
The best time to code away from PHP was 20 years ago. The next best time is now.
Or just patch and keep enjoying fast, convenient, accessible, flexible PHP?
Any signs of exploits out yet?
Is PHP 7 essentially going to be dead and unusable for everyone then? Or will it get fixes?
> Given the severity of these vulnerabilities, the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor.
PHP 7 hasn’t received an update since 2022 when it went EOL.
EDIT: looks like there are backports though
There are backports already.
https://github.com/Niek/php7
Debian has a new build of 7.4 at least.
Not out on Ubuntu 20.04 yet, but sometimes they are a little slower. Hopefully should be posted later today.
So they've added malloc fail checks and tests for malloc fail throughout.
Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?
PHP is tracking its own memory usage internally with limits configurable via php.ini.
Time to restart Apache again!
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests." -Rasmus Lerdorf
Amusingly enough restarting php after each request seems to block the issue
If true then classic CGI mode should not be vulnerable, but apparently it is.
Is it? How? Yes, you can get longjmp to do invalid things, but with an ASLR reset each attempt, can you exploit it?
Not sure how, but from the announcement: Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.
Maybe just CYA.
Also, CGI PHP skips request cleanup on init failure.
I'm 90% sure CGI can't be exploited this way in default configuration with ASLR and 99% sure if PHP is configured with memory_limit=-1
That said, don't be an idiot and switch to CGI instead of patching. I'm like one of three guys running PHP in CGI mode and I'm vaguely satisfied I have the most resistant configuration.
The reason, BTW, I run PHP in CGI mode is so I can (moral equivalent of) suexec to a locked-down sandboxed environment that limits exploit blast radius. I could do the same with fcgi daemon, but the suexec is stateless, and roundcube doesn't need the performance.
In general, anything stateful or long-lived is just one more thing that can go wrong. One reason why the trend of turning everything into a persistent daemon drives me nuts.
PHP runs literally half the web. Half the web will not apply this patch in any reasonable amount of time (a huge portion will never). This is going to be absolutely catastrophic.
The union of hosters which will not update to this patch, and users who have not updated to the past 283762 CVE is literally the same circle. I think that maybe a couple new not infected machines will get infected with a cryptominer - the rest will just get one new miner fighting for resources
> the rest will just get one new miner fighting for resources
Hehe. That's funny.
I can imagine a truce, either on machines ('ok, you take that one') or on cores ('16/8, deal?')
They should probably invent some sort of Crypto Miner Communication Protocol (CMPC) that will make the process easier for all miners out there. Let's hope most are not bad actor crypto miners who ignore the protocol though, we should strive for more good actor crypto miners.
What should be done? Can beneficent governments race to hack and patch servers?
So if I wanted to build a botnet, then it would be very easy ;).
Infiltrate vulnerable PHP sites. Install backdoor(s). Secure root access. Patch PHP to lock out script kiddies. Let it sit dormant until you need to launch attack
Indeed this is undoubtedly happening as we speak to untold millions of forgotten sites.
So many scanners scan for various wordpress sites, if they save their results then they can more-or-less immediately build huge botnets.
PHP 8.3.36 (cli) (built: Oct 21 2026 08:18:34) (NTS)
made it in time hopefully
This reminds me of the old days when PHP was such a vulnerable language.
By simply searching for websites that used local includes to load other pages, you could get RCE.
At this point, running webapps in JS workers/sandboxes sounds like a good idea. Vendors take care of patching.
Have a search for V8 RCE/CVEs over the past year.
That's why I mentioned vendors. They patch it before announcements.
Also, sandboxing makes automatic exploitation harder. There is no FS persistence, so some checks simply do not pass.
Anyone know when amazon linux 2023 is releasing updates?
Seems like 4chan is down for maintenance as a result.
there is clearly some drama w.r.t. who takes credit here, 3 companies credited for a single flaw is super odd.
I think there's a lot to learn from the last twenty four hour's events. An absolute nuclear bomb of an exploit affecting every version of PHP back to 2012 (which nobody should be using of course, but I've worked in plenty of environments that are not up to date).
The thing that's annoyed me the most is the speculation and misinformation, filling in the gaps. Folks looked into the php-src and figured out one of the vulnerabilities, starting saying you should disable certain php settings and then core PHP developers on obscure mailing lists hinting this isn't enough.
Given how inexpensive it is for agents to scan popular OSS projects, disclosure needs to be more discrete and you cannot publish fixes to OSS before disclosure. People will be and are watching for this kind of thing already.
While the fix was not published I genuinely thought a quick service rewrite to some other stack (say Go) would make sense as a fix. (Assuming high integration test coverage )
Is this why Wikipedia isn't working?
en.wikipedia.org works for me
This is pure gold. A critical vuln like this is such classic lolphp. Luckily you can port away from PHP pretty easily with AI.
...and If you have a server in a closet still running PHP 5 or 7, hosting that project you’ll rewrite “next quarter,” this might buy you some time: https://github.com/analogic/phpsafepass
Doing a...
... every now and then until that 8.3.35 turns into 8.3.36.So far, no dice.
I'll give a shoutout to Lithium Hosting. I was able to log in and update my PHP Pool per their custom control panel and switch all of my sites over to the latest fix: 8.5.12.
For those who can’t patch their PHP for a variety of reasons right now, here is a proxy I developed that can sit between nginx or apache and your PHP-FPM, to sanitize inputs and prevent this (and other) attacks:
https://github.com/Qbix/proxy
Thanks for the inspiration! I've stripped down your code and made https://github.com/analogic/phpsafepass which is mostly just filter for fpm
Love it! Finally somebody gets it.
I got downvoted heavily by other HNers for merely offering a solution to protect people’s legacy PHP servers. They said it should be deleted and “not worth working on”. The solution was free and open source but these downvoters commented as if it was worse than having your server PWNED. I still don’t understand why.
Well, HN is far from representative of the real world.
I have this slight suspicion this was not the last critical PHP apocalypse ... :(
Some web-services are back up again here in central Europe, but some are not, which is very annoying. Kind of surprising to see how much PHP is actually used. Hate it or love it, PHP really is very important still - lots of the web depends on it.
> 8.1 and earlier Not patched: these versions have reached end of life and will not receive an official fix
I would not recommend using PHP. The PHP team keeps breaking backward compatibility and trying to introduce new features instead of focusing on fixing bugs and hardening the compiler.
Do any home router login pages use PHP?
Pretty sure they do yes.
Log4J4PHP
Sucks to be you if you're not on PHP 8 :|
Every year, several of my clients say "We will upgrade next year"
Why they can't publish an expoit so people can run it against their own servers to check the impact?
What I've been feeling lately is that security vulnerabilities will inevitably keep being discovered, and I worry whether humans can ever patch all of them.
where is patch for alpine?
They bundled the fixes with a regular bugfix release, looks like.
Yeah, there was a new patch release in the works already. They just added this fix and got it out the door. Changelog: https://www.php.net/ChangeLog-8.php#8.5.12
This is extremely damning for Cloudflare. I had a bunch of clients telling me Cloudflare is all they need to prevent this, and they want to get that on their site instead of upgrading PHP.
I have not seen confirmation Cloudflare is doing anything except playing whack a mole with certain request patterns. PHP Core Devs have been clear you need to upgrade. If this is true, it's disgustingly opportunistic that Cloudflare is using this critical security time to lie to people that they are safe.
Anyone from Cloudflare want to speak to this?
I'm not from Cloudflare, or particularly a fan of theirs, but they are doing a few things about this, including a new WAF capability: https://blog.cloudflare.com/full-transaction-waf/ and automatic protection for all customers https://blog.cloudflare.com/php-vulnerabilities-waf-protecti...
These were rolled out before the exploit became public.
I would wouldn't describe that as damning.
It's great they are doing mitigations, but they admit themselves, in fine print, that this will not protect you from the vulnerability
Why is word circulating that you can just sign up for Cloudflare and be 100% protected from this? They are burying the leed and trying to get new customers, and it's working.
When log4j came out CF helped a lot. The rules are called stopgap. A TEMPORARY fix. CF added some for this exploit.
The old way of doing things like putting old unpatched stuff behind firewalls is pretty much a dead pattern today.
apt update
apt upgrade
debian package WHEN
Debian package 20 minutes before your post: https://lists.debian.org/debian-security-announce/2026/msg00...
Hetzner's control panels are PHP. And they're totally unresponsive. Perhaps people storming to manage their services or submit support requests.
Maybe Hetzner know a company that can help out with extra computer resource...? /s
Useless. My fault for paying peanuts
What I did on our WordPress boxes while waiting for distro packages (CVE-2026-109618 / CVE-2026-109619)
1. session.upload_progress.enabled = Off, in php.ini and as php_admin_flag in every FPM pool, so per-directory config can't turn it back on. It's one of the two confirmed consumers in GHSA-6wmf, and the validated FPM path depends on it. Almost nobody uses it, and the advisory suggests leaving it off even after patching.
2. Refuse multipart request bodies at the web server, before PHP parses them. All of the GHSA-w8hw out-of-memory strategies go through multipart parsing. On Apache it's a rewrite rule matching a Content-Type of multipart/form-data that returns 403. On Caddy it's a header matcher that responds 403. The cost: every browser upload breaks (media library, plugin zips, importers). Check your public forms first.
3. Check your SAPI. Both bugs have confirmed RCE against mod_php. FPM is narrower: the validated path needs upload_progress, and the early INI consumer only applies if your front end sends PHP_VALUE/PHP_ADMIN_VALUE. To check, grep your Apache, nginx and Caddy configs for it, and run apache2ctl -M | grep php.
4. pm.max_requests = 1 in the pools. A worker serves one request and exits, which breaks the stale-state chain: the "producer" and "consumer" requests must land on the same worker. It costs a fork per request.
5. Lower max_input_nesting_level and post_max_size, per the advisory.
6. Housekeeping that should already be done: no .php served from uploads directories, and remove any stray phpinfo.php. Scanners request it constantly, and it tells an attacker your exact build.
This is just Claude output. Did you verify anything or just rehash the links?
It's just Claude output of what I've done; the other URL has the basics.
HN should ban comments that are just Claude output
https://news.ycombinator.com/newsguidelines.html#:~:text=Don...
I’d rather just some sort of tag. Because sometimes it can be useful. This is a case where the community here can scrutinize the output and actually pull out useful data or steps or even starting points when information is coming in so fast for a developing story/issue
The (pretty obviously Claude'd) responses with actual steps you could take to mitigate were 1000% more useful to me than the "SHUT EVERYTHING DOWN WE'RE GONNA DIE" and the "stop posting AI slop" posts were, that's for sure.
It was your response. Of course you prefer your response.
The fact is you had no idea how useful or dangerous your advice was. PHP maintainers said to shut it down, how many people followed your advice instead? Did it work or just leave them vulnerable? Do you know?
Because you're heavily implying that the people who knew about the details of the vulnerability were panicking and thank god we had you with an LLM
C'mon Ondřej..
it's out?
yup
PHP is done.
People have been saying this for the past 16 years, but the reality is once a system is in production over time it becomes increasingly risky to replace it. Because over the life of a piece of software you make tons of small fixes, resolve bugs, adding customer-specific functionality, etc. that you'd completely overlook when planning our requirements for a rewrite. Which is a big problem when other systems are dependent on the software operating a specific way i.e. APIs, web services, and so forth. Not to mention the economics of a rewrite also has to make sense. Nobody is going to spend 2-3 years recreating what they already had and get no additional functionality out of it. Certain software basically has to get so bad that literally anything replacing it is better than what came before for replacing it to be the right approach.
People shouldn't be using PHP. I was shocked some security focused websites are even using it. I just hope there's nothing of value on their servers and that it's not connected to their internal network in any way. In my experience this is almost always the case because it makes maintenance and development easier but effectively exposes your entire organization to the internet.
That 70% of the internet still uses it is shocking to me. These organizations deserve to get burned badly. Let this incident be a warning to all of them!
PHP is not a particularly insecure language. It’s certainly more secure than something like C or C++. Certain PHP applications are known to have vulnerabilities often, like WordPress.
PHP is a memory-safe language. This vulnerability is a memory safety bug in the VM, which does happen from time to time. It happens with V8 (JS), Java, C#.
To me PHP has an aura of "unprofessionalism" around it. Many of the PHP solutions have been hacked together by amateurs who sought a solution for their own problem and by chance it became widely used.
The language itself was one big hack when it was created. It has improved somewhat but just like with C++ you can still use the C syntax that's at the core of it all.
This isn't the last we'll hear of PHP vulnerabilities because the exploits exist on multiple levels. Not just the language (runtime) but the solutions using it too.
I mean you’re just incorrect about the C++ vs C comparison here.
PHP is a memory safe language, just as memory safe as Java, C# and JS. The runtime itself has very few vulnerabilities and bugs, and is quite mature. There’s no “drop down into C” type thing in PHP, where you can just write unsafe code whenever you want. The closest thing is extensions, which operate on the runtime itself.
In the past 10 years, the PHP runtime has had little to no exploitable vulnerabilities. The V8 runtime has had much more. Mostly because their implementation is much more complex.
The PHP language was hacky in the very early days, but for over a decade now it’s been mature and professional. It’s basically just dotnet.
List a single language for web development that hasn't had a single RCE vulnerability
C# (ASP.NET) and Java.
Just how debian was done after weak keys, OpenSSL was done after heartbleed, or Windows was done after (rolls dice) the print spooler RCE
And how Crowdstrike was done after their fiasco 2 years ago...
And Lenovo was done after Superfish
Sony after installing a rootkit. (Although they really are dead to me now after paying two noise cancelling headphones of theirs)
Not at all. People will patch and carry on.
always was
always will be
Can't we fingerprint the code in github and elsewhere and tell AI labs to not do security reviews on the code unless (A) someone is a legitimate security researcher or (B) someone is the owner of the code.
Yeah it sucks, but the alternative could be worse.
If you're tired of having to upgrade Wordpress, point your agent at this tutorial:
https://blog.okturtles.org/2024/10/convert-wordpress-to-stat...
…or just enable automatic updates.
last I looked, automatic updates for wordpress meant letting the web server write to the document root, which may be on the same level of negligence as not updating quickly.
Plus, wordpress updating isn't going to help you upgrade php.
The problem with that is your site might get replaced by a rant by the CEO ...
So-- if PHP's sourcecode was unavailable (closed source), would this ever have been found? Probably not. Maybe it is safer to be closed source.
Know how recompilers are porting video games from one platform to another these days? That exact trick works just as well for finding vulnerabilities. Broadly.
1. Hey LLM, turn this binary into source code.
2. Hey LLM, see any glaring security issues with this source code?
You can only do that if you have access to the binary. Which, in a web service, you shouldn't be able to access!
But all the people deploying that binary to their webservers would have access to do that.
So how is PHP being distributed in your funny world? Because I can tell you, even if you put it behind “register with your work email,” whoever seeks the binary will find it.
> Know how recompilers are porting video games from one platform to another these days?
They actually aren't. Most of the claimed cases of "recompilation" are just an emulator packaged into the same binary as the game so you can't tell it's an emulator, or are for projects that already had their source code available (in which case "porting" to WASM is trivial because all of the hard work is done by the people who write your-language-to-WASM compilers, and you just need to do a little bit of work to adjust your toolchain to use it). Everyone just takes slopshit at face value and shares clickbait without actually checking any of the work done. It's infuriating how empowering this software is for liars, honestly.
Does anyone use PHP anymore? I assumed it was abandonware
No, the entire world abandoned it when you realized it wasn't the perfect language. The rest of us are just role playing today basically. It's a bit of a lark, kind of like civil war reenactment.
"Four diffs and seven lines ago..."
I see the downvotes and I don't really disagree with you.
This hurts because my resume has laravel and WordPress on it. I built sooo many sites/apps on it.
With AI agents, I just can't imagine using PHP anymore unless I'm patching legacy stuff.
I loved laravel too... WordPress, love hate.
Are you fucking serious?
Ever heard of WordPress?
or Wikipedia.
Wordpress is a toxic property.
Is WordPress still a thing? Why hasn't it been rewritten in Rust by Claude?