PHP: understand the security flaws and update your server

On October 21, 2026, the PHP project released fixes for two critical vulnerabilities. If you manage a PHP website, make room in your schedule for an update. Before pasting commands, though, let's understand the issue and organize the maintenance without turning urgency into another incident.

Who needs to pay attention?

PHP's warning covers installations handling web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Official fixes are available in 8.2.35, 8.3.36, 8.4.27 and 8.5.12, or later releases in each series. Both flaws can allow remote code execution without authentication. Official PHP advisory.

This includes the PHP underneath WordPress, Laravel, online stores and custom applications. Updating only plugins or the framework does not replace patching the interpreter. Conversely, having Apache or Nginx installed without running PHP does not put that service within the scope of these two flaws.

“Remote code execution” means making a process run code chosen by an attacker. The impact depends on the environment's permissions and isolation; it does not automatically mean root access.

The two vulnerabilities, in plain language

CVE-2026-109618: exhausted memory can interrupt initialization, leaving an invalid state. The fix makes that path safe. Exploitation was demonstrated with mod_php before website code runs; PHP-FPM is susceptible, but that complete exploit was not demonstrated on it. Technical details.

CVE-2026-109619: a reused process can retain references to a previous request's memory and access it after release. The fix clears that state. Exploitation depends on application/configuration conditions; documented paths include mod_php and sessions in PHP-FPM. Technical details.

How to update AlmaLinux 9 with cPanel

The walkthrough below is for AlmaLinux 9 with cPanel/WHM and EasyApache 4. Run commands as root or with appropriate administrative privileges. Do not copy them onto Ubuntu, installations without cPanel or servers using a different PHP provider.

1. Get ready

Check that you have a recent backup of files, databases and configuration, with a known restoration procedure. Set aside a maintenance window and make sure you can reach the provider's console if SSH disconnects.

In MultiPHP Manager, identify the version assigned to each domain and whether PHP-FPM is enabled. Also list scheduled jobs, queues and applications with their own configuration. Running php -v in a terminal does not prove which PHP version serves every website.

Avoid combining this emergency patch with a series migration, such as moving from 8.2 to 8.5. Apply the available patch first; plan and test migrations separately.

2. Check the patched package

EasyApache 4 recorded the fixes and backports for ea-php74, ea-php80 and ea-php81. A backport applies a fix to an older series without changing its main version number. This does not guarantee support for every obsolete PHP release; check the package your repository offers. cPanel changelog.

Record installed package versions and release revisions (builds), then compare them with the vendor's advisory. If the fix is unavailable, investigate repositories, exclusions and availability with support. “Nothing to do” does not confirm protection.

3. Inspect the transaction before installing

The ea-php* filter does not cover alt-php, containers or separately installed PHP binaries; update those through their respective vendors.

Refresh the metadata and ask DNF to show its proposal while automatically declining execution, as described in the DNF options:

dnf --refresh upgrade 'ea-php*' --assumeno

Check packages, dependencies, versions and any removals. The * is quoted so DNF, rather than the shell, interprets it. If you see a conflict, an unexpected removal or a provider change, stop and investigate. Do not blindly force the transaction through.

After reviewing the proposal, run:

dnf --refresh upgrade 'ea-php*'

Read the summary again and confirm only if it is correct. The command deliberately omits -y to preserve that review. Wait for completion and check for errors; a successful finish usually displays Complete!.

4. Make sure the new PHP is running

An installed package is not enough if old processes keep running. cPanel may restart services automatically, but check the result. To look for outdated services without restarting them:

/usr/local/cpanel/scripts/find_outdated_services --never-restart

This is a diagnostic command, not an instruction to restart everything. Script documentation.

Identify the PHP processes and services involved. If old workers remain, reload or restart only the necessary services using the appropriate procedure for your environment, allowing for disruption. Do not assume an empty list replaces checking the version actually used by the application.

Check the patched packages, each website's PHP and running services. Test logins, important pages, forms, cron jobs and queues. Watch the logs after maintenance. Updating only PHP does not automatically require rebooting the whole server; other updates may have their own requirements.

What about other environments?

• Linux without cPanel: use the packages and procedure supplied by your installation's vendor. Confirm the fix or backport in its advisory; comparing only the main version number can be misleading.
• Containers: obtain a patched PHP image, rebuild where necessary and redeploy. Check replicas that are still running, too.
• Shared hosting: ask the provider to confirm the fix and the version actually used by your domain.
• Unsupported PHP: look for a fix explicitly maintained by the vendor and plan a migration. Do not assume every old version received a patch.

Finally, a WAF and firewall rules are additional layers, not replacements for updating. Applying a patch also does not prove there was never a compromise. If you find suspicious signs, preserve logs and investigate beyond the maintenance work.

The practical takeaway: check the environment, have a backup, review the update and validate websites and processes afterward. Security improves when an update ends with verification, not just a closed terminal.

Sources accessed on October 21, 2026.