Critical PHP updates

There is no way to upgrade PHP. How to solve it temporarily?
If rebuilding isn't possible right now: our open-source extension mirrors the official fix on an unpatched PHP 5.4–8.5 without recompiling PHP. There's a prebuilt x86_64/arm64 .so per PHP version: copy it into that version's extension_dir (/usr/local/phpXY/bin/php -n -r 'echo PHP_EXTENSION_DIR;'), add a 20-hp_uploadprogress_guard.ini with extension=hp_uploadprogress_guard.so to /usr/local/phpXY/lib/php.conf.d/, restart PHP and check with /usr/local/phpXY/bin/php --ri hp_uploadprogress_guard. It steps aside by itself once a patched PHP is built.

Honest caveat: we haven't tested it under lsphp ourselves, so please do a test upload after installing. da build php as described above remains the real fix.
 
If rebuilding isn't possible right now: our open-source extension mirrors the official fix on an unpatched PHP 5.4–8.5 without recompiling PHP. There's a prebuilt x86_64/arm64 .so per PHP version: copy it into that version's extension_dir (/usr/local/phpXY/bin/php -n -r 'echo PHP_EXTENSION_DIR;'), add a 20-hp_uploadprogress_guard.ini with extension=hp_uploadprogress_guard.so to /usr/local/phpXY/lib/php.conf.d/, restart PHP and check with /usr/local/phpXY/bin/php --ri hp_uploadprogress_guard. It steps aside by itself once a patched PHP is built.

Honest caveat: we haven't tested it under lsphp ourselves, so please do a test upload after installing. da build php as described above remains the real fix.
It looks very cool.
 
Nobody knows what customisation you have. So we can not guide you on a way to save the customisation. Regular servers will get updated with the command:

Code:
da update
da build php

and if you used an official way to customize software/installation the suggested commands should not remove the customisation.
Sir The last PHP bug need to fix
 
First make sure you see patches for 5.6 and 7.2. using the command:

Bash:
ls -la /usr/local/directadmin/custombuild/patches/php-*/*-cve-2026-10961?.patch

Expected output:

Bash:
-rw-r--r-- 1 root root 19603 Oct 21 20:34 /usr/local/directadmin/custombuild/patches/php-5.6/173-php-5.6-cve-2026-109618.patch
-rw-r--r-- 1 root root 28416 Oct 21 20:34 /usr/local/directadmin/custombuild/patches/php-7.0/184-php-7.0-cve-2026-109618.patch
-rw-r--r-- 1 root root 28296 Oct 21 20:34 /usr/local/directadmin/custombuild/patches/php-7.1/186-php-7.1-cve-2026-109618.patch
-rw-r--r-- 1 root root 38460 Oct 21 20:34 /usr/local/directadmin/custombuild/patches/php-7.2/159-php-7.2-cve-2026-109618.patch
-rw-r--r-- 1 root root 38329 Oct 21 20:34 /usr/local/directadmin/custombuild/patches/php-7.3/139-php-7.3-cve-2026-109618.patch
-rw-r--r-- 1 root root 40315 Oct 21 20:34 /usr/local/directadmin/custombuild/patches/php-7.4/143-php-7.4-cve-2026-109618.patch
-rw-r--r-- 1 root root 40650 Oct 21 20:34 /usr/local/directadmin/custombuild/patches/php-8.0/138-php-8.0-cve-2026-109618.patch
-rw-r--r-- 1 root root 49737 Oct 21 20:34 /usr/local/directadmin/custombuild/patches/php-8.1/114-php-8.1-cve-2026-109618.patch

Then check

Code:
da build versions | grep avail

whether or not updates for PHP are offered.

If you see patches and no updates are available, then you are most likely secured.
Curious that PHP8.1 is in the list (or maybe not) as PHP8.1 also got an update during the initial DA patch release yesterday.
Which was way before the 20:34 time frame.

Just to be sure I reran the build for PHP8.1 down here.
 
If rebuilding isn't possible right now: our open-source extension mirrors the official fix on an unpatched PHP 5.4–8.5 without recompiling PHP. There's a prebuilt x86_64/arm64 .so per PHP version: copy it into that version's extension_dir (/usr/local/phpXY/bin/php -n -r 'echo PHP_EXTENSION_DIR;'), add a 20-hp_uploadprogress_guard.ini with extension=hp_uploadprogress_guard.so to /usr/local/phpXY/lib/php.conf.d/, restart PHP and check with /usr/local/phpXY/bin/php --ri hp_uploadprogress_guard. It steps aside by itself once a patched PHP is built.

Honest caveat: we haven't tested it under lsphp ourselves, so please do a test upload after installing. da build php as described above remains the real fix.
Can it be run on CentOS 6?
 
There is no way to upgrade PHP. How to solve it temporarily?
If you can not upgrade PHP, then please follow official instructions from PHP maintainers - 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.

RCE via OOM corruption (CVE-2026-109618):

Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable path.
Set a low post_max_size. For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.
Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

RCE via stale global state (CVE-2026-109619):

Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.
Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.
Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks, upload or import processing and cleanup.

The advisories linked above have the full technical details.
...
 
Back
Top