Critical PHP security release for 21 Oct 2026 14:00 UTC

adil

php.net announced a critical PHP security release for 21 Oct 2026 14:00 UTC
(2 CVEs, CVSS 9.2): https://www.php.net/archive/2026.php#2026-10-20-1

@Adam Does enhance plan to release this ASAP ?

Adam

Once php.net release their patches, we will release updated PHP packages for Enhance.

Bear in mind they are unlikely to release patches for EOL versions. It's possible we might be able to backport the patch but this will take longer.

Enhance doesn't run PHP as root and no PHP is used in Enhance itself. Any RCE would be limited to the scope of the individual website container but of course it could be chained with an LPE vulnerability - make sure your kernels are up to date.

pratik_asabe

Adam This is the exact reason i was against using EOL versions many months back, and also told why cloudlinux is able to do it and we can't, because they (cloudlinux) use hardened versions, enhance has to divert resources to do so and imo its not worth it..

ordinary

Adam The control panel server runs Roundcube and phpMyAdmin? On our cluster both are on PHP 8.1.

Powie

@Adam This will not be a regular PHP security update. The PHP team has already decided to move the release of the fixed versions forward. The CVEs have not been published yet, but they will likely carry a CVSS 3.1 and 4.0 score of 10.0.
It does not matter whether PHP runs as root.
This is genuinely extremely urgent.

Powie

@adam if you are interested, send me an PM for more informations, they cannot be published here at this time

Adam

We have the PoC. It looks like setting session.upload_progress.enabled to 0 or Off in php.ini is a mitigation for at least one of the vulnerabilities. I would recommend doing this across your cluster unless you specifically need it enabled. You can do this right now without waiting for the php update to be released.

tstrand

Should we set this in Home / Settings / Service / Application / php.ini ?
Or do we have do go through every site manually?

Adam

tstrand

You can set it there. There is no guarantee that this protects against both vulnerabilities.

presswizards

As Adam mentioned, the proof of concept exploit script has been made public, and so waiting for PHP updates may be a bit too late.

Based on the scripts I've reviewed, adding the mitigating PHP directive is relatively simple in Enhance, go to Server > Application > PHP Settings > Add Directive button. I was able to deploy it per-server to protect all sites on each server:

session.upload_progress.enabled then choose BOOLEAN then choose Disabled

Click Save, and apply that to each App server.

Also, I'm adding a specific Cloudflare WAF block rule:

http.request.method eq "POST" AND http.request.body.raw contains "PHP_SESSION_UPLOAD_PROGRESS"

I saw Cloudflare's new emergency managed WAF rule was just released, but it's not yet clear if that is specific to this issue or not, and I'm not waiting around to find out.

More details for those interested: https://presswizards.com/critical-php-vulnerabilities-what-website-owners-need-to-know-and-do-now/

presswizards

UPDATE: but that is not enough, the part 2 needed, it blocks multipart uploads, and must be done in nginx:

if ($http_content_type ~* "^multipart/form-data") { return 403; }

or Apache:
<If "%{HTTP:Content-Type} =~ m#(?i)^multipart/form-data#">Require all denied</If>

From what I've reviewed, both together hopefully squash the vulnerabilities.

You can also create a custom Cloudflare WAF BLOCK rule:
http.request.method eq "POST" and (http.request.body.raw contains "PHP_SESSION_UPLOAD_PROGRESS" or starts_with(lower(http.request.headers["content-type"][0]), "multipart/form-data"))

I saw Cloudflare's new emergency managed WAF rule was just released, but it's not yet clear if that is specific to this issue or not, and I'm not waiting around to find out.

More details for those interested: https://presswizards.com/critical-php-vulnerabilities-what-website-owners-need-to-know-and-do-now/

Powie

https://news.ycombinator.com/item?id=50172041

Adam

[unknown]

Those just run as ordinary websites, they have no privileged access. But you're right that they are potentially vulnerable too.

ordinary

Adam Thanks Adam. I've used the "block all IP addresses" setting on both roundcube and phpmyadmin sub-domains. We don't host mail and I doubt any of my clients would need to access phpmyadmin.

Powie

Adam ADAM, this is an RCE, its unimportant if they have privileged access or not. RCE -> Run Code on the System........

mike

less than 8.2 will not get patched ? .. this will be a shit show..

Powie

mike

good for enhance ..... bad for plesk :

Adam

Please see https://community.enhance.com/d/3896-enhance-12261-and-php-cve-2026-109618-or-cve-2026-109619 for updates.