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.)
show comments
basilgohar
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.
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.
Hopefully just a mistake? But looks like a botched release at the least
show comments
bartnp
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
k1kingy
Does anyone know how long it takes for the ondrej/php repo to be patched usually?
show comments
dstu
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.
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.
conradfr
Hard to deploy if you also install extensions from PECL right now (probably slammed).
show comments
bstsb
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!
show comments
tikotus
Has there yet been any signs of any service actually being successfully hacked due to the vulnerability?
show comments
devtor
Interview with two of the discoverers: Breaking Down PHP2Shell with Sagi Tzadik (Wiz) & Thai Duong (Calif)
>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.
aurareturn
And there were people who thought Project Glasswing was a stunt.
Amsozzer
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
show comments
ckbkr10
Sury released backports for older versions, as always hes incredibly reliable.
Does anybody know when Amazon Linux 2023 will get this release?
show comments
blain
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.
show comments
theturtletalks
If open source has these vulnerabilities, imagine proprietary ones.
davidgoggins
The best time to code away from PHP was 20 years ago. The next best time is now.
dabinat
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.
londons_explore
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"
show comments
choilive
How does this not have a CVSS of 10?
RoshanAmble
Seems like they finally decided to release it after so many people had access. What happened to security as a priority.
abbbi
debian trixie just rolled updates.
show comments
a-nych
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.
...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
alper
They have to backport this fix or else leave a large part of the internet broken.
there is clearly some drama w.r.t. who takes credit here, 3 companies credited for a single flaw is super odd.
DonHopkins
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
show comments
torbengee
Looks like the upgrade instructions for PHP 8.3 for Fedora 39 and earlier are not working ... yikes.
system7rocks
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.
sourcecodeplz
PHP 8.3.36 (cli) (built: Oct 21 2026 08:18:34) (NTS)
made it in time hopefully
cowlevel
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?
show comments
f311a
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.
show comments
mahboi
Seems like 4chan is down for maintenance as a result.
julian9499
Anyone know when amazon linux 2023 is releasing updates?
techteach00
Is this why Wikipedia isn't working?
show comments
deanc
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.
lexoj
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 )
EGreg
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 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.
phplovesong
This is pure gold. A critical vuln like this is such classic lolphp. Luckily you can port away from PHP pretty easily with AI.
cute_boi
> 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.
2OEH8eoCRo0
Do any home router login pages use PHP?
show comments
joenada
Log4J4PHP
iLoveOncall
Sucks to be you if you're not on PHP 8 :|
show comments
varispeed
Why they can't publish an expoit so people can run it against their own servers to check the impact?
jdw64
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.
Capricorn2481
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?
show comments
gib444
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
bombcar
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.
show comments
magar_fos
C'mon Ondřej..
show comments
rvz
PHP is done.
show comments
bitbasher
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.
show comments
amelius
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.
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)
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)
Looks like there might be a second vulnerability: https://fedi.katze.sh/@elise/117479383739450605
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.)
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.
Someone is saying there is a new vulnerability that works on the newest 8.5.12 https://x.com/_annieversary/status/2112933589943742598
Ondrej might appreciate some monetary love on a day like today.
https://www.patreon.com/cw/oerdnj
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...
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
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
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
Does anyone know how long it takes for the ondrej/php repo to be patched usually?
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.
https://ubuntu.com/security/CVE-2026-109618#status fixes have been back ported in Ubuntu LTS versions just now.
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.
Hard to deploy if you also install extensions from PECL right now (probably slammed).
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!
Has there yet been any signs of any service actually being successfully hacked due to the vulnerability?
Interview with two of the discoverers: Breaking Down PHP2Shell with Sagi Tzadik (Wiz) & Thai Duong (Calif)
https://www.youtube.com/watch?v=lfEtbrz4-zY
CISA published an advisory half an hour ago:
https://www.cisa.gov/news-events/alerts/2026/10/21/critical-...
>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.
And there were people who thought Project Glasswing was a stunt.
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
Sury released backports for older versions, as always hes incredibly reliable.
Code example for the exploits https://github.com/david-alvarez-rosa/php-rce
Does anybody know when Amazon Linux 2023 will get this release?
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.
Versions: 8.2.35 8.3.36 8.4.27 8.5.12
Now are available in the php-src github
Looks like the docker images are struggling in the Jenkins queue: https://doi-janky.infosiftr.net/
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.
If open source has these vulnerabilities, imagine proprietary ones.
The best time to code away from PHP was 20 years ago. The next best time is now.
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 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"
How does this not have a CVSS of 10?
Seems like they finally decided to release it after so many people had access. What happened to security as a priority.
debian trixie just rolled updates.
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
...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
They have to backport this fix or else leave a large part of the internet broken.
https://github.com/php/php-src/commit/01a40e89fbfc499936e3b0...
What everyone is looking for.
Why is the official source (php.net) marked as [dupe] https://news.ycombinator.com/item?id=50180943
and not the github mirror?
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
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?
So this only affects 8.2 are other patches coming?
https://github.com/consocio/php2shell-audit/ GLM 5.3 just wrote it to audit all my php sites. I hope it is useful to you.
Any signs of exploits out yet?
there is clearly some drama w.r.t. who takes credit here, 3 companies credited for a single flaw is super odd.
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
Looks like the upgrade instructions for PHP 8.3 for Fedora 39 and earlier are not working ... yikes.
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.
PHP 8.3.36 (cli) (built: Oct 21 2026 08:18:34) (NTS)
made it in time hopefully
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?
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.
Seems like 4chan is down for maintenance as a result.
Anyone know when amazon linux 2023 is releasing updates?
Is this why Wikipedia isn't working?
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 )
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
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.
This is pure gold. A critical vuln like this is such classic lolphp. Luckily you can port away from PHP pretty easily with AI.
> 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?
Log4J4PHP
Sucks to be you if you're not on PHP 8 :|
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.
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?
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.
C'mon Ondřej..
PHP is done.
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.
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.