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.)
basilgohartoday at 2:43 PM
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.
cholmontoday at 2:14 PM
Ondrej might appreciate some monetary love on a day like today.
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
majewskytoday at 2:17 PM
> 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.
andrelaszlotoday at 2:41 PM
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.
bartnptoday at 3:50 PM
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
imzaditoday at 2:07 PM
FML. Can't get in to update our servers because of MFA and our director, who gets the codes, isn't in
k1kingytoday at 1:50 PM
Does anyone know how long it takes for the ondrej/php repo to be patched usually?
dstutoday at 2:04 PM
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.
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.
conradfrtoday at 4:56 PM
Hard to deploy if you also install extensions from PECL right now (probably slammed).
andixtoday at 1:57 PM
Does anyone know the ETA on the official php:* docker images? I think they only released patched 8.6 RC containers for now.
system7rockstoday at 8:41 PM
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.
bstsbtoday at 1:55 PM
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!
devtortoday at 6:17 PM
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.
ckbkr10today at 2:34 PM
Sury released backports for older versions, as always hes incredibly reliable.
Amsozzertoday at 2:04 PM
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
blaintoday at 5:31 PM
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.
TekMoltoday at 2:03 PM
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?
Does anybody know when Amazon Linux 2023 will get this release?
aurareturntoday at 4:14 PM
And there were people who thought Project Glasswing was a stunt.
jillesvangurptoday at 4:48 PM
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.
The best time to code away from PHP was 20 years ago. The next best time is now.
choilivetoday at 6:56 PM
How does this not have a CVSS of 10?
dabinattoday at 6:23 PM
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.
theturtletalkstoday at 2:47 PM
If open source has these vulnerabilities, imagine proprietary ones.
RoshanAmbletoday at 6:16 PM
Seems like they finally decided to release it after so many people had access. What happened to security as a priority.
londons_exploretoday at 4:13 PM
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"
a-nychtoday at 5:26 PM
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.
GLM 5.3 just wrote it to audit all my php sites.
I hope it is useful to you
pier25today at 2:13 PM
Apparently about 40% of PHP apps are still on PHP 7 and 5...
nairboontoday at 2:00 PM
A bit too early for the announced coordinated release, no?
DonHopkinstoday at 2:10 PM
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
sourcecodeplztoday at 4:47 PM
PHP 8.3.36 (cli) (built: Oct 21 2026 08:18:34) (NTS)
made it in time hopefully
alrenaitoday at 2:42 PM
Anyone know if Microsoft updates azure web-app built-in php runtimes fairly quickly in this sort of scenario?
torbengeetoday at 2:43 PM
Looks like the upgrade instructions for PHP 8.3 for Fedora 39 and earlier are not working ... yikes.
EGregtoday at 7:22 PM
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:
Is PHP 7 essentially going to be dead and unusable for everyone then? Or will it get fixes?
mahboitoday at 3:30 PM
Seems like 4chan is down for maintenance as a result.
cowleveltoday at 1:57 PM
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?
f311atoday at 2:18 PM
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.
techteach00today at 4:04 PM
Is this why Wikipedia isn't working?
julian9499today at 2:45 PM
Anyone know when amazon linux 2023 is releasing updates?
deanctoday at 3:10 PM
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.
lexojtoday at 3:17 PM
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 )
shevy-javatoday at 6:47 PM
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.
phplovesongtoday at 2:59 PM
This is pure gold. A critical vuln like this is such classic lolphp. Luckily you can port away from PHP pretty easily with AI.
ramesh31today at 2:05 PM
PHP runs literally half the web. Half the web will not apply this patch in any reasonable amount of time (a huge portion will never). This is going to be absolutely catastrophic.
cute_boitoday at 5:15 PM
> 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.
... every now and then until that 8.3.35 turns into 8.3.36.
So far, no dice.
varispeedtoday at 3:30 PM
Why they can't publish an expoit so people can run it against their own servers to check the impact?
louskentoday at 2:48 PM
where is patch for alpine?
jdw64today at 2:34 PM
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.
baggy_troughtoday at 1:59 PM
They bundled the fixes with a regular bugfix release, looks like.
deletedtoday at 3:56 PM
deletedtoday at 1:50 PM
sourcecodeplztoday at 2:45 PM
apt update
apt upgrade
Capricorn2481today at 4:17 PM
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?
deletedtoday at 4:24 PM
calvinmorrisontoday at 2:09 PM
debian package WHEN
Maxioustoday at 1:48 PM
[dead]
g147today at 5:38 PM
[dead]
georgestonestoday at 4:42 PM
[dead]
holnptoday at 3:50 PM
[dead]
hizlikovboy27today at 1:56 PM
[dead]
deletedtoday at 4:49 PM
gib444today at 7:57 PM
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
consociotoday at 4:36 PM
[dead]
holnptoday at 3:48 PM
[flagged]
EGregtoday at 2:10 PM
[flagged]
EGregtoday at 2:01 PM
[flagged]
bombcartoday at 1:49 PM
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.
magar_fostoday at 1:57 PM
C'mon Ondřej..
rvztoday at 2:16 PM
PHP is done.
gslepaktoday at 2:14 PM
If you're tired of having to upgrade Wordpress, point your agent at this tutorial:
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.
small_modeltoday at 2:22 PM
Does anyone use PHP anymore? I assumed it was abandonware
ameliustoday at 5:22 PM
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.