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?
 
dedd said:
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??
Click to expand...

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.
 
Drakar said:
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?
Click to expand...
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.
 
nathany said:
Apologies for the repetition but have any CloudLinux 8 users seen alt-php-* updates yet?
Click to expand...
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
Click to expand...
 
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.
 
fln said:
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.
Click to expand...

Thanks, can you confirm that both 109618 and 109619 have been patched, since the filename only references 618?
 
CloudLinux have now released alt-php## updates for CL7/8/9 and have provided these steps. CL10 update is per normal via dnf.

Fixed alt-php packages for CloudLinux OS 7, 8 and 9 are available now in the ELS ALT PHP repository. To install them, add the repository and update alt-php using the steps below. CloudLinux OS 10 already receives alt-php from this repository and only needs a regular update.

CloudLinux OS 7, 8 and 9
1. Make sure the server is registered with CLN (this file must exist):
ls /etc/sysconfig/rhn/jwt.token || rhnreg_ks --activationkey <YOUR-KEY> --force

2. Add the ELS ALT PHP repository:
CloudLinux OS 7: yum install -y els-php-release
CloudLinux OS 8, 9: dnf install -y els-php-release

3. Keep regular updates working even if the repository becomes unreachable:
CloudLinux OS 7: yum-config-manager --save --setopt=php-els.skip_if_unavailable=true
CloudLinux OS 8, 9: dnf config-manager --save --setopt=php-els.skip_if_unavailable=True

4. Check access to the repository (the output must include "Metadata cache created"):
CloudLinux OS 7: yum --disablerepo='*' --enablerepo=php-els makecache
CloudLinux OS 8, 9: dnf --disablerepo='*' --enablerepo=php-els makecache

5. Update alt-php:
CloudLinux OS 7: yum update -y 'alt-php*'
CloudLinux OS 8, 9: dnf upgrade -y 'alt-php*'
Click to expand...
 
Last edited:
Sebastian said:
CloudLinux have now released alt-php## updates for CL7/8/9 and have provided these steps. CL10 update is per normal via dnf.
Click to expand...
I've no idea what CLN are playing at with their updates. The haven't increased the PHP version

Code: 
[23:44][root@XX ~]# rpm -q --changelog alt-php82-common | grep -E 'CVE-2026-(109618|109619)'
- CVE-2026-109618, CVE-2026-109619: security hardening in the memory allocator,
[23:44][root@XX ~]# rpm -qa | grep alt-php82-common
alt-php82-common-8.2.34-7.el9.x86_64
 
Hi, I am running 'da build php' but it generates build errors.

Code: 
collect2: error: ld returned 1 exit status
make: *** [Makefile:357: sapi/litespeed/php] Error 1
install_php: failed to compile '/usr/local/directadmin/custombuild/cache/php-8.2.35.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.RMl8GFIGwc.php-8.2.35.tar.gz'
 
fln said:
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.
Click to expand...

It seems to be problem with PHP 8.0 patch on EL7:
patch_dir_apply: failed to apply '/usr/local/directadmin/custombuild/patches/php-8.0/131-php-cve-2026-7258.patch' patch
 
MattJW said:
I've no idea what CLN are playing at with their updates. The haven't increased the PHP version
Click to expand...
They have just said this, to that end:

Our packages carry the fix as a backport, so their version numbers stay below PHP's (for example, ea-php84 is 8.4.26, not 8.4.27).

Look for the CVE IDs in the package changelog instead:
rpm -q ea-php84-php-cli --changelog | grep -E "CVE-2026-(109618|109619)"

Security advisory metadata (OVAL and UpdateInfo) is not published yet, so security-only updates such as yum --security do not list these packages.
Use a regular update, as shown above.
Click to expand...
 
How i really know if i'm patched or not?
I already execute the da update + da build php.

I can see the follow patch on most of versions of PHP

cve-2026-109618.patch
Click to expand...

That's mean that i'm "safe/patched" or do i need to do another procedure?
 
You must log in or register to reply here.
Back
Top