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.
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?
Well... Based on the response to this incident, I think you're asking a great question!
What value did the security team add? Seemingly none. In fact, it seems they actively delayed the response; if the report/fix had come through as a normal MR, they would have fixed it weeks ago.
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.
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?!
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.
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
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.
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.
> 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.
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
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?
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.
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.
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.
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 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?
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.
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.
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
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
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.)
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.
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.
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!
> 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.
>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, 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.
Since I have to go through a bunch of php repos today at work I ended up releasing a CLI tool that automates that process by listing out the steps you need to take to stay away from the vulnerability.
Here's the link incase it helps anyone https://github.com/Amsozzer1/php2shell-repo-audit
Dude, today of all days is not when I'm going to trust some random CLI tool that was vibed out. I'm not saying your work isn't helpful, but it would probably be a lot better to just release your prompts you used to build this and let others build it on their own.
I wouldn't listen to him. This is very helpful to people that might be managing dozens or hundreds of servers and need a way to quickly figure out things. It's literally open source and we can point our agent to it and have it examine the source code for anything that looks suspicious first. No need to sit here for a couple hours trying to go back and forth and create something that you already took the time to do. Thanks for the work!
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.
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.
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 )
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.
> 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
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:
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.
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.
"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.
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.
It's free, MIT open source. It was the best I could do. Run it under a Linux user with no permissions to access anything. All it's supposed to do is proxy requests. Don't give it access to any files.
Honestly, and not to be harsh, but doing absolutely nothing is better than what you've done here.
Not only is this proxy unlikely to actually protect against the issues, but this code almost certainly has its own, equally bad security vulnerabilities. A 30 second check with Opus 5.5 found at least one heap overflow, multiple memory leaks, and a number of bugs that shows that it doesn't even succeed at doing what it claims. I appreciate that you're trying to help, but there are better tools for the approach that you're going for here, and injecting noise with AI slop that isn't even reviewed at a basic level is causing noise, confusion, and potential harm in an already urgent, tense situation.
Not to be harsh, but what you said is completely irresponsible and harmful.
Leaving people completely unprotected to the entire Internet when their servers are now vulnerable to arbitrary, remote, command execution, is about as bad as it gets.
People can have their large language model review the code in about 15 seconds. It’s quite minimal. They can also simply run the proxy as a Linux user that has zero permissions for most things like writing files. This is literally just a proxy that sanitizes input.
I could understand if you actually at least clicked and looked at the repository, and read what it’s about. But you chose to simply write generic text without looking at anything. You want to discourage people from protecting their servers, in order to feel good about yourself. What amount of effort have you put into understanding what you’re even talking about?
If your AI found a possibility of a memory leak, please actually point to the source code, or better yet submit a request. And a possible gradual memory leak, as a reason to not do this, really? None of this is as bad as NOT protecting your server.
I'm going to engage only because I do not wish others to come across this project and think it's serious. I did open the project and read the code, and I did throw it into an LLM as I previously said for some very basic security posture checks, and found a number problems immediately, but I don't trust them (and neither should you, which is part of the problem here), so I went digging a bit deeper. I don't have the time to go through all of them, so here's a big one of my own finding: There's a parser differential in how multipart boundaries are handled, your proxy only deals with ;, the PHP interpreter accepts , as well, and the proxy will pass it through unchanged to the upstream. That's a full bypass of what the proxy is trying to do.
The article linked from your own README (https://sansec.io/research/php2shell) has a better partial mitigation in existing, battle-tested reverse proxies. Even still, as that article says, everything here is a partial mitigation. The description of the issues in your project's README is an inaccurate understatement of the severity of the issues. "CVE-2026-109618 — heap use-after-free in the session.upload_progress handler" is an incomplete understatement of the issue, the session.upload_progress handler is only one of a number of potential exploitation paths. https://github.com/php/php-src/security/advisories/GHSA-w8hw... has some hints at other paths, of which there are many.
From an LLM, and quickly validated by me, a heap overflow, likely an RCE.
> src/http.c:101-116 and src/util.c:9
Attacker supplied value in strtoul, the size-limit checks are unsigned addition that can wrap, and you can follow the chain from there.
> or better yet submit a request.
This project is not deserving of fixing, it should just be deleted and direct people to more serious documentation of fixes and mitigations. This code is clearly AI-generated slop, it is not my responsibility to fix your project.
> I could understand if you actually at least clicked and looked at the repository, and read what it’s about. But you chose to simply write generic text without looking at anything. You want to discourage people from protecting their servers, in order to feel good about yourself. What amount of effort have you put into understanding what you’re even talking about?
Great, by writing what I did, I got you to at least post the actual issues you found. That’s progress.
They have already been addressed and the results pushed. That’s how things work. Anything else?
Now, regarding your insistence that this project, which protects servers running PHP from potentially being TOTALLY PWNED by any random bot on the Internet (and silently turned into a botnet, for instance)…
Please do point to “more serious documentation and mitigations” that will actually protect unpatched PHP servers. We don’t need documentation, we need actual practical software. Where is it? This magical proxy software that was there the whole time…
You know, normally I'd be okay with these comments, but in this case you're actively hurting a lot of people by this bullshit. Many people need something other than patching PHP.
It's free and MIT licensed, open source and it is currently the only alternative to patching your PHP. The "profit" is for people who don't get PWNED today!!!
Many people can't patch your PHP. If you can't be bothered to even look at the repo, you may want to sit this one out.
The one we're in right now, where we're waiting for vendors to rebuild the packages (I'm ass-blasted that the delay to 14:00 UTC wasn't for the vendors to build packages but seems to be a PR stunt?).
You're right – need to fix the Cosmopolitan build in GitHub actions. On it!
UPDATE: Just going to ship a Linux binary for now, that's where most hosting is. Almost no one hosts from a MacOS or Windows machine. The Cosmo binary was overkill here.
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
Why don't you do something useful and rewrite it so it's not claude output any more, but says the same thing in a way that you're satisfied with?
Then your own comment would not be such low effort and useless human slop.
Do you agree or disagree with the comment's claims? Did YOU verify anything? Let's all hear you fact check and proofread and reword what it said so it matches your standards, instead of just listening to you bitch and complain without offering any useful information.
Or do you not actually know anything about PHP administration, programming, and security, so you're only capable of information-free drive-by anti-ai posts, without any other useful content or corrections?
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!
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.
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)
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...
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.
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.
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.
i highly doubt it. these are pretty big names in the security sector who have plenty of experience reporting high severity vulns.
this is basically the same as releasing a working exploit.
What value did the security team add? Seemingly none. In fact, it seems they actively delayed the response; if the report/fix had come through as a normal MR, they would have fixed it weeks ago.
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?!
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?
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.
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.
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.
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.
The PHP team knew about it since September 21st.
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.
See PHP foundation blog post on their timeline
Amazingly, AWS Linux has not been patched yet.
And they botched this as someone talked. To me this looks like they used this for a PR stunt and aimed for an RCE.
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.
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.
Ubuntu: https://ubuntu.com/security/notices/USN-8948-1
Fedora package status: https://packages.fedoraproject.org/pkgs/php/php-fpm/
Edit: was looking Wiz post when citation was from OpenAI
I’d press go too - if something this big was known to some but not all…
We’ll all get through together
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.
PHP will always be the slop before AI.
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
Boy, do I hate these PR websites masquerading as vulnerability reports. It's slop all the way down with these companies.
It's like slop for infosec markters
https://www.cisa.gov/news-events/alerts/2026/10/21/critical-...
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.)
Edit: Seems like GitHub has issues with merging PRs: https://github.com/docker-library/official-images/pull/22541
https://github.com/docker-library/official-images/pull/22544
Maybe the guy that has to click OK is asleep?
https://github.com/docker-library/faq#an-images-source-chang...
https://hub.docker.com/_/php/tags
EDIT: 25min later, nope.
https://hub.docker.com/layers/library/php/8.5.12-fpm/images/...
The average phpBB or Wordpress, even if it's behind cloudflare, probably has a direct IPv4 that's not disabled.
https://wpenginestatus.com/incidents/969801
https://github.com/php/php-src/security/advisories/GHSA-w8hw...
https://github.com/php/php-src/security/advisories/GHSA-6wmf...
Well off to a good start here.
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.
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.
> 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
But there were two vulns - only the second required the two requests.
https://www.patreon.com/cw/oerdnj
> 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
Is it perhaps a bit misleading, and only means that there's no branch containing that commit?
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.
`[00:06:03.209] pecl install -f amqp igbinary redis imagick` :sad_face:
follow https://packages.sury.org/php/README.txt
https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecom...
https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)
I realised that my linode and ovh vm's point at local mirrors not direct to ubuntu, I guess that's why the delay
awake2death or something
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.
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"
It feels like many times PRs could just be that.
made it in time hopefully
Now are available in the php-src github
https://github.com/php/php-src/tags
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.
> Exploit portability and reliability depend on the PHP build, extensions, frontend behavior and allocator layout.
There are already functional exploit scripts on GitHub, you can target any Wordpress site right now.
and not the github mirror?
https://buildd.debian.org/status/package.php?p=php8.2&suite=...
> 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
What everyone is looking for.
I assume it just got pushed?
https://www.php.net/archive/2026.php#2026-10-20-1
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.
"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
Maybe just CYA.
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.
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.
Also, sandboxing makes automatic exploitation harder. There is no FS persistence, so some checks simply do not pass.
Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?
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?
These were rolled out before the exploit became public.
I would wouldn't describe that as damning.
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.
Honestly, and not to be harsh, but doing absolutely nothing is better than what you've done here.
Not only is this proxy unlikely to actually protect against the issues, but this code almost certainly has its own, equally bad security vulnerabilities. A 30 second check with Opus 5.5 found at least one heap overflow, multiple memory leaks, and a number of bugs that shows that it doesn't even succeed at doing what it claims. I appreciate that you're trying to help, but there are better tools for the approach that you're going for here, and injecting noise with AI slop that isn't even reviewed at a basic level is causing noise, confusion, and potential harm in an already urgent, tense situation.
Leaving people completely unprotected to the entire Internet when their servers are now vulnerable to arbitrary, remote, command execution, is about as bad as it gets.
People can have their large language model review the code in about 15 seconds. It’s quite minimal. They can also simply run the proxy as a Linux user that has zero permissions for most things like writing files. This is literally just a proxy that sanitizes input.
I could understand if you actually at least clicked and looked at the repository, and read what it’s about. But you chose to simply write generic text without looking at anything. You want to discourage people from protecting their servers, in order to feel good about yourself. What amount of effort have you put into understanding what you’re even talking about?
If your AI found a possibility of a memory leak, please actually point to the source code, or better yet submit a request. And a possible gradual memory leak, as a reason to not do this, really? None of this is as bad as NOT protecting your server.
https://github.com/Qbix/proxy/blob/main/src/sanitize.c#L41 https://github.com/php/php-src/blob/master/main/SAPI.c#L162
The article linked from your own README (https://sansec.io/research/php2shell) has a better partial mitigation in existing, battle-tested reverse proxies. Even still, as that article says, everything here is a partial mitigation. The description of the issues in your project's README is an inaccurate understatement of the severity of the issues. "CVE-2026-109618 — heap use-after-free in the session.upload_progress handler" is an incomplete understatement of the issue, the session.upload_progress handler is only one of a number of potential exploitation paths. https://github.com/php/php-src/security/advisories/GHSA-w8hw... has some hints at other paths, of which there are many.
From an LLM, and quickly validated by me, a heap overflow, likely an RCE.
> src/http.c:101-116 and src/util.c:9
Attacker supplied value in strtoul, the size-limit checks are unsigned addition that can wrap, and you can follow the chain from there.
> or better yet submit a request.
This project is not deserving of fixing, it should just be deleted and direct people to more serious documentation of fixes and mitigations. This code is clearly AI-generated slop, it is not my responsibility to fix your project.
> I could understand if you actually at least clicked and looked at the repository, and read what it’s about. But you chose to simply write generic text without looking at anything. You want to discourage people from protecting their servers, in order to feel good about yourself. What amount of effort have you put into understanding what you’re even talking about?
Every accusation is an admission.
They have already been addressed and the results pushed. That’s how things work. Anything else?
Now, regarding your insistence that this project, which protects servers running PHP from potentially being TOTALLY PWNED by any random bot on the Internet (and silently turned into a botnet, for instance)…
Please do point to “more serious documentation and mitigations” that will actually protect unpatched PHP servers. We don’t need documentation, we need actual practical software. Where is it? This magical proxy software that was there the whole time…
It's free and MIT licensed, open source and it is currently the only alternative to patching your PHP. The "profit" is for people who don't get PWNED today!!!
Many people can't patch your PHP. If you can't be bothered to even look at the repo, you may want to sit this one out.
https://github.com/Qbix/proxy
UPDATE: Just going to ship a Linux binary for now, that's where most hosting is. Almost no one hosts from a MacOS or Windows machine. The Cosmo binary was overkill here.
Nobody should trust this.
GitHub actions builds from source
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.
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
Then your own comment would not be such low effort and useless human slop.
Do you agree or disagree with the comment's claims? Did YOU verify anything? Let's all hear you fact check and proofread and reword what it said so it matches your standards, instead of just listening to you bitch and complain without offering any useful information.
Or do you not actually know anything about PHP administration, programming, and security, so you're only capable of information-free drive-by anti-ai posts, without any other useful content or corrections?
Ball's in your court.
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!
1. Hey LLM, turn this binary into source code.
2. Hey LLM, see any glaring security issues with this source code?