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.
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?
I'm surprised by CGI. The vulnerability description talks about a second request being affected by corrupted state from an earlier request. But I though CGI only processes one request per process?
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:
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.
And 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.
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.
Similar issue with "Merge request", GitHub invented the term "Pull Request", combined it with a particular workflow (rebased, ff-only merged without merge commits favored), and it worked well for them, and also to simplify Git for their users.
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.
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!
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.
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
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.
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.
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.
> How does knowing the agency who's practically whole purpose is hoarding 0days has 0days mean anyone thinks they're "special"?
Read the original text, it makes it seem that the NSA has some next level capabilities in hacking and discovering or requesting zero days from vendors. Something which seem absurd given the intelligence failure that we see in the Persian gulf.
> Also, Vulnerability Researchers working for the NSA are not located in the Gulf, and the NSA was not involved in that situation.
May be difficult to believe but Iranians also have computers. If you want to believe the NSA has incredible multiple zero days and Iran has been at worst in the top 3 of enemy nations, how did they not know about the missiles and drone programs ? How could they not know ALL or SOME of their locations ?
> I fail to see how it's relevant whatsoever. The U.S. is not a monolith.
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?
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.
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
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
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
I wrote it so I could deploy it myself on our old nginx + php-fpm setups, thought I would share. It should work with all top servers (nginx, apache, caddy etc)
>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.
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.)
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'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 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!
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.
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. The organizations that do 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.
I'm very skeptical having been in this business for decades. It's almost common knowledge that any PHP site can be hacked by intelligence agencies or state actors due to either errors in the runtime or the solutions themselves.
This incident got a lot of publicity, but what about the thousands of plugins out there full of hacks and sloppy programming?
Again, there are virtually no vulnerabilities in the runtime itself. PHP has had less vulnerabilities than V8.
Certain applications, like Wordpress, are notorious for vulnerabilities. But these happen at the application level. PHP, as a language, is memory safe and largely secure.
Think of it this way. V8 has had numerous RCE vulnerabilities in the runtime. But also, react router has had RCE vulnerabilities. But react router was due to poor application design, much like Wordpress, where actors could trigger arbitrary code on the backend from manipulating requests. That’s very similar to how most wordpresss vulnerabilities work.
280 comments
[ 4.5 ms ] story [ 30.7 ms ] threadNow are available in the php-src github
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.
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.
https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecom...
https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
follow https://packages.sury.org/php/README.txt
https://github.com/php/php-src/security/advisories/GHSA-w8hw...
https://github.com/php/php-src/security/advisories/GHSA-6wmf...
> 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.
How does that work? Exec(ve) without fork? That should still clean up the PHP state.
What everyone is looking for.
I assume it just got pushed?
> 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 very least
Is it perhaps a bit misleading, and only means that there's no branch containing that commit?
And 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.
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.
Similar issue with "Merge request", GitHub invented the term "Pull Request", combined it with a particular workflow (rebased, ff-only merged without merge commits favored), and it worked well for them, and also to simplify Git for their users.
https://buildd.debian.org/status/package.php?p=php8.2&suite=...
https://docs.nvidia.com/datacenter/tesla/driver-installation...
awake2death or something
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
Is this even reachable on Linux due to overcommit? Maybe by attempting a single extremely large allocation?
https://www.php.net/archive/2026.php#2026-10-20-1
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...
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.
and yet they attacked and lost ALL their bases around the Gulf and today are in what can best be described as a Pyrric Stalemate.
Also, Vulnerability Researchers working for the NSA are not located in the Gulf, and the NSA was not involved in that situation.
I fail to see how it's relevant whatsoever. The U.S. is not a monolith.
Read the original text, it makes it seem that the NSA has some next level capabilities in hacking and discovering or requesting zero days from vendors. Something which seem absurd given the intelligence failure that we see in the Persian gulf.
> Also, Vulnerability Researchers working for the NSA are not located in the Gulf, and the NSA was not involved in that situation.
May be difficult to believe but Iranians also have computers. If you want to believe the NSA has incredible multiple zero days and Iran has been at worst in the top 3 of enemy nations, how did they not know about the missiles and drone programs ? How could they not know ALL or SOME of their locations ?
> I fail to see how it's relevant whatsoever. The U.S. is not a monolith.
Meaning ?
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?
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.
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.
"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.
Amazingly, AWS Linux has not been patched yet.
The PHP team knew about it since September 21st.
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
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
https://news.ycombinator.com/item?id=50180987
https://github.com/Qbix/proxy
I wrote it so I could deploy it myself on our old nginx + php-fpm setups, thought I would share. It should work with all top servers (nginx, apache, caddy etc)
Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)
It feels like many times PRs could just be that.
"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
https://www.patreon.com/cw/oerdnj
Newest: 5.6.40-104 which has the CVE fixes.
That 70% of the internet still uses it is shocking to me. The organizations that do deserve to get burned badly. Let this incident be a warning to all of them!
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#.
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.
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.
This incident got a lot of publicity, but what about the thousands of plugins out there full of hacks and sloppy programming?
Certain applications, like Wordpress, are notorious for vulnerabilities. But these happen at the application level. PHP, as a language, is memory safe and largely secure.
Think of it this way. V8 has had numerous RCE vulnerabilities in the runtime. But also, react router has had RCE vulnerabilities. But react router was due to poor application design, much like Wordpress, where actors could trigger arbitrary code on the backend from manipulating requests. That’s very similar to how most wordpresss vulnerabilities work.