How to Update PHP on cPanel, DirectAdmin & CloudLinux

To update PHP safely, patch every PHP installation that serves your websites—not simply choosing a different version in the hosting panel. EA-PHP, CloudLinux Alt-PHP and DirectAdmin CustomBuild can coexist with separate executables, extensions and running workers.

Applies to RHEL-family DNF 4; EA-PHP and CloudLinux Alt-PHP; current DirectAdmin CustomBuild; LiteSpeed detached PHP

Short answer: identify the active PHP binaries, review the vendor advisory and proposed transaction, confirm a usable backup, apply updates through the package owner or CustomBuild, recycle the affected workers using the documented method, then test the actual websites. A successful CLI version check alone is not enough.

Scope and evidence: reviewed against vendor documentation on 22 October 2026. RPM/DNF examples below target RHEL-family hosting systems using DNF 4. They are not commands for Ubuntu or Debian package installations. The Vega case study is supplied production evidence (cPanel, CloudLinux, LiteSpeed). The DirectAdmin CustomBuild steps were run on our DirectAdmin 1.712 lab server on 22 October 2026; the other general procedures were checked against vendor documentation, not executed on a production server while preparing this guide.

Choose the correct update path

Installation	Identify it	Update through	Separate decision
cPanel EA-PHP	ea-phpXX-*; /opt/cpanel/	EasyApache 4 / its approved package repositories	Domain version and handler in MultiPHP Manager
CloudLinux Alt-PHP	alt-phpXX-*; /opt/alt/	CloudLinux repositories and applicable entitled ELS repository	User version/extensions in PHP Selector
DirectAdmin CustomBuild	/usr/local/phpXX/; options.conf	CustomBuild for the configured branch	Domain PHP selection
Standalone LiteSpeed/OpenLiteSpeed	Configured external application and executable path	That executable’s package repository or build owner	Web-server handler mapping and worker recycling

Do not change package families to fix a patch problem. Installing the operating system’s php package does not replace the PHP binary selected by cPanel, CloudLinux or DirectAdmin. LiteSpeed is the web server; it does not identify which PHP distribution needs the patch.

Inventory and rollback readiness

Use a root/admin shell only on a server you administer. Keep an independent console available. Before maintenance, confirm the backup can restore the application database, files, PHP configuration and required extensions together. Record the selected versions and handlers so a later application failure is not confused with a version-selection change.

Read-only checks:

cat /etc/os-release
uname -r
hostnamectl

test ! -x /usr/local/cpanel/cpanel || /usr/local/cpanel/cpanel -V
test ! -x /usr/local/directadmin/directadmin || /usr/local/directadmin/directadmin v

systemctl is-active httpd nginx lsws openlitespeed
rpm -qa | grep -Ei '^(ea-php|alt-php|php[0-9]|lsphp)' | sort
dnf repolist --enabled
ps -eo pid,user,comm,args | grep -E '[l]sphp|[p]hp-fpm'

An inactive or missing service is not automatically a fault. Identify the stack actually serving requests. These RPM checks do not inventory source-built CustomBuild PHP; inspect that separately below.

For LSAPI workers, inspect their executable paths:

for pid in $(pgrep -x lsphp); do
    readlink "/proc/$pid/exe" 2>/dev/null
done | sort | uniq -c

This samples running workers only. Idle versions and other handlers may not appear. Cross-check panel assignments, PHP-FPM pools, cron jobs and long-running queue workers. Record loaded modules using the full PHP binary path and -m, and configuration using --ini.

Before applying: check ionCube and application compatibility, custom PECL extensions, free disk space, trusted repositories and the rollback point. Patch updates and a jump between PHP branches are different risk profiles. Rehearse a branch migration on staging.

Verify PHP security fixes and backports

The PHP project’s October 2026 security notice identifies CVE-2026-109618 and CVE-2026-109619. Upstream fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older do not receive upstream releases; obtain confirmed vendor backports or migrate. A WAF or KernelCare installation does not prove PHP itself is patched.

Do not apply those upstream version thresholds blindly to vendor RPMs. A distributor may retain the upstream number and raise the RPM release while backporting the correction. Compare the complete installed package identity with the advisory for that vendor, OS and repository. Missing CVE text in a changelog is inconclusive—not proof of either vulnerability or safety.

rpm -q ea-php83-php-cli alt-php83-cli alt-php83-common
rpm -q --changelog alt-php83-cli | head -60
rpm -q --changelog alt-php83-common | grep -E 'CVE-2026-(109618|109619)'
dnf info --installed alt-php83-cli
dnf check-update 'alt-php83*'

dnf check-update returns 100 when updates are available, 0 when none are found, and an error status for failures. Do not make a monitoring script treat 100 as an installation failure. Its repository refresh may write local metadata even though it does not install packages. Security-only filters such as dnf --security and dnf updateinfo can miss a fresh emergency build: on 21 October CloudLinux warned that they would not list the fixed alt-php packages until the advisory metadata was published, so check plain dnf check-update as well.

For repository changelogs on DNF 4, use the supported changelog plugin, if installed:

dnf changelog --upgrades alt-php83-cli

This is not a portable dnf repoquery --changelogs command. If the changelog subcommand is unavailable, consult dnf changelog --help and your distribution’s plugin package, or use the vendor advisory. See the DNF changelog documentation. Also verify the package owning the active lsphp executable; checking only the CLI subpackage is insufficient.

Update cPanel EA-PHP

cPanel’s EasyApache 4 interface provides the package review/provision workflow. Use the currently installed profile as the starting point; do not replace it with an unrelated preset. In MultiPHP Manager, record each domain’s PHP version and handler before maintenance.

Inspect, then decline the proposed transaction:

rpm -qa 'ea-php*' | sort
dnf check-update 'ea-php*'
dnf upgrade --assumeno 'ea-php*'

Read the proposed additions, upgrades, replacements, removals and repository origins. --assumeno resolves the transaction but declines installation; it is not an application compatibility test. A broad glob can include multiple installed branches. Narrow it only after confirming every PHP family requiring the security fix.

Production change — after review and backup readiness:

dnf upgrade 'ea-php*'

Leave the confirmation prompt enabled. The cPanel incident advisory also provides its supported update route. Updating cPanel itself or one EA-PHP branch is not evidence that every alternate PHP installation has been patched.

Verify the installed branch and its configuration:

rpm -q ea-php83-php-cli ea-php84-php-cli
/opt/cpanel/ea-php83/root/usr/bin/php -v
/opt/cpanel/ea-php83/root/usr/bin/php --ini
/opt/cpanel/ea-php83/root/usr/bin/php -m

Run only paths installed on your server. For PHP-FPM, inspect the pool/service for the affected version through the panel’s supported workflow. For CGI or Apache modules, follow their service requirements. For LiteSpeed, use the detached-worker section below rather than assuming an Apache or PHP-FPM restart is appropriate.

Update CloudLinux Alt-PHP, PHP Selector and ELS

Alt-PHP is a separate package family from EA-PHP. Updating one does not patch the other. PHP Selector changes a user’s selected version/extensions; it is not a replacement for updating the installed packages. Inspect the full package set before choosing branch globs.

rpm -qa 'alt-php*' | sort
dnf check-update 'alt-php83*' 'alt-php84*' 'alt-php85*'
dnf upgrade --assumeno 'alt-php83*' 'alt-php84*' 'alt-php85*'

Production change — approved installed branches only:

dnf upgrade 'alt-php83*' 'alt-php84*' 'alt-php85*'

These are examples, not a complete list of affected branches. Include older installed branches if their vendor supports a fix. Verify the selector and extension configuration after package hooks finish; do not run an undocumented blanket reset of customer settings.

When the fixed build is in the PHP ELS repository

For this incident, CloudLinux’s status page reported on 21 October (20:18 UTC) that fixed alt-php builds were available in the stable repositories, updated with yum update alt-php*, with the remaining branches and alt-php 8.5 following later that evening. The separate TuxCare ELS for PHP repository is a paid service for end-of-life PHP branches (licence key, or the Imunify360 route described in TuxCare’s documentation); it is not required for supported branches. The Vega server below already used it. Check the latest vendor update, registration, entitlement and licensing before adding any repository.

Inspect repository configuration (the els-php-release package installs a php-els-rollout.repo file; check the repository IDs it actually defines before using them):

dnf repolist --all | grep -Ei 'php-els|alt-common'
rpm -q els-php-release
dnf info els-php-release
dnf install --assumeno els-php-release

Repository change — only when applicable and authorised:

dnf install els-php-release
dnf repolist --all | grep -i els

Confirm the repository can actually be reached, then repeat the update review. Do not equate a skipped or unavailable security repository with “fully up to date.” Do not disable signature checks or install release packages from random mirrors. Repository IDs and packaging differ outside the stated CloudLinux environment.

rpm -q alt-php83-cli alt-php84-cli alt-php85-cli
/opt/alt/php83/usr/bin/php -v
/opt/alt/php83/usr/bin/php --ini
rpm -qf /opt/alt/php83/usr/bin/lsphp

Update PHP with DirectAdmin CustomBuild

Use CustomBuild for CustomBuild-managed PHP. Do not substitute operating-system RPMs. Inspect the current slots, modes and custom configuration first:

/usr/local/directadmin/directadmin v
cat /usr/local/directadmin/custombuild/options.conf | grep -E '^(php[1-4]_(release|mode)|webserver)='
ls -ld /usr/local/php*/bin/php 2>/dev/null
da build versions

da build versions fetches the current version list itself and compares it with what is installed. On our DirectAdmin 1.712 lab on 22 October it already offered the fixed release: PHP 8.3 8.3.33 to 8.3.36 update is available. There is no separate metadata refresh to run first. Two commands look like one but do much more: da build update updates DirectAdmin itself (on our lab it answered directadmin current 1.712 ... is already latest), and da build update_versions updates every CustomBuild component with a newer version, not just PHP. Review custom configure files and extension/loader compatibility before rebuilding.

Production rebuild — example for an already configured PHP 8.3 branch:

da build php 8.3

DirectAdmin documents the optional branch argument: the selected branch must already be configured, and its mode is read from options.conf. Omitting the argument (da build php) rebuilds every configured PHP version. There is no DNF-style transaction dry-run for the compilation. Schedule for possible disruption and preserve build output; a failed build needs investigation, not repeated destructive cleanup.

What happened on our lab (DirectAdmin 1.712, AlmaLinux 9, Apache with PHP-FPM, one vCPU, PHP 8.3 and 7.4 configured, 22 October 2026): da build php 8.3 downloaded and compiled PHP 8.3.36 in 10 minutes 50 seconds. At the end it restarted php-fpm83 (new main PID), restarted Apache and rewrote every user’s httpd.conf. PHP 7.4 was not touched: its binary and its php-fpm74 process kept their old build date and PID. Afterwards /usr/local/php83/bin/php -v showed 8.3.36, da build versions showed no PHP 8.3 update left, and the site still answered 200. The restarts are why this belongs in a maintenance window even when only one branch is rebuilt; on a busy multi-core server the compile is faster but the restarts are the same.

Apache/nginx PHP-FPM installations and LiteSpeed/OpenLiteSpeed LSAPI installations use different handlers. Keep the configured mode. Security-patching a branch does not require changing all version slots, rewriting every virtual host or switching all customer domains. Use those operations only when the relevant panel procedure requires them.

for php in /usr/local/php*/bin/php; do
    [ -x "$php" ] || continue
    printf '\n%s\n' "$php"
    "$php" -v | head -1
done

For slot selection and extensions, see our CustomBuild PHP versions guide. Treat application migration as a separate change from the security update.

Verify and recycle the workers that serve HTTP

Re-running php -v starts a new CLI process. It does not prove that an existing web worker has discarded old code. Map the web handler to its executable, confirm its package/build identity, and recycle the affected worker group after the update.

LiteSpeed Enterprise detached PHP

With detached PHP, restarting the web server alone may leave PHP processes running. LiteSpeed documents a per-account restart marker and a server-wide marker. Prefer the smallest affected scope. See LiteSpeed’s cPanel PHP restart procedure.

Worker-recycle change — replace the account path:

touch /home/ACCOUNT/.lsphp_restart.txt

Use the actual account home, and touch the marker again to update its timestamp for a later recycle. The alternative server-wide marker below affects all detached PHP handlers; use it only where that scope is intended:

touch /usr/local/lsws/admin/tmp/.lsphp_restart.txt

Recycling occurs as handlers are next used; verify after real requests. The panel plugin also provides a Restart Detached PHP Processes action. Do not use killall -9 lsphp as a routine update step.

OpenLiteSpeed, other LSAPI setups and PHP-FPM

Inspect the configured external application and process mode. Do not assume every OpenLiteSpeed deployment implements the Enterprise cPanel marker workflow. Use that installation’s documented PHP restart action. For PHP-FPM, identify the specific installed unit and validate its configuration before a controlled reload/restart. A maintenance window may still be necessary.

Read-only stale-code indicators:

for pid in $(pgrep -x lsphp); do
    exe=$(readlink "/proc/$pid/exe" 2>/dev/null) || continue
    case "$exe" in
        *"(deleted)"*) printf 'PID %s: %s\n' "$pid" "$exe" ;;
    esac
    grep '(deleted)' "/proc/$pid/maps" 2>/dev/null |
        grep -v '/dev/zero (deleted)' |
        grep -vE '/(memfd:|SYSV)' |
        sed "s/^/PID $pid: /"
done

/dev/zero (deleted) is not by itself evidence of an obsolete PHP library. Investigate deleted executable or file-backed library mappings. Processes may exit while inspected, and permissions may hide details. Zero matching output is not proof of complete patching; reconcile it with the runtime/package checks and website tests.

Vega: supplied production update, 21–22 October 2026

The supplied maintenance record describes CloudLinux 9.8, cPanel 138.0.18, LiteSpeed Enterprise, Imunify360 and KernelCare. EA-PHP was already patched, while the active Alt-PHP installation needed separate packages. The record reports 75 upgraded packages and a successful Selector configuration refresh.

Alt-PHP branch	Recorded before	Recorded after
8.3	8.3.35-3.el9	8.3.35-6.el9
8.4	8.4.26-3.el9	8.4.26-5.el9
8.5	8.5.11-3.el9	8.5.11-5.el9

These are reported historical package versions, not universal minimum safe versions. Check the current vendor build for your OS and architecture. They illustrate why an unchanged upstream version can accompany a security backport.

The record confirms the three CLI RPM versions, active LiteSpeed, 61 active lsphp processes during one check and no deleted PHP executable paths. A later check showed 84 processes with /dev/zero (deleted) mappings. The final targeted check for deleted file-backed PHP libraries was not supplied. Therefore this case does not claim that every worker/library was independently verified clean or that a complete runtime rollout was proven.

Validate websites, troubleshoot and prepare rollback

After the package/build step, check representative sites on every active PHP family and handler. Test an uncached dynamic page, login, database access, uploads, background jobs and application-specific functions. A static HTTP 200 or cached homepage is insufficient. Do not place real orders or send customer mail merely to test an update.

Use an authenticated application diagnostic or a temporary access-restricted check to inspect PHP_VERSION, PHP_SAPI, loaded extensions and the active INI path over HTTP. Remove the temporary check afterwards. Avoid publicly exposing phpinfo(), environment variables or credentials.

Symptom	Check first	Avoid
No fixed package offered	Vendor rollout, OS/architecture, registration, repository reachability, excludes/versionlocks	Assuming “no updates” means “patched”
PHP version looks unchanged	Full RPM release, backport advisory, exact binary and selected handler	Comparing only the upstream number
HTTP 500/503 after maintenance	PHP/web logs, pool state, extensions, loader ABI, INI errors and permissions	Restarting every service without a diagnosis
CustomBuild compilation fails	First build error, dependencies, custom configure options, available disk/memory	Deleting configurations or replacing managed PHP with unrelated RPMs
Web workers still use old code	Executable, mappings and documented handler recycle	Assuming a CLI check proves HTTP state

For related diagnosis, see DirectAdmin PHP-FPM 503 troubleshooting and LiteSpeed on cPanel.

Rollback choices: restoring a VM/system backup restores an earlier environment; reverting a site’s selected PHP branch only changes its handler choice. A trusted RPM downgrade or rebuilding an older CustomBuild release has dependency and compatibility consequences. Do not present dnf history undo or dnf downgrade as a guaranteed recovery plan. Preserve configurations and the old working inventory before maintenance. A rollback may reintroduce the vulnerability, and restoring a snapshot can lose newer application/database changes.

Printable command reference

Use your browser’s print/save-as-PDF function for this reference. These are checkpoints, not a script to paste wholesale. Pick the matching platform; the update and recycle lines change production.

1. Inventory: rpm -qa | grep -E '^(ea-php|alt-php|lsphp)'; inspect executable paths and panel assignments.
2. Advisory: compare full package releases and vendor backports, including older installed branches.
3. Preview: dnf upgrade --assumeno 'ea-php*' or the reviewed Alt-PHP globs.
4. Apply: run the approved DNF transaction, or da build php 8.3 for that configured CustomBuild branch.
5. Runtime: recycle the affected handler using its documented procedure and inspect actual HTTP requests.
6. Close: review logs, test representative applications and record package versions, worker handling and remaining limitations.

Frequently asked questions

Editorial verification: vendor procedures reviewed 22 October 2026; Vega results supplied by the site operator. DirectAdmin CustomBuild steps (PHP 8.3.33 to 8.3.36 with da build php 8.3) run on our DirectAdmin 1.712 lab. No production update was executed during article preparation. The cPanel, CloudLinux and LiteSpeed procedures were checked against documentation; they were not freshly lab-tested.

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by

srvScripts

Supported versions

RHEL-family DNF 4; EA-PHP and CloudLinux Alt-PHP; current DirectAdmin CustomBuild; LiteSpeed detached PHP

Last full review

22 Oct 2026

Next review

29 Oct 2026

Sources

php.net/archive/2026.php
docs.cpanel.net/ea4/basics/package-manager-basics
cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5
docs.directadmin.com/changelog/version-1.659.html
docs.litespeedtech.com/lsws/cp/cpanel/php
dnf-plugins-core.readthedocs.io/en/latest/changelog.html