Critical PHP Security Update: aaPanel and WHM/cPanel Guide

Why this PHP security update deserves attention

PHP powers a large part of the web, from WordPress sites and online stores to customer portals and hosting control panels. When a serious flaw is found in PHP itself, the impact can reach beyond one application. A vulnerable PHP runtime may be used by many websites on the same server, so updating it is an important part of routine hosting maintenance.

On 21 October 2026, the PHP project announced security releases addressing CVE-2026-109618 and CVE-2026-109619. The published advisory describes both as critical vulnerabilities that may allow remote code execution in affected circumstances. The release notice lists PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as fixed upstream releases. The aaPanel notice also lists vendor-provided fixed builds for older branches. Because support and backported fixes differ by operating system and vendor, administrators should verify the exact package and advisory supplied for their environment instead of assuming every old PHP branch has an upstream patch.

This is a practical security guide for website owners and server administrators using aaPanel, WHM/cPanel, or OpenLiteSpeed. It explains how to check the runtime, apply the appropriate vendor update, test websites, and respond if an update is not yet visible.

What are CVE-2026-109618 and CVE-2026-109619?

A CVE is a public identifier assigned to a reported security vulnerability. The PHP security notice dated 21 October 2026 identifies CVE-2026-109618 and CVE-2026-109619 as critical issues. The official PHP advisory should be treated as the source of truth for technical details, affected branches, and upstream fixes.

The risk is not determined by the PHP version displayed in a hosting dashboard alone. A server may have several PHP versions installed, and different domains can be assigned to different runtimes. Command-line PHP may also use a different binary from the PHP-FPM service handling web requests. That is why administrators need to check the version used by each active website and update every affected runtime.

Do not assume that a website is safe simply because its homepage loads or returns HTTP 200. That status means the web request succeeded; it does not prove which PHP version handled the request or whether the runtime contains the relevant security fix.

Fixed PHP versions: what should you install?

The PHP project announced these fixed upstream releases for the currently maintained branches:

PHP 8.5: 8.5.12
PHP 8.4: 8.4.27
PHP 8.3: 8.3.36
PHP 8.2: 8.2.35

The aaPanel security notice also lists PHP 8.1.35, 8.0.27 and 7.4.34 as patched releases for its supported or vendor-maintained builds. Important: PHP 8.1 and older are no longer receiving normal upstream security releases from the PHP project. A control-panel or operating-system vendor may backport a fix into a package, but you should confirm that claim in the vendor’s own advisory and package changelog. If no supported, verified patch is available, plan a tested migration to a maintained PHP branch.

Do not choose a PHP version only because it is the newest number in the menu. First check your application requirements, extensions, framework version and vendor support policy. A controlled update to a patched, supported version is safer than an untested major-version jump.

Before updating: make a recovery plan

Take a full backup of website files, databases, PHP configuration and relevant web-server configuration.
If your cloud provider supports snapshots, take a server snapshot before a major runtime change.
Record the PHP version assigned to every domain and note any custom extensions or php.ini settings.
Check that you can access the server through SSH or the provider console if the control panel becomes unavailable.
Schedule the change during a quieter period where possible, and make sure someone can test important site functions afterward.

For a busy production site, test the update on staging first when possible. A backup is only useful if it can be restored, so make sure your recovery process is understood before changing the runtime.

How to update PHP in aaPanel

Sign in to aaPanel using an administrator account.
Open App Store and then Installed.
Use Update App List to refresh the available package information.
Find each PHP version installed on the server and check whether aaPanel offers the vendor’s patched build.
Update every PHP version that is actually assigned to a website, not only the version shown by the command-line php -v.
After the update completes, use the PHP service controls to restart or reload the affected PHP-FPM service if the package update does not do so automatically.
Open the affected websites and test login, forms, uploads, checkout, scheduled tasks and other essential functions.

If no update is available: refresh the App Store list and check the aaPanel security notice or support forum for your operating system and PHP branch. Do not download an arbitrary PHP build or replace aaPanel-managed binaries by hand. Confirm whether the vendor has published a fixed package or backport. If you use OpenLiteSpeed with LSPHP, follow the current aaPanel/OpenLiteSpeed instructions for your operating system; the aaPanel notice says its current script may install LSPHP but may not upgrade it correctly.

How to update PHP in WHM/cPanel

On a cPanel server, PHP packages are generally managed through EasyApache 4. The exact package names and available versions depend on the operating system, cPanel release, and repositories enabled on the server.

Log in to WHM with an account that has permission to manage server software.
Open Software → EasyApache 4.
Review the installed EasyApache profile and the PHP versions currently installed. Back up or record the profile before changing it.
Use the available EasyApache package update or profile review workflow to install the vendor-patched packages for each PHP branch in use. Confirm the package changelog or cPanel security guidance identifies the fix; do not assume a package is patched just because its branch number looks correct.
Open WHM → Software → MultiPHP Manager and review the PHP version assigned to each domain. MultiPHP Manager is primarily for selecting a domain’s PHP version; it is not, by itself, proof that the underlying package has been patched.
Where needed, use WHM → Software → MultiPHP INI Editor to review PHP settings. Do not use configuration toggles as a substitute for installing the security update.
Verify the updated package version, then test each affected website and check PHP-FPM and web-server logs for errors.

Some cPanel administrators manage updates through the operating system package manager and cPanel’s supported update process. Follow the official cPanel documentation for your installed version and operating system. Avoid copying package commands from a different distribution or installing PHP from an unrelated repository on a production server. If a patched package is not offered, check cPanel’s security advisories and your OS vendor’s support status, then contact your hosting provider if you do not control the server.

OpenLiteSpeed and LSPHP: check the actual package

OpenLiteSpeed installations often use LSPHP packages rather than the PHP-FPM build managed by aaPanel. Updating one PHP installation does not automatically update every LSPHP version. Check the active external application or virtual-host configuration and identify the package that handles each site.

The aaPanel notice provides these package-manager examples for LSPHP upgrades, but confirm repository availability and package naming on your own server before running them:

# Debian / Ubuntu
apt-get update
apt-get install --only-upgrade 'lsphp*' -y

# CentOS / AlmaLinux / Rocky Linux
yum update 'lsphp*' -y

Package-manager commands can update multiple installed LSPHP packages. Review the proposed package changes before confirming, maintain a backup, and follow the current OpenLiteSpeed and distribution guidance. Afterward, restart or reload the relevant service as documented and verify the version used by each site.

Temporary mitigation: understand its limits

The aaPanel notice describes limited mitigations for specific attack paths associated with CVE-2026-109619. It recommends setting the following in the affected PHP version’s main php.ini configuration:

session.upload_progress.enabled = 0

For PHP 8.5, the notice additionally recommends:

fatal_error_backtraces = 0

These settings must be applied in the configuration that is loaded before request parsing, and affected PHP workers must be restarted. Do not rely on ini_set() inside an application or on a per-directory .user.ini file for these mitigations.

These settings do not fix both vulnerabilities and are not a replacement for a patched PHP build. The official PHP advisory states that updating is the only safe choice; treat mitigations as limited, temporary risk reduction while arranging the proper update.

How to verify the update correctly

Check the version of the PHP binary managed by your panel.
Check the PHP-FPM or LSPHP service binary and confirm the service is running.
Inspect the web-server virtual-host configuration to see which PHP socket or handler each domain uses.
Check every PHP version installed and every runtime assigned to a live website.
Test the website over HTTPS and exercise important features. An HTTP 200 response confirms availability only; it does not independently confirm the PHP runtime version.
If you need an HTTP-level version check, use an existing authenticated diagnostic tool or create a temporary endpoint restricted to your IP that outputs only the PHP version. Remove it immediately after testing. Never leave a public phpinfo() page online.
Review PHP-FPM, Apache/Nginx/OpenLiteSpeed and application logs for startup errors or compatibility problems.

For example, the command php -v checks the command-line binary. It may not be the same PHP binary used by a website. Likewise, a successful configuration test confirms that the configuration parses; it does not by itself prove that a live request uses the expected runtime.

Security awareness for website owners

You do not need to be a server administrator to take sensible precautions. If your website is hosted on a managed plan, ask the provider which PHP runtime your account uses, whether the vendor-patched release is installed, and whether any action is required from you. If you manage your own VPS, identify all domains and runtimes before making changes.

Keep PHP, your CMS, themes, plugins and server packages updated.
Remove unused PHP versions and extensions only after confirming that no site depends on them.
Use strong, unique control-panel credentials and multi-factor authentication where available.
Restrict SSH and control-panel access to trusted IPs when practical, and use separate accounts with only the permissions needed.
Keep tested, off-server backups and review logs after security updates.
Do not assume that a web application firewall or a configuration workaround makes a vulnerable PHP runtime safe.
Ask your hosting provider for confirmation if your control panel does not offer a fixed package.

What about Node.js?

The aaPanel notice also includes a separate Node.js security update and lists Node.js 22.23.4, 24.22.1 and 26.12.1. This is a separate issue from the PHP vulnerabilities. If you operate Node.js projects through aaPanel, review the current Node.js security release notes, install a fixed supported version, switch each project to that version in the Node version manager, and restart the project. Installing a new Node.js version alone does not necessarily switch existing projects to it.

Frequently asked questions

Does a successful website response mean the PHP vulnerability is fixed?

No. A successful response shows that the website answered the request. You must also verify the PHP runtime and patched package used by the request.

Why is the PHP update missing from aaPanel or WHM?

Package availability depends on the panel version, operating system, configured repositories and PHP branch. Refresh the package list, check the vendor advisory and package changelog, and contact the provider if the fixed build is not available. Do not replace panel-managed binaries with an unverified build.

Should I update every installed PHP version?

Check every installed version and update every affected runtime that serves a website or application. If an old runtime is unused, confirm that no site, cron job or command-line task depends on it before removing it. A version that is not assigned to a website may still be used by scheduled scripts.

Can I use the temporary php.ini settings instead of updating?

No. The settings in the aaPanel notice mitigate only specific attack paths for CVE-2026-109619. They do not fix both vulnerabilities. Install the appropriate patched build or follow your vendor’s documented remediation.

What if my host manages PHP for me?

Open a support ticket and ask the provider to confirm the PHP branch, exact package build, patch status for CVE-2026-109618 and CVE-2026-109619, and whether a service restart or account-level change is required. Keep the response with your maintenance records.

Final thoughts

Security updates are most effective when they are handled methodically: identify the runtime, confirm the vendor’s fixed package, back up the site, update the correct installation, restart the right service, and test real website behaviour. Do not rely on a version selector, a successful homepage response, or a temporary setting alone as proof of remediation.

If you use aaPanel or WHM/cPanel and are unsure which PHP version serves your site, ask your hosting provider or administrator to verify the active handler and patched package before making manual changes. A careful update is better than a rushed change that leaves one runtime exposed or takes a production website offline.

Critical PHP Security Update: How to Protect Your Server on aaPanel and WHM/cPanel

Key Takeaways