Critical PHP updates

Hi, I'm testing this on a new server running AlmaLinux 9 with the latest DirectAdmin version.

When I run `da build versions`, I get:

Latest version of PHP 7.4: 7.4.33
Installed version of PHP 7.4: 7.4.33

I don't see any asterisk (*) indicating that security patches have been applied.

How can I verify if PHP 7.4.33 is actually patched? Is there another way to check?
 
I´m trying the update (debian 11) with custombuild, but I keep gettin errors like E: Failed to fetch http://security.debian.org/debian-s...krb5/krb5-multidev_1.18.3-6+deb11u8_amd64.deb 404 Not Found [IP: 2a04:4e42:82::644 80]

I've no idea why??

I'm not sure but I think nobody answered yet. Debian 11 is EOL, the files aren't available anymore. I just upgraded one of mine to 12 despite the fact my PHP did update but on it but on another box it didn't and I got more or less the same error. So imho best solution is to upgrade to v12 at least. LTS until 2028.
 
Hi, I'm testing this on a new server running AlmaLinux 9 with the latest DirectAdmin version.

When I run `da build versions`, I get:

Latest version of PHP 7.4: 7.4.33
Installed version of PHP 7.4: 7.4.33

I don't see any asterisk (*) indicating that security patches have been applied.

How can I verify if PHP 7.4.33 is actually patched? Is there another way to check?
See custombuild/patches/php-7.4/143-php-7.4-cve-2026-109618.patch

If this patch-file exists, the patch has been applied after a PHP re-build.
 
I wonder why DirectAdmin doesn't update the version numbering, as you also see in phpinfo(). Certain repositories seem to have been doing that for years.

Something like:

PHP Version 7.4.33 da-patch2026-109618​

 
I'd like to join the club asking for the patches for Centos 7.9 / DA 1.668 with PHP 7.3 (fpm) in my case. I've seen some workaround suggestions in this thread, but I'd really prefer an official fix via DA custombuild.

(and please, kindly spare me the "CentOS 7 is old / inplace upgrade asap etc." type comments, most users on here know that very well and have done that already for eligible servers, I'd just like to keep my legacy installs secure where upgrading the OS and apps is not an option).

You've done a fantastic job so far, really big big thanks 😎👌, but please consider to also issue a legacy patch, after the current turmoil has died down a little.
 
Apologies for the repetition but have any CloudLinux 8 users seen alt-php-* updates yet?
No, we've just raised a new ticket with them because their stable repos do not agree with their status page. Very poorly handled by them.

They've also broken their commitment to update every 30 minutes the status page advisory. Not impressed with their incident handling.

Seconds ago, they posted this correction:

Correction:
Our 19:00 UTC update said the first fixed CloudLinux alt-php packages were released.
Those packages went to the TuxCare ELS alt-php repository. CloudLinux 7, 8, and 9 servers install alt-php from the CloudLinux repositories, where the fixed packages are not available yet.

CloudLinux 10 servers install alt-php from the TuxCare ELS repository, and fixed alt-php 7.4 is confirmed there. Fixed ea-php packages for cPanel EasyApache 4, ea-php52 through ea-php85, are released. Imunify360 rulesets 8.84 and 8.85 add blocking rules, including on LiteSpeed.

Full details: https://blog.cloudlinux.com/php-cve-2026-109618-and-cve-2026-109619
 
Seems they screwed up according to the last update a few minutes after my post. Still not sure when they are releasing them, given the CloudLinux USP is security this is a shambles.
 
We have backported the new PHP patching sub-system to the RHEL 7 branch. A new build is pushed out to the rhel7 and debian10 legacy release channels. It comes with latest PHP versions and all security patches (not just the latest CVEs).

@Richpark yes, the one patch file is for both CVEs.
 
We have backported the new PHP patching sub-system to the RHEL 7 branch. A new build is pushed out to the rhel7 and debian10 legacy release channels. It comes with latest PHP versions and all security patches (not just the latest CVEs).

@Richpark yes, the one patch file is for both CVEs.

Thanks, can you confirm that both 109618 and 109619 have been patched, since the filename only references 618?
 
Back
Top