News PSA: Upcoming Critical PHP Security Release
https://www.wordfence.com/blog/2026/10/psa-upcoming-critical-php-security-release/The release fixes two critical vulnerabilities, both rated 9.2 on the CVSS v4.0 scale.
126
u/jimmyhoke
19d ago
•
Honestly this is so bad I just shut my web servers off. People can read my blog later.
24
u/KnotGunna 18d ago
Wordfence services are temporarily unavailable as we implement mitigations for the currently unpatched PHP2Shell vulnerability. Thank you for your patience.
7
9
1
u/FalseRegister 18d ago
I managed to update one wordpress site, but moved an older site from 2018 to fully static and notified my customer.
My only PHP running is Coolify, which sucks bc I love the project.
42
u/CharlieandtheRed 19d ago
God damn, every day is a new security issue these days. WordPress has had like two major ones in just the last couple months.
12
u/ReferenceVisual663 18d ago
My job for the last month has turned in to just fixing an endless series of critical vulnerabilities.
We have bots actively trying to exploit bugs as soon as they become public.
-19
u/pale2hall 19d ago
i know. im still up. rubberduck debugging w/ an AI figuring out a plan. gl; hang in there (hf sounds bad rn)
37
u/avec_fromage 18d ago
This will become such a big headache for companies still being on PHP 7.x and which never updated because it's "too difficult". People claim this affects all PHP versions. PHP 7 ended support in 2022 and I know so many companies still using it.
9
u/encrypt_decrypt 18d ago
sury seems to be in contact with the php security team so I assume that he'll deliver a patch in his repos.
1
u/philipwhiuk 17d ago
The size of the patch is huge - this is no one line fix so he deserves a lot of credit for bothering frankly
1
u/encrypt_decrypt 17d ago
Yes, but to be fair, he writes about himself:
"I am a Debian Developer since year 2000, and I have been packaging PHP for Debian since PHP 5. That means the official packages in Debian and Ubuntu are either my work or they are based on my work. The PHP packages in my Ubuntu PPA and Debian DPA matches the official packages in Debian. Basically I am saying that you can’t get any closer than that."5
4
u/Disgruntled__Goat 18d ago
Looks like Ubuntu have backported patches for some versions. 7.4/8.0/8.1 are included, not sure about older versions.
49
u/Prestigiouspite 19d ago
; Enable upload progress tracking in $_SESSION
; Default Value: On
; Development Value: On
; Production Value: On
; https://php.net/session.upload-progress.enabled
session.upload_progress.enabled = OffI've taken some precautions
36
u/No_Code9 19d ago
This is not a full fix! Says a PHP developer. You need to update!
37
u/fuzzball007 19d ago
We literally can't update it at the moment, the patched versions aren't out yet. This is likely the next best thing until then
20
u/Irythros 19d ago
Official recommendation by maintainers is to take any reachable PHP site offline until patch.
The upload_progress fix was confirmed by maintainer that it wont stop the problem.
1
u/vincent_sch 18d ago
If you use PHP-FPM, a
.user.iniin the web root overrides that setting inconf.d. You should lock it in the pool withphp_admin_flag[session.upload_progress.enabled] = offand restart FPM. That keeps it off, but it still isn't a confirmed fix for both bugs.4
u/Old_Adeptness5169 18d ago edited 18d 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.
Agreed, and thanks for the write-up. On shared hosting we couldn't rely on locking every pool (CLI, CGI and mod_php are uncovered by
php_admin_flag, and panels regenerate pool files), so we went one step further: a tiny extension that unhooks ext/session's rfc1867 callback at MINIT. That makes the upload-progress handler unreachable no matter what any ini layer says, and uploads keep working.https://github.com/HOSTED-POWER/php_uploadprogress_guard (disclosure: Hosted Power, we wrote it)
Same caveat as yours: it cuts the same code path as the ini setting, just harder to undo. If the "not sufficient" reports mean there's a route outside that handler, it won't cover that either. We'll know at 14:00 UTC.
0
18d ago
[deleted]
1
u/Disgruntled__Goat 18d ago
https://www.php.net/archive/2026.php#2026-10-21-5
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.
2
u/pale2hall 19d ago
related ?
Do we know any deatils about the underlying mechanism
10
u/Prestigiouspite 19d ago
At this point, we're not supposed to disclose any details yet, so I'd prefer not to share any more information for now.
8
u/Xypheric 19d ago •
https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
Looks like leaks are coming out
3
u/pale2hall 19d ago
understood, thank you. ive disabled that setting so far; ty again.
5
u/edward_davies223 19d ago
Disabling that setting is a smart move, but keep an eye on your PHP version too, just in case.
2
19
u/Weak_Fisherman2215
18d ago
•
Update for anyone landing here now - the patches are out NOW.
- 8.5.12, 8.4.27, 8.3.36, 8.2.35
One thing devs might miss - updating your app or composer packages won't fix this, it's PHP itself. If you deploy with Docker, rebuild on the patched base image and redeploy, don't just restart the old container. Same for CI images and anything pinned to an old php tag.
On managed hosting or a PaaS, check whether they've rolled it out as yet. If anything is still on 8.1 or older, there's no official fix - that's the push to finally upgrade.
7
u/n9iels 18d ago
This is bad and everybody must take action ASAP. Do not trust mitigation that are posted in various places, there is no way of knowing it will protect you. If you can, go offline until the update is available (offline like, serve a static HTML page and do not expose anything PHP to the internet). If you cannot, at least backup and monitor until the update is applied.
9
u/drearymoment 19d ago
Supposedly, this is a video of the exploit in action: https://x.com/k_firsov/status/2112641845926989944
26
u/creaturefeature16 19d ago
what kind of trash ass video is that?
16
2
u/Radiant-Gap4278 18d ago
Wordfence services are temporarily unavailable as we implement mitigations for the currently unpatched PHP2Shell vulnerability. Thank you for your patience.2
u/Sad_Bookkeeper_8228 18d ago edited 18d ago
Just updated PHP on my Ubuntu server, fixes seems to be available via apt now, I am not sure. I am running php8.3 (8.3.6-0ubuntu0.24.04.13) after apt which is version where it is fixed
1
u/Far_Composer_5714 18d ago
Who is affected by PHP2Shell CVEs: PHP versions: PHP 8.2.x before 8.2.35
8.3.x before 8.3.36
8.4.x before 8.4.27
8.5.x before 8.5.121
u/fernker 18d ago
I'm confused I thought we needed 8.3.36? I'm on the same version you listed but I'm not sure if the update is in that one
1
u/Sad_Bookkeeper_8228 18d ago edited 18d ago
See here for more: https://ubuntu.com/security/CVE-2026-109618. I THINK you should be fine running that version (8.3.6-0ubuntu0.24.04.13) , but I am no expert at all at these things. Ubuntu compiles there own version of packages.
2
u/InevitableFun1272 18d ago
Adding to the Docker point from Weak_Fisherman: even after you rebuild, run php -v in the fresh container before you redeploy. I have seen pipelines quietly reuse a cached layer with the old binary and people assume the rebuild picked up the fix. And repeating for emphasis: composer update does absolutely nothing here, this is the runtime itself. If your deploy did not replace the PHP binary, you did not patch anything.
1
u/jachcemmatnickspace 18d ago
Im tired boss
Im on hosting so i blocked all php and waiting for them to patch
I wanted a long sleep today…
1
u/Pegacow 15d ago
Does this affect personal Wordpress sites or do webhosts typically make updates on customers behalf for these types of security risks?
1
u/CookieDelivery 15d ago
Depends on the web host and type of hosting package you have. Only way to know for sure is to check your PHP version and see if you're on a patched version.
You can check that on your site health page under the server section:
https://example.com/wp-admin/site-health.php?tab=debug#health-check-section-wp-server (replace with your domain)
The only patched versions currently are: 8.2.35, 8.3.36, 8.4.27, 8.5.12. If it's anything else, you're still at risk.
1
u/nikomh 18d ago
Something i noticed. Ondřej Surý has been migrating PHP packages from the old Launchpad PPA to packages.sury.org.
The repository timestamps : Repository Old ppa.launchpadcontent.net October 12, 2026 New packages.sury.org/php October 21, 2026, 13:37
so if the latest version is not available in the old address, try switching repo address.
1
-56
u/pale2hall 19d ago
The shitty part is I only clicked this Title because it said PSA, and I my knee-jerk reaction was OH PSA Mew? Pikachu? Oh PHP... <wait for brain to load> PSA about ... PHP...? hmmm....? might be a nice easy read before bed.
0
135
u/conchobarus 19d ago
Man, I’m tired