PHP2Shell on DirectAdmin: CustomBuild Rebuilds

As of 23 October 2026, DirectAdmin has released CustomBuild updates that build the fixed PHP 8.2 to 8.5 releases and add PHP2Shell patches for older versions, but its official changelog does not list them yet. Everything DirectAdmin has said is in staff posts on its community forum. Exploitation attempts are widely reported, confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The direct answer: DirectAdmin updates itself, but it does not rebuild PHP on its own unless you turned that on. On a server you manage, run da update and then da build php, restart PHP-FPM, and confirm every PHP version your sites use. If your site sits on a host's DirectAdmin server, the host does this, and our guide to PHP2Shell on shared hosting covers what to check.

PHP2Shell is the name for two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. This guide covers DirectAdmin and its CustomBuild tool.

Where DirectAdmin Stands

DirectAdmin has not published a security advisory page or changelog entry for PHP2Shell. When we checked on 23 October, its official changelog pages for versions 1.713 and 1.714 had no PHP item, and the 1.715 and 1.716 pages did not exist. The information comes from a staff member, "fln," in the forum thread "Critical PHP updates". Here is the timeline from that thread (post times converted to UTC):

No newer staff post had appeared by 23 October. Forum posts can be edited or superseded, so read the latest page of the thread before you act.

How CustomBuild Handles PHP

CustomBuild is DirectAdmin's tool for building and updating the web server, PHP and related software. Unlike panels that install prebuilt packages, CustomBuild compiles PHP on your server and applies DirectAdmin's patch files during the build. That has two effects. First, a DirectAdmin update alone doesn't change the PHP your sites run; PHP only changes when CustomBuild rebuilds it. Second, the fix for older PHP versions arrives as a patch file, so the version number stays the same.

CustomBuild settings live in one file. DirectAdmin's CustomBuild overview says "The configuration of CustomBuild is stored in the /usr/local/directadmin/custombuild/options.conf file." The PHP versions you run are set there as php1_release, php2_release and so on, and DirectAdmin lets several versions run side by side.

One detail matters for PHP2Shell. DirectAdmin's multiple PHP versions page says: "The first PHP version will be the default and will run all webapps." Its PHP page names those webapps as "squirrelmail, roundcube, phpmyadmin." So the version in php1_release serves your webmail and database tools. It needs the fix even if every customer site has moved to another version.

How to Patch PHP on DirectAdmin

These are the commands DirectAdmin staff and docs give. Run them as root, during a maintenance window.

1. Take a backup or server snapshot. Our guide to backups and recovery explains what a usable backup includes.
2. Update DirectAdmin and CustomBuild: da update.
3. See what CustomBuild wants to update: da build versions. DirectAdmin's docs describe this as the command-line view of the admin-level CustomBuild > Updates page.
4. Rebuild PHP: da build php. This rebuilds the PHP versions set in options.conf. To apply every pending CustomBuild update at once, the docs give da build update_versions.
5. Restart PHP-FPM for each version (next section).
6. Confirm each version (the section after that).

If a PHP 8.1 build fails, update again first. Staff reported the 8.1 compile problem and shipped "a small fix for the PHP 8.1 compilation" later on 21 October. If you can't get a fixed build in place, DirectAdmin staff direct you to PHP's own temporary measures, which are covered in PHP2Shell interim mitigations. Those are partial, not a fix.

Restart PHP-FPM, Apache and LiteSpeed

A rebuilt PHP does nothing until the processes that serve your sites restart. DirectAdmin's PHP-FPM page gives this form, with PHP 8.3 as the example:

systemctl restart php-fpm83

Replace 83 with each version you run, such as php-fpm82 or php-fpm84, and restart every one. If any site uses PHP as an Apache module (mod_php), do a full Apache restart rather than a graceful one. Apache's documentation doesn't say whether a graceful restart loads an updated PHP module, and vendor instructions use a full restart.

LiteSpeed needs extra care. Staff posted on 22 October that a new build "fixes the patching order on servers that use LiteSpeed web server. Before this fix patches would fail to apply when lsphp mode is used." If your server uses LiteSpeed and you rebuilt PHP before that build, update and rebuild again. Then restart PHP itself, because LiteSpeed's PHP runs in "Detached mode and will not be restarted when LSWS restarts." LiteSpeed's documentation gives pkill lsphp or touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt. Our PHP2Shell on LiteSpeed guide covers this in depth, and every restart method is in our guide to restarting PHP workers after a security update.

How to Confirm the Fix

How you confirm depends on the PHP version, because DirectAdmin fixed newer and older versions differently.

For the patched versions, staff gave this check for PHP 7.4: "if you have custombuild/patches/php-7.4/143-php-7.4-cve-2026-109618.patch file present and CB does not show update for PHP 7.4 it means you are up to date." Staff also explained that in CustomBuild's version list, "The versions with * symbol means PHP version is the same, but we added new patches for that particular PHP release." The patch file names for other versions may differ, so look in the matching custombuild/patches/php-X.Y folder.

Then confirm what your websites actually run. A temporary phpinfo() page loaded through each site shows the PHP that serves it; delete the file once you've read it. The command-line PHP can differ from the PHP-FPM version a site uses, so php -v alone is not proof. Our guide on how to check your PHP version covers each method, and the PHP2Shell version lookup tells you whether a given release is fixed.

Automatic Updates and Pinned Versions

DirectAdmin staff were clear: "DA will auto update by itself, but PHP upgrade needs to be triggered manually (unless CB cron feature is enabled)." DirectAdmin's upgrading services page describes two levels of automation. One checks for updates and emails you. The other installs them, set with da build set updates yes and da build cron. DirectAdmin adds a caution that "the server admin is still required to be fully aware of the system and its state if he sets the system to be auto-updated."

Check one more thing. The same page explains that "a file called custom_versions.txt" lets an admin keep an older version of any item CustomBuild manages. If someone pinned PHP that way, a rebuild can leave it on the old version. Look for that file in the custombuild folder and remove any PHP pin before you rebuild.

Old PHP Versions, Legacy Channels and Old Operating Systems

DirectAdmin's patches for PHP 8.1 and older close PHP2Shell, but those versions still get no releases from the PHP project. PHP 8.1 reached end of life on 31 December 2025, 8.0 on 26 November 2023 and 7.4 on 28 November 2022. Even PHP 8.2 reaches end of life on 31 December 2026. Use the patches to get safe today, then move sites to 8.3 or newer. DirectAdmin's docs show how to change a version: set the release, for example da build set php1_release 8.3, then da build php and da build rewrite_confs. Users can then choose among installed versions on their Domain Setup page.

If your server runs on an old operating system, staff said the new patching system was backported to the "rhel7 and debian10 legacy release channels." That keeps PHP patched on those systems, but the operating system underneath no longer gets regular security updates from its own project. Plan the move to a supported OS.

Some DirectAdmin servers also run CloudLinux's hardened alt-php packages. A forum user relaying CloudLinux's support said these are "not a CustomBuild option" and that "CustomBuild does not pick them up." If that describes your server, update alt-php through CloudLinux's own packages and confirm it with the changelog check CloudLinux publishes.

Settings That Still Matter After the Rebuild

On 23 October, PHP published an informational advisory for a third issue, CVE-2026-115560, which affects patched releases too. PHP suggests you "set session.upload_progress.enabled=0 until the next regular bugfix release," using "php.ini, an FPM pool or server configuration that applies before request parsing." It warns: "Do not rely on ini_set() or FPM .user.ini." On DirectAdmin, put the setting in the php.ini for each PHP version, then restart that version's PHP-FPM service.

Also look at per-directory PHP settings. DirectAdmin's PHP docs explain that "Only mod_php and lsphp read" php_value and php_flag lines from .htaccess files natively, while PHP-FPM needs the htscanner module to do so. PHP's own advisory for CVE-2026-109619 says per-request settings that produce warnings before a request starts are part of the problem, and tells admins to remove invalid or deprecated ones. Clean out old php_value lines that no longer apply.

Conclusion

On DirectAdmin, PHP2Shell is fixed by rebuilding PHP with CustomBuild, not by the panel's own self-update. Run da update and da build php, restart PHP-FPM for every version (and LiteSpeed's detached PHP if you use it), and confirm each version by its number or patch file. Fix php1_release first, because it also serves webmail and phpMyAdmin. Then move sites off PHP 8.1 and older. If you'd like someone to rebuild and verify the server with you, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions