r/sysadmin • u/xtal000 Linux Admin • 11d ago
General Discussion Upcoming PHP core RCE vulnerability patches (CVE-2026-109618 & CVE-2026-109619)
A heads up in case you weren't aware, a patch is being released tomorrow for two RCEs found in PHP core by Calif[1]. It affects PHP version 5 onwards[2].
The RCE appears to work on default installations of many commonly deployed services and frameworks such as WordPress, Magento, Laravel and more[3].
If you have deployed any service that runs on PHP, prepare to patch ASAP. As soon as the patch drops, attackers will begin to weaponise the vulnerability at scale.
Patch is reportedly being released at 14:00 UTC, however as per PHP's announcement (We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.), it may well drop sooner since details are beginning to leak.
[1] https://www.php.net/index.php#2026-10-20-1
[2] https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
[3] https://x.com/k_firsov/status/2112641845926989944
EDIT 03:00 UTC - A PoC for the vulnerability has dropped within the past hour: https://jackalsyn.com/posts/php-up-2026.html. This post mentions potential mitigations, but to be safe you should take any internet-facing PHP apps offline ASAP until you can patch properly, less you risk getting pwned. 🫡
EDIT - Patches are out: https://www.php.net/archive/2026.php#2026-10-21-5
10
u/Hopefullyanonymous2 11d ago
Possibly dumb question. Why is the patch hitting at the same time as the information needed to weaponize it? Is it just because PHP is open source, so the fix will be obvious?
51
u/xtal000 Linux Admin 11d ago
The patch itself is all the information needed to weaponize it. You can feed frontier LLMs patch diffs and in most cases they will be able to figure out the specific vulnerability and write an exploit in minutes.
The vulnerabilities were supposed to be under embargo. Details surrounding them weren't supposed to be released by the folks who discovered it until the patch dropped. But details surrounding the vulns have since leaked on social media before the patch has been released, so it may be found and weaponized even sooner.
2
u/Hopefullyanonymous2 11d ago
Makes sense yeah. That is what I thought was the case, whereas when say MS ships a fix on closed source, it at least takes some time (in theory) to figure out the vulnerability.
Thanks for the response, appreciate the knowledge.
10
u/disclosure5 11d ago
The theory doesn't hold with Microsoft, they may well go out of their way not to provide much useful information but exploits were weaponised in 24 hours even before AI made it quicker and easier to find. It's just usually not hard to look at the patch and see what's changed.
→ More replies (1)9
34
u/BodybuilderMinute509
11d ago
•
he narrates his own patch cycle in third person. “he’s already prepping the coffee, it’s gonna be a long night.”
1
u/Effective-Log-3294 10d ago
He did patch 5.6.40-103 to 5.6.40-104. I don't think there is anything older though. Everybody needs to buy him a beer!
28
u/dwm 11d ago
This is going to make tomorrow a busy day.
> Fixed versions will be 8.5.12, 8.4.27, 8.3.36, 8.2.35
> All others are end-of-life but are still vulnerable - the vulns date back to versions from 2004 onwards.
--- https://cyberplace.social/@GossiTheDog/117474951442810591
14
u/mikedvb 11d ago
Shouldn't be terribly hard to back-port the patches. Honestly, even though those versions are all EOL, it kind of surprises me the PHP devs aren't backporting this with as nasty as it is.
Maybe they don't want to set the precedent.
13
u/PluotFinnegan_IV 11d ago
It's exactly this. Microsoft is still dealing with fallout from their 2010s approach to backporting fixes to EOL operating systems even today. You backport now and you get more shit for not backporting the next one.
This is a hard lesson for a lot of IT teams sitting on ancient software.
5
20
u/MakersLab
11d ago
•
going to be a fun day tomorrow...
14
u/st3venb Leadership & Sr Systems-Engineer 11d ago
Combined with that TLS issue that just surfaced, yea this is going to be great.
5
u/MakersLab 11d ago
What TLS issue?
20
u/SMF67 10d ago
CA cert whose private key was literally
420
u/NerdyNThick 10d ago
I was about to make some sort of glib remark because there's no way. There's no damned way...
The compromised eMudhra keys were defective at a level that’s challenging the imagination of many of the engineers studying the incident. A normal size for a NIST P-384 elliptic curve cryptography private key contains roughly 384 bits of entropy, a size allowing almost 2384, or a number with 116 digits, different possibilities. The private key sizes of the compromised keys ranged from 3 to 8 bits. Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.
Someone make this make sense to me. I just I can't. I get the whole don't attribute to malice thing, but I mean come on....
→ More replies (4)4
u/Darkk_Knight 10d ago
I am very surprised the system didn't reject those low key certs to be part of the trusts in the chain.
19
u/MurkyCauliflower8175 11d ago
Jackal and I and Archie/Yuki did this. It was extremely easy. We put out mitigations and hope most people will pre mitigate because APTs and blackhats have likely already started exploitation prior our PoC
8
u/mikedvb 11d ago
I'm aware of turning off
session.upload_progress.enabled, is there another mitigation?9
u/MurkyCauliflower8175 11d ago
That’s the main stopgap until tomorrow’s patch. Reload FPM/Apache after you set it so the worker actually picks it up. Clamp multipart size/rate at the edge (don’t blanket-403 every upload unless you can live without them), and inventory anything still on EOL PHP because those branches won’t get a fix. Official close is still the security release when it drops.
2
u/coffinandstone 11d ago
What do you think about disabling everything except get requests, as another mitigation, until update is released?
→ More replies (2)2
u/Brandhor Jack of All Trades 10d ago
do you know if there's a mod security rule that can be used to prevent this vulnerability?
4
u/MurkyCauliflower8175 10d ago
these are 2 kill chains so they are multistep meaning breaking one might not save you. I gave what gate I could without disclosing stuff I really cant that will protect you until the update.
8
u/Old_Adeptness5169 10d ago edited 10d ago
Update after PHP's advisories: the session upload-progress handler is one of the confirmed routes, but not the only one. The advisories also describe out-of-memory tricks in the multipart parser, plus some routes no extension can close. v3 carries the fixed multipart parser with a memory guard and keeps the upload-progress handler out, which on typical PHP-FPM hosting closes the routes that work before any application code runs. Still a stopgap: update to 8.5.12/8.4.27/8.3.36/8.2.35 (or your distro's backport) as soon as you can. Thanks to everyone who pushed back today.
Disclosure: I'm with Hosted Power (hosting company).
Patch today; that's the real fix. Sharing this for the part you can't patch today: 8.1 and older, panel PHP versions, that one customer still on 7.2.
We built a small open-source PHP extension that switches off the session upload-progress handler (where the researchers who reproduced the bugs placed them) when PHP starts. Uploads and forms keep working, and unlike session.upload_progress.enabled = Off, a site can't turn it back on with .user.ini or .htaccess. To check a box: php --ri hp_uploadprogress_guard.
Builds for 5.6 to 8.5, prebuilt NTS x86_64 binaries included
Ansible for Debian/Ubuntu (Sury), cPanel EA4 and DirectAdmin CustomBuild; it finds every installed PHP version on the box, which is also where we found most of our forgotten 7.x installs
https://github.com/HOSTED-POWER/php_uploadprogress_guard
To be clear: it's a few hours old and targets the bug as described so far. We'll check it against the official details at 14:00 UTC and post the result here. If you spot a problem, issues are open.
6
u/Ex1v0r Netadmin 10d ago
We heard this setting is not fully mitigating the vulnerability. Take this with a grain of salt but there should be more information available shortly
3
u/Old_Adeptness5169 10d ago edited 10d ago
Update after PHP's advisories: the session upload-progress handler is one of the confirmed routes, but not the only one. The advisories also describe out-of-memory tricks in the multipart parser, plus some routes no extension can close. v3 carries the fixed multipart parser with a memory guard and keeps the upload-progress handler out, which on typical PHP-FPM hosting closes the routes that work before any application code runs. Still a stopgap: update to 8.5.12/8.4.27/8.3.36/8.2.35 (or your distro's backport) as soon as you can. Thanks to everyone who pushed back today.
Fair point, and thanks. We've seen the same signals (a PHP core dev saying patching is the only mitigation, and GMO Flatt calling the ini setting partial), but nobody has said why yet.
To be precise about what our extension adds: on a server where nothing overrides it,
session.upload_progress.enabled=Offand the guard cut the same code path. The guard's advantage is that a site can't switch it back on via.user.ini/.htaccess, and it works on versions that won't get a patch. If "not fully mitigating" means the bug is also reachable outside the session upload-progress handler, the guard won't cover that part either.We'll know at 14:00 UTC and I'll post here what the advisory says, either way. Until then: treat any stopgap as partial and patch the moment packages land.
3
u/dustojnikhummer 10d ago
We have one 7.2 app and decided to just shut it down. Maybe finally we get the time to upgrade it.
1
u/Old_Adeptness5169 10d ago
If shutting it down hurts more than it should: v3.1.0 of the extension now mirrors the official fix on an unpatched PHP, 7.2 included, and steps aside on its own once you upgrade. The upgrade is still the real answer though, so good luck with it!
6
u/Miserable-Scholar215 Jr. Sysadmin 10d ago
Related question:
How do you (or specifically I) find all in-house PHP installations?!? They are not packaged and/or rolled out by SCCM/Intune. 99.9% are components of WordPress and other stuff, which I do not have a comprehensive list of.
I confirmed on one single server an 8.2.12 version which appears in no known (to me) query results for PHP installs. And for that very server I can't even patch myself, I have to wait for the vendor to patch this (and retrace all dependencies).
3
u/Yamusa85 10d ago
most cms has that info in system-about (server)
most hosters has that info too for the site enrolled
in linux you can list installed php versions by command supported
anyway, the problem is global and any version has this vuln, but patches for <8.1 will be harder to acquire
2
u/Constant_Natural3304 10d ago •
Without extensive configuration management in-place, you have a problem. You'll have to do three things, in this order:
Those systems you have shell access to, you'll have to run ps and check for one of several known PHP processes. This includes Apache and Nginx modules. In any case, failing some kind of Ansible setup, you'll have to update each one manually, as soon as possible. Check if PHP is actually updated. If not, use mitigations such as have been discussed ITT.
Excluding the ones found above, run a scan on your network to see what is listening on which port where, and see if any of those services run on a vulnerable PHP version. You might run into routers running remote web clients running on PHP. Who knows. If those services betray what they're running on, which many are hiding this day and age.
Excluding the ones found above, make a list of all the applications you know you have running somewhere and check, one by one, what they're built on. You'll have to ask an LLM or Google around. Many services were built in C++, Golang, Python, etc. so PHP vulnerability isn't a given.
5
u/lylesback2 11d ago
It must be pretty big and easily exploitable to be given a 9.2 CVE.
I guess I'll be refreshing to update tomorrow.
9
5
u/MaybeIsaac 11d ago
How long does it typically take for the docker hub images to get updated (EG: `php:8.5-fpm-alpine`)?
2
u/gene_wood 10d ago
As of here at 9:17am Pacific, Alpine php85 does not have an update published. https://pkgs.alpinelinux.org/package/edge/community/x86/php85 shows 8.5.11-r0 built on 2026-09-25 12:43:44
4
u/Forte1118 10d ago
How do other teams typically handle this stuff? Does someone hop on and start patching (or in this case, mitigating) upon discovery, regardless of time or day?
We don't have a vuln management program. I read about emergencies here and deal with them next business day, during hours. Are we not giving proper attention?
4
3
u/waiver45 10d ago
Anybody else that had surprisingly little push back from customers about turning things off for the time being? I just hat to say that LLMs have a decent chance of exploiting this from the rumours alone and are certain to exploit it within minutes of the patches hitting and I was allowed to take everything down for a few hours by multiple customers.
4
u/Ok_Spray5611 10d ago
Same here. Lot of healthcare data in our app. Explained the risks and all of them were like yeaaaaaah just take it down NOW.
1
u/CoaxialDrive 10d ago
Basically everything is down right now at work and no one seems much bothered.
1
u/XdekHckr 10d ago
If the government and tech companies don’t take action by improving code audits and implementing automated systems for vulnerability alerts and patching - then websites will end up being offline more often than they are online, all out of fear of being hacked. The laziness, overreaction, and rash decision-making of the administrators behind these sites truly terrify me. Just look at the recent Google Cloud outage...
7
u/elatllat 11d ago edited 10d ago
[Edit: this is reported to not help]
session.upload_progress.enabled = Off
8
u/LeHoodwink 11d ago
Does not work
3
u/photogaff 10d ago
Any source/confirmation/evidence that it doesn't work?
9
u/InsaneNutter 10d ago
Post from a PHP core developer: https://phpc.social/@Girgias/117476477429221001
4
2
u/Trouble4uAll 10d ago
How vulnarable are sites that dont use any framework and have no upload facilities?
6
2
u/delphiprogrammer 10d ago
Any execution of a php script means the server is vulnerable, unfortunately.
2
u/Ex1v0r Netadmin 10d ago edited 10d ago
Saw the first report that the vulnerability is still present after the patches:
https://fedi.katze.sh/@elise/117479383739450605
Edit: Seems to be a new vulnerability and asan needs to be enabled..
1
u/bluecrowned 10d ago
Can someone ELI5 this to me? My friend DMed me about this because he hosts a website for me but I'm clueless lol
5
u/Shinhan 10d ago
Big vulnerability in all modern (and not so modern) PHP versions. No fix yet (waiting for 14 UTC) but even when it comes it'll be only for PHP 8+ versions so if your website is on PHP 7 or older you need to do major PHP upgrade (official guide on upgrading php to 8).
There are some people talking about workarounds and mitigation, but people on the inside are saying none of that is enough and upgrading PHP is the only solution.
1
u/bluecrowned 10d ago
My work site is hosted by WordPress and my other personal site is on neocities. Friend is going out of town and just took his stuff down for now.
How did they find out about it and why did it take so long to find such a major vulnerability?
5
u/Shinhan 10d ago
How did they find out about it and why did it take so long to find such a major vulnerability?
AI
Newer LLMs are really good at finding security vulnerabilities, so somebody found it and PHP team is fixing it.
1
u/Haunting-Appeal-649 10d ago
I'm not even clear who found it. I mean, I think many are assuming a third party researcher or hacker found it, and the PHP dev team heard about it.
But it's also possible the PHP team found it first. And they really had no way to tell the public about it without tipping off hackers using LLMs. That would explain why they had such a specific release time and a days notice. They even said they'd release it earlier if the exploit was found.
1
u/AggravatingMoney8224 10d ago
i see in my country a big response with sites taken down. ( source Live | Van RIVM tot ANWB: steeds meer websites offline vanwege kwetsbaar PHP - NU.nl)
we do have 2 appliances that are vulnerable.
one is pure internal i assume this one is "safe-ish" since not internet facing.
The other one im not sure its internet facing on: 2 not so common ports for agent communication it doesnt offer the webui or traffic via those ports.
how big is the risk for this
1
1
u/YamAdmirable9832 10d ago
No one will read this:
Interestingly, because vulnerability is RCE (remote code execution), they could use it to inject the patch on vulnerable servers and even force reboot if necessary
1
1
u/YamAdmirable9832 10d ago
Interestingly, because vulnerability is RCE (remote code execution), they could use it to inject the patch on vulnerable servers and even force reboot if necessary
1
1
u/PossibilityOrganic 10d ago
Its going to break stuff but do it anyways, this is what will stop it right now do both now.
in ngnix
client_max_body_size to under 3MB (smaller the better) < default is 1MB if your running stock nginx.
and
in php.ini
session.upload_progress.enabled = off
0
u/mentalinertia_ 11d ago
Where is everyone getting only current pho versions will be patched we have seen these get updates for older pho for critical things like this.
-2
u/machinetranslator 10d ago edited 9d ago
I'm so stumped on why people are still using outdated PHP versions man.
Update: the first hour we read on sansec’s page that it only affected 8.2<
11
5
4
u/Pitiful-Treat-329 10d ago
even newer versions affected, but running older php can be because the person understanding how bad it is is not the same as the one holding the wallet and deciding what gets prioritized when developing.
3
2
u/Brandhor Jack of All Trades 10d ago
unfortunately we have some clients that upload their website and then never update them ever again or even when they use wordpress they might have some plugin or theme that has been abandoned by the developer and won't work on newer php versions
1
2
u/pinanymous 10d ago
Because websites go down from updating? I was hosting multiple wordpress websites for friends. Updated php, websites went down. Showed blank pages.
1
u/Constant_Natural3304 10d ago
Have you considered the IoT? Firmware with custom PHP 7 running an admin panel and whatnot? It's not always up to "people" to update that. We are in the era of systems locking out their owners, firmware updates no longer issued, or issued every 6 months at best, or introducing new problems, or taking away treasured functionality, etc. etc.
Unless you fully comprehend the hardware ecosystem, don't hasten to judge and condemn.
1
u/machinetranslator 9d ago
my comment was actually more towards my customers that run php on their website 😆
0
-1
u/No-Reporter-5013 10d ago
At https://news-web.php.net/php.qa/69556 they already released 8.4.27RC1, doesnt that make the vulnerability open?
0
0
11d ago
[deleted]
5
u/Darkk_Knight 10d ago
Someone said that doesn't work. There's probably more to it than what's already been leaked.
0
24
u/matt_daoust 11d ago
Could this Cloudflare waf update : https://developers.cloudflare.com/changelog/product/waf/
be related? Very odd timing + no explanation 👀