Critical PHP updates

I hope there will be some sort of backport/patch for the 7.x series because the number of sites on 7.x without the ability to upgrade is probably unmeasurable.
 
adam12 said:
I hope there will be some sort of backport/patch for the 7.x series because the number of sites on 7.x without the ability to upgrade is probably unmeasurable.
Click to expand...
According to php at this moment, only 8.2 and above will get this. There are a number of backports from RHEL and ubuntu that would get updates, and hardened php with cloudlinux is an option. Custombuild though compiles older php versions manually and would not have any of these back ports.

We don't yet know where the issue is. If it is in php-fpm itself, servers with litespeed or openlitespeed may be unaffected, and potentially fastcgi wouldn't be. However this is all a guess. I know some users run ubuntu (no cloudlinux) but with imunify360. This doesn't officially support hardened php. I asked the imunify team and they told me

Code: 
 Hardened PHP is not a CustomBuild option. It comes as our prebuilt alt-php packages installed under /opt/alt/phpXX, and CustomBuild does not pick them up, so they do not appear in DirectAdmin's selector.
 
On a server without CloudLinux, a website can use a Hardened PHP version only through manual configuration. For example, with php1_mode=lsphp in CustomBuild, the version can be set per directory in .htaccess. This is the block for PHP 7.4:

<FilesMatch "\.(php4|php5|php3|php2|php|phtml)$">
SetHandler application/x-lsphp74
</FilesMatch>

This is set up outside DirectAdmin, so DirectAdmin's selector will not show or manage it.

Depending on how big the issue is, it may require patching the old sources directly.
 
Official PHP statement: https://www.php.net/index.php#2026-10-20-1
More info: https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities
Proof of concept: https://media.infosec.exchange/info...759/330/067/147/original/4e800fe72bfa6523.mp4

This leak can take over your server and a patch is not yet available. It seems that of proof of concept exists so we can assume this leak is being used in the wild. How will Directadmin handle the patch when it arrives? Does custombuild implement this patch automatically when it's available?
 
Hi all,

There is an advisory about two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, reportedly allowing remote shell access on all PHP versions. The advisory says the PHP project will release patched versions today and suggests setting session.upload_progress.enabled = Off as a temporary mitigation.


https://www.php.net/archive/2026.php
https://watchtowr.com/intelligence/php-cve-2026-109618-faq
https://cert.europa.eu/publications/security-advisories/2026-018


1. Can anyone confirm these CVEs are real, ideally with a link to the PHP advisory or NVD entry?
2. Has DirectAdmin / CustomBuild published anything about them, and will updated PHP builds be available as soon as upstream releases the fix?
3. For shared hosting, is setting session.upload_progress.enabled = Off in php.ini (or php.conf.d) enough? As far as I know this is a PHP_INI_PERDIR setting, so users can re-enable it via .user.ini or .htaccess depending on the PHP handler. Is there a recommended way to enforce it?

Environment: DirectAdmin + CloudLinux, multiple PHP versions.

Thanks!
 
samsepiol008 said:
There is an advisory about two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, reportedly allowing remote shell access on all PHP versions. The advisory says the PHP project will release patched versions today and suggests setting session.upload_progress.enabled = Off as a temporary mitigation.
Click to expand...
Seems that's not going to work: https://phpc.social/@Girgias/117476477429221001 unfortunately. We really have to wait for the patch.
 
ju5t said:
Be very careful with following advisories from untrusted sources.
Click to expand...
100% though we're a bunch of admins who are trying to avoid absolute turmoil in 4-5 hours time from now, if not sooner. It's a balance. :-)
At the moment, we're staring down the barrel of the largest PHP vulnerabilities in 20+ years (to my knowledge) on internet-facing servers.

ju5t said:
There's only one real workaround and that's taking your webservers offline.
Click to expand...
Especially given what's on the post from Gina Peter Banyard (PHP Foundation) on Mastodon, this does seem like sound advice.
It sounds like the hopes around it being limited to upload_progress are null and void, and likely to be far more critical than just that.

ju5t said:
As @Tristan said, changing your .ini does not help.
Click to expand...
It seems like the posts around this, relayed by @zEitEr for instance, are hopeful yet AI-driven by others trying to re-produce (unknown) issues.

​

 
Is a temporary patch or workaround possible? Perhaps by disabling certain functionality? I notice that in the Netherlands, for instance, security.nl has even taken its website offline as a precautionary measure...
 
brinkie said:
Is a temporary patch or workaround possible? Perhaps by disabling certain functionality? I notice that in the Netherlands, for instance, security.nl has even taken its website offline as a precautionary measure...
Click to expand...
set your php.ini session.upload_progress.enabled = Off
 
Last edited:
If this doesn't do much, then why are they suggesting to disable it.
Maybe they have to enable it first before they can abuse it again...

Kr
Dries
 
You must log in or register to reply here.
Back
Top