r/sysadmin • u/tankton • 12h ago
General Discussion PHP patch is now available
PHP patch is now avaiable https://www.php.net/archive/2026.php#2026-10-21-5
Get it while its hot :)
•
u/showbizusa25 11h ago
One thing I'd double-check after patching: is Apache or PHP-FPM actually running the updated version? I've seen people update packages and forget about the workers still running the old code. A successful apt upgrade doesn't always mean the running service is patched. Anyone checking the live processes too?
•
u/HanSolo71 Information Security Engineer AKA Patch Fairy 10h ago
It's why I hate the "Linux doesn't need to reboot".
Yes it does or you need to coordinate restarting services and killing old workers.
•
u/wwb_99 Full Stack Guy 8h ago
I always had "reboot server" on our patching runlist. Because of this, and also if something broke the server I would rather know in the maintenance window proximate to the error, not one weeks or months later.
•
u/HanSolo71 Information Security Engineer AKA Patch Fairy 8h ago
We can be friends <3
•
u/Caleth 8h ago
Oh oh can I join the group. I'm really ready to murder some clients that don't understand that reboots are needed despite the common wisdom.
•
•
u/SoilMassive6850 10h ago
Not to mention that things like livepatching dont have full coverage and not everything can be livepatched. It's just a stopgap to use outside regularly scheduled maintenance. I occasionally see some people assuming that its fullblown kernel hotswapping to a new version.
•
u/HanSolo71 Information Security Engineer AKA Patch Fairy 10h ago
Hot take: If your service can't survive reboots, you need to fix your service. Updates requiring reboots should not be scary.
•
u/showbizusa25 9h ago
Agreed. If a server can't handle a planned reboot, that's a bigger problem than the patch itself. I'd rather find that out during maintenance than during an actual outage. Do you guys test reboot recovery as part of patch validation?
•
u/HanSolo71 Information Security Engineer AKA Patch Fairy 9h ago
All of my home services, but my NAS and hypervisor, automatically update and install kernel patches and reboot without my intervention. I haven't logged in, in months because the first thing i do when setting up a service is restart the server like 10 times and make sure it comes up clean every time. If it doesn't, I work until it does.
•
u/showbizusa25 7h ago
That's a good way to test it. A service starting after a reboot is one thing, but do you also check that it's actually working and not just showing active in systemctl?
•
u/HanSolo71 Information Security Engineer AKA Patch Fairy 7h ago
I have Uptimekuma looking for health HTML responses.
•
u/showbizusa25 7h ago
Nice, that covers it. Do you have Uptime Kuma running separately from the servers it's monitoring?
•
u/HanSolo71 Information Security Engineer AKA Patch Fairy 7h ago
For some services, I only have one giant VM host but I run uptimekuma as it's own VM. I'm fact every service is a dedicated VM, I don't believe in containers when I can avoid it.
→ More replies•
u/Breezel123 9h ago
That's exactly why I turned off our server for the night. Not because I can't be arsed to figure out what needs to be done this late in the day (in my timezone). If it's good enough for the Asana admins it's good enough for me.
•
•
u/rujopt NetSec Lackey 10h ago edited 10h ago
Excellent recommendation and reminder. I see that critical patching step skipped far too often.
That’s one of the reasons why all my Debian or Ubuntu servers get the needrestart package installed to automatically assist with this step for identifying & restarting outdated running processes post apt upgrade:
Manpage: https://manpages.debian.org/stable/needrestart/needrestart.1.en.html
Project home: https://github.com/liske/needrestart
(Edit: fixed broken Debian manpage link)
•
u/PsychologicalFlan877 10h ago
needrestart is the right call, and the process it usually catches for me is php-fpm itself. The package updates fine and everything looks patched, but the FPM workers keep serving from the old binary until the pool actually reloads. Now I check the worker processes after every PHP update, not just the package version.
•
u/showbizusa25 9h ago
Good call on needrestart. I'd still verify the PHP-FPM workers afterward, especially on production boxes. Do you have needrestart automatically restart services or just report what needs restarting? Curious how others handle that during patch windows.
•
u/rujopt NetSec Lackey 5h ago
A mixture of both, but the majority are automatic.
Non-critical servers get automatic service restarts. Critical (and brittle) servers are reporting only, then handled like the maddeningly special little snowflakes that they are.
I very narrowly scope what’s considered critical or special one-off servers / services. That can be a whole battle with business owners in and of itself. *Le sigh*
•
u/showbizusa25 3h ago
Haha, the real challenge is convincing business owners that not every server is critical. Sounds like you've got a good balance.
•
u/Haribo112 9h ago
Upgrading php-fpm does restart the workers automatically.
•
u/showbizusa25 9h ago
True, normally it does. But do you trust the restart alone, or do you also verify the running processes afterward?
•
u/shelfside1234 12h ago
And here ends my life for at least the next 2 weeks
•
u/ilogik 9h ago
2 weeks? kiss those sites goodbye if it takes 2 weeks to patch :)
•
•
u/shelfside1234 8h ago
External sites will be fine and patched overnight; the intranet sites will drive me insane
•
•
u/lordkuri 12h ago
Full text of the announcement, including mitigation strategies:
Security advisory: Critical remote code execution vulnerabilities, update now
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP users are strongly encouraged to update immediately.
Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.
The vulnerabilities:
RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): 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.
RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
How to update:
Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Source downloads are on our downloads page. Windows source and binaries are on the same page.
Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version.
If you rely on the volunteer-maintained rpms.remirepo.net, we urge you to switch to distribution packages or build from source, so you can immediately apply updates. The repo will not have updates today.
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.
If you cannot update immediately: while only an update is a complete solution, the following measures reduce exposure to specific attack paths but do not make an installation safe.
RCE via OOM corruption (CVE-2026-109618):
Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.
RCE via stale global state (CVE-2026-109619):
Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.
The advisories linked above have the full technical details.
•
u/Glad-Locksmith-4136 10h ago
As a temp solution you can proxy through cloudflare who are actively blocking this exploit
•
u/bron_101 9h ago edited 8h ago
Finally managed to get the patch deployed everywhere and services reenabled... what a shitshow. Various repos and mirrors getting flooded with requests and timing out made things worse.
I do think that the whole responsible disclosure process needs rethinking in the AI era. How long do we have now until AI agents start using new attacks? 15 minutes? It takes longer than that for patches to get seeded through mirrors, let alone actually deployed. We were ready and waiting for the patch and it still took us an hour or two to get it fully deployed.
When you get these kind of remote RCE in major very widely used services, I'm starting to think the only safe thing to do is shutdown services until patching is done. Before you could rely on attackers needing to get human eyes on the patch, figuring out the problem and spend a while writing exploit code. Now you can point your local unrestricted llm AI agent at PoC code and disclosures, and within minutes you have automated attacks going - worse, automated attacks with intelligence that allows figuring out maximum damage/value and chaining to other targets.
Lets not even talk about what happens if you get leaks that even vaguely hint at the issue, people send their AI tools to find the issue, and either partially (like today) or completely find the issue before a patch is even available.
Damn this has been a long day.
•
u/MattAdmin444 9h ago
I kind of feel like it's a toss up. Forward notice means both sides can prep but only finding out when the patch drops means potential victims are likely on the back foot compared to AI bots ready to roll as soon as the patch is live. Places usually don't update as soon as a patch is live no? Usually would go through rounds of testing/validation?
•
u/bron_101 8h ago
I was thinking more that the advice needs to shift from 'be ready to patch at 2pm UTC' to 'Consider if you should shut down your services at 2pm UTC until patched'.
Regarding testing - we judged that this was too high risk to not patch immediately. Actually, we shut down when rumours started flying about active exploits in the wild. Our service contains highly sensitive personal and medical data, and given risk of our application being targeted, compromised and data exfiltrated meant we felt there was no choice but to proactively shutdown, even though it caused services to be cancelled today and real knock on effects to people's lives.
If it wasn't for the leak giving enough information for people to find and possible even exploit the issue (i'd really like to know what cloudflare was seeing, their CTO tweeted that they were seeing attacks, that was what made us decide to shutdown) it wouldn't have been anywhere near as bad. We could have mitigated things such that the impact to our services were much less, but this whole incident has generally felt to us like a wake up call that things are different now in the AI era.
•
•
u/Reworked 8h ago
The estimates I've been seeing for time between patch and attacks, from the postmortem of the early release, were 15 minutes yeah. That was the reason for the intended coordinated disclosure and patch deployment.
•
u/bron_101 8h ago
Yeah, good luck getting patches done in 15 minutes. Maybe we need some kind of encrypted pre-seeding process where encrypted patches are distributed, then keys released with the disclosure.
•
u/AdventurousSquash 5h ago
I don’t know what kind of patching strategy you use. It took exactly 17 minutes between my colleague asking for a PR review on our playbooks and having everything patched and verified. Sure, the time window is getting smaller but our tools are also getting better.
•
u/Connect_Shoulder_965 8h ago
Why aren't these patches/vulnerabilities prepackaged up by the security vendors and patching systems? The vulnerability hasn't even made it into the Tenable or Tanium scans yet, taking up to 24 hours to release this makes it a lot more difficult to identify vulnerable systems and close the gap.
•
•
u/Jkabaseball Sysadmin 11h ago
We use Azure App Service. We will upgrade when Microsoft tells us we can upgrade.
•
•
•
u/Glum-Freedom-8414 12h ago
Hello, my company still runs on php 5 anything we can do ?
•
u/Knukun 12h ago
put your company offline, then pay someone to migrate to PHP8.3, good luck
•
u/sylvester_0 6h ago
If someone's doing the work to migrate from something that old, they might as well get to the latest version (8.5) so they have a longer EoL.
•
•
u/lordkuri 11h ago
Cloudflare's WAF has rules to mitigate this, but that's not a "solution", that's "buy time to get shit upgraded finally".
•
u/nathanielban Sysadmin 11h ago
I mean, there have been a ton of exploits since whenever you last updated your server (Presumably Pre-2020) the issue is that upgrading is going to require a lot of steps because of breaking changes in both PHP and presumably MySQL since then. I did this for a customer in 2024 and it took me over a week of work to patch their bug ridden spaghetti code because the previous developer was long gone.
•
•
u/thortgot IT Manager 12h ago
Put it behind your auth immediately.an app proxy or similar solves the immediate issue.
•
u/doubled112 Sr. Sysadmin 10h ago
I run everything possible this way for reasons. This is one of those reasons.
•
•
u/RandyCoreyLahey 10h ago
source for this to ease my mind? we have a windows server reverse proxy and i'm a small team sysadmin that doesnt really understand php or can keep with everything all the time.
•
u/thortgot IT Manager 2h ago
An unauthenticated proxy doesnt help you. Something like Azure App Proxy does.
You hand off your auth to a trusted source and then only authorize traffic from logged in users.
Reduces your attack surface from everyone to just users.
•
u/jackboy900 7h ago
I'm not sure if there's anything unique to this specific issue but generally if a service is behind a reverse proxy that only lets through authorised traffic it's not a visible target for most threat actors, they'd need to get past the proxy before doing anything and most generic attackers aren't going to bother. This is mostly an issue for websites running PHP that are on the open internet, which is obviously an absurdly massive affected population but it's not a 5 alarm fire kind of concern if that's not you.
•
•
u/Daniel15 8h ago edited 6h ago
If you use Ondřej Sury's Debian repo, he's backported the fix to older versions including PHP 5.6.
Otherwise, your company could build their own version of PHP with the backported patch, or pay for PHP LTS by Freexian.
•
•
u/Dizzy-Technician4580 5h ago
you probably have endless unfixed security vulns, stop being unc and have ur company upgrade to newest PHP with fixes.
•
•
u/throwawayPzaFm 8h ago
Your options are somewhere between shutdown -h now and having ChatGPT backport a patch.
But if you're running on 5 I really don't think today is that special, you probably already have 50 major vulnerabilities and may well have been promoted to a C2 by now.
•
•
•
•
•
•
u/Blackie1077 12h ago
Anyone else getting 49kB/s
•
u/lordkuri 12h ago
It just went live a few minutes ago, I can pretty much guarantee that they're getting swamped.
•
u/d_to_the_c Sr. SysEng 8h ago
Now to get software vendors that bundle it to their application to update....
•
u/Dependent-Spite-7787 9h ago
Would be nice if AWS would put the 8.2.35 patch in the distro channel. Still showing 8.2.34-1.amzn2023.0.1 as the latest. No fears, this is fairly simple website that I just converted to static and migrated into S3 behind cloudfront. The one thing I am happy to use cluade/vscode to do quickly.
•
u/the-cock-slap-phenom 11h ago
Sury updated their repo to move away from launchpad not that long ago, you can grab the new repo address from the launchpad overview.
It’s on the sury.org domain and the patches are available on there.
•
u/david455678 9h ago
Any idea when the update will be available on Ubuntu over apt?
•
u/PaintDrinkingPete Jack of All Trades 8h ago
If you installed PHP from the default Ubuntu repos, it's already been patched and available to update via apt:
https://ubuntu.com/security/CVE-2026-109618
If you installed via Ondrej PPA, follow the instructions in this Reddit thread if you're not on Sury repo yet.
•
u/xxscrublord69420xx 9h ago
Switch to sury repo from launchpad, this is the way it is moving forward anyway, ie migration is in progress. Check below commands and that the correct packages are available for you before running*, worked for me.
sudo rm -f /etc/apt/sources.list.d/ondrej-ubuntu-php-*.list curl -fsSL https://packages.sury.org/php/README.txt | bash
•
u/Chill_Squirrel 9h ago
So glad I'm currently on sick leave - partly because I'm noticing first signs of burnout, I wonder why 🫠
•
u/futurama08 12h ago
How do you get the .deb file?
•
u/Haribo112 12h ago
Use ondrej sury repo, like the rest of us.
•
u/futurama08 12h ago
I am? It's not there.
php8.5-fpm: Installed: 8.5.11-1+ubuntu22.04.1+deb.sury.org+1 Candidate: 8.5.11-1+ubuntu22.04.1+deb.sury.org+1 Version table: *** 8.5.11-1+ubuntu22.04.1+deb.sury.org+1 500 500 https://ppa.launchpadcontent.net/ondrej/php/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status
•
u/the-cock-slap-phenom 11h ago
Change from the launchpad repo, there’s a newer repo address that has the patches.
If you go to the launchpad site in browser then you’ll see a message about it in the description of the overview. It’s on the sury.org domain.
I don’t want to link it in case it gets removed, and you shouldn’t trust me anyway so grab it from launchpad overview.
•
•
u/fp4 11h ago edited 11h ago
tons of builds in progress right now:
https://launchpad.net/~ondrej/+archive/ubuntu/php
remove ondrej: sudo add-apt-repository --remove ppa:ondrej/php
switch to sury: https://packages.sury.org/php/README.txt
•
u/Visible_Spare2251 11h ago
ok good, not just me
•
u/futurama08 11h ago
how tf did this repo not get the update ahead of time and put it on a global cdn...
•
u/thenickdude 9h ago
Sounds like the disclosure time got brought forward, so they didn't have enough time to complete the builds.
•
u/Haribo112 11h ago
Hmm not sure. We use Debian. The patches for all php versions were present at 15:50 CEST
•
•
•
•
•
•
u/ilikerdjr 11h ago
Cannot find synology anywhere (home stuff dont judge)
•
u/OkDimension 8h ago
It will probably take a few days until Synlogy has tested the update and will roll out to all customers. So isolating would be the appropriate response until then.
•
•
u/Middle_War_9117 8h ago
reports of 8.5.12 not being fixed
https://fedi.katze.sh/@elise/117479383739450605 supposedly something new and not the same but keep it in mind
•
u/fattes 11h ago
Any idea on getting this updated via WAMP Server? Latest update shows 10/14 which doesn't cover the updated versions.
•
•
•
u/TheOnlyKirb Sysadmin 9h ago
Ah yes. I'll have to do it manually because launchpad seems to have died
•
•
•
u/dfreeezzz 9h ago
I'm a complete novice when it comes to this stuff. But we have a website that is hosted on a server that we are paying for. From the control panel it reads, that our current PhP version is 8.4. But there is no option to upload this Patch File manually.
I can connect to the server via SFTP. And I have access to MyPhPAdmin. Could you guys help me understand how I can implement this new patch for our website?
•
•
u/LinuxJeb 9h ago
Do you not have SSH access to the server? If you don't, contact your hosting provider.
•
u/dfreeezzz 9h ago
i just connected to my server via SSH. it says the current version is 8.4.27. So do I need to update to PHP 8.5.12?
•
•
u/eri- Enterprise IT Architect 9h ago
Im just not feeling it, somehow. This whole thing feels artificial , designed to be a media crysis.
There is way too much to do about an as of yet unexploited cve. The response is all over the place also, the one consistent thing seems to be panic. In an industry which does this stuff for a living.
Hardly a single in depth thought to be found, its all "shut it down now or you'll burn". Well ... It certainly is more nuanced than that where is all the nuance.
•
u/sarosan ex-msp now bofh 9h ago
The details about the vulnerability leaked yesterday.
A few researchers already figured out the exploitation path.
•
u/Daniel15 9h ago edited 8h ago
The PoC didn't work for a bunch of people, myself included. The successful exploits have been on Apache, so maybe it doesn't work on Nginx? Not sure.
Edit: From Ondřej Sury, who maintains Debian packages for PHP:
PSA on the “jackalsyn” PHP RCE PoC doing the rounds (php-up-2026.tar.gz): I’ve gone through the bundle. It is not a validated working exploit for CVE-2026-109618 / 109619 — it’s unvetted, looks LLM-assembled, and by its own README a wrong offset just faults a worker (DoS, not RCE). Treat the tarball as untrusted; don’t run a “weaponized” archive someone served over plain http.
•
u/DevelopersOfBallmer 9h ago
I would say the issue is how wide of a scope the issue is. Something like 63% of the web runs on PHP. Usually the vulnerabilities are application based and limit the scope and not platform. In this instance it's a major platform vulnerability and it does not require server access.
This also includes many hardware/application vendors, for example, PFSense uses PHP.
•
•
u/unknhawk 7h ago
Would this issue have happened if PHP was created using a memory safe programming language?
•
u/ShellHunter Jack of All Trades 12h ago
Meanwhile my company refusing to update most of our apps from php 7.3...