Looks like a co-ordinated disclosure between Wiz, Calif and OpenAI:
https://www.wiz.io/blog/php2shell-php-rce
https://openai.com/index/coordinated-disclosure-of-critical-... (not yet live)
https://thephp.foundation/blog/2026/10/21/todays-php-securit... (not yet live)
Someone is saying there is a new vulnerability that works on the newest 8.5.12 https://x.com/_annieversary/status/2112933589943742598
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.
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.
Ondrej might appreciate some monetary love on a day like today.
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...
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
> out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.
If only we could come up with a way to manage memory automatically. Alas, one can only dream.
Just pulled the new matomo that was published on dockerhub 26 minutes ago, thinking it has the patched PHP version:
# docker pull matomo:latest
latest: Pulling from library/matomo
Digest: sha256:6e63589d31ec653f78e029084d21488640fdbbd9a42c96c872098f42c8678a02
Status: Image is up to date for matomo:latest
docker.io/library/matomo:latest
# docker run --rm matomo:latest php --version
PHP 8.4.26 (cli) (built: Oct 21 2026 00:31:19) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.4.26, Copyright (c) Zend Technologies
with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies
The PHP build is from today, which is doubly misleading. 8.4.27 is the patched release, not 8.4.26. I wonder how many people will pull this image thinking they're good to go online again.Interview with two of the discoverers: Breaking Down PHP2Shell with Sagi Tzadik (Wiz) & Thai Duong (Calif)
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.
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
there is clearly some drama w.r.t. who takes credit here, 3 companies credited for a single flaw is super odd.
FML. Can't get in to update our servers because of MFA and our director, who gets the codes, isn't in
Hard to deploy if you also install extensions from PECL right now (probably slammed).
Does anyone know how long it takes for the ondrej/php repo to be patched usually?
how does Docker not yet have a new, official PHP image ready, given such a big heads up? https://hub.docker.com/_/php Nuts this wasn't ready to flip on at :00 (or even earlier given the PoC exploit and even the official PHP fixes were out well before). Now we are 27 minutes past due.
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.
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.
CISA published an advisory half an hour ago:
https://www.cisa.gov/news-events/alerts/2026/10/21/critical-...
Does anyone know the ETA on the official php:* docker images? I think they only released patched 8.6 RC containers for now.
i just took down all my PHP sites for the last few hours. they’re proxied behind Cloudflare so i know there were mitigations, but infrastructure can’t be breached if it isn’t running!
Seems like they finally decided to release it after so many people had access. What happened to security as a priority.
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].
It says pecl.php.net recovered but downloading source for extensions ends up with 504 most of the time.
Still no release for Ubuntu... They are already half an hour late. Debian got the patch almost immediately...
Has there yet been any signs of any service actually being successfully hacked due to the vulnerability?
The best time to code away from PHP was 20 years ago. The next best time is now.
>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.
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.
Sury released backports for older versions, as always hes incredibly reliable.
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
Looks like the docker images are struggling in the Jenkins queue: https://doi-janky.infosiftr.net/
Why is the description of "RCE via OOM corruption" mentioning all these settings like memory_limit, post_max_size, max_input_nesting_level etc under "Mitigation" but not blocking multipart requests? Isn't that a solution?
The description of the vurnurability "Several multipart parsing problems" makes it sound like it is?
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.
PPA packages on LaunchPad being built here: https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
Versions: 8.2.35 8.3.36 8.4.27 8.5.12
Now are available in the php-src github
If open source has these vulnerabilities, imagine proprietary ones.
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"
Does anybody know when Amazon Linux 2023 will get this release?
apt-get update + apt-get upgrade fixes it on Debian, but not on Ubuntu for now
While the patches are being merged for the official docker images, perfect time for a github outage! https://downdetector.com/status/github/
They have to backport this fix or else leave a large part of the internet broken.
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?
Gentoo has it updated.
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.
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)