On October 21, 2026, the PHP project released security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. These flaws can potentially allow unauthenticated remote code execution in affected PHP installations that serve web requests.

This guide explains the vulnerabilities, the fixed PHP versions, how to update PHP on common Linux distributions and hosting control panels, and what administrators can do if a patched package is not yet available for their environment.

Important: PHP says updating is the only complete solution. Temporary configuration changes can reduce exposure to specific attack paths, but they do not make an unpatched installation safe. See the official PHP advisory.

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

CVE-2026-109618 concerns memory handling when PHP encounters an out-of-memory condition while processing a request. In certain circumstances, request cleanup may process partially initialized internal data, potentially leading to memory corruption and remote code execution.

CVE-2026-109619 concerns stale request-related internal state that can remain after its backing memory has been released. A later request handled by the same worker may encounter that stale state before normal initialization has completed, potentially leading to remote code execution.

Both vulnerabilities are rated Critical, with a CVSS v4.0 score of 9.2. The PHP advisory covers PHP installations serving web requests, including PHP-FPM, Apache mod_php, PHP-CGI, FrankenPHP, and LiteSpeed. The precise exposure depends on the environment, but no affected runtime should be assumed safe without the appropriate fix.

Sources: PHP security advisory and Google Cloud security guidance.

Which PHP versions contain the fixes?

The PHP project published the following fixed upstream releases:

Update to the fixed release for your current branch where available. You do not need to change from one PHP minor branch to another solely to address this advisory if a fixed package exists for your current branch.

Linux distributions and commercial vendors may backport the security fix without matching the upstream version number exactly. Confirm the package version and fix status using the security notice for your operating system, control panel, or PHP vendor.

PHP 8.1 and older no longer receive regular updates from the PHP project. Some operating system and extended-lifecycle vendors may supply backported fixes. Check with your vendor or plan a tested migration to a supported PHP branch.

References: PHP downloads and PHP supported versions.

What SatisfyHost has done for managed hosting customers

At SatisfyHost, server security maintenance for managed services is handled by our system administration team. We have applied the relevant security patches to affected PHP installations on servers under our management.

This includes affected PHP runtimes within the management scope of our managed Web Hosting, WordPress Hosting, WooCommerce Hosting, Cloud Hosting, cPanel VPS, and other managed server services.

Managed customers do not need to perform root-level PHP package updates themselves for the server environments administered by SatisfyHost. Please continue to keep your application code, WordPress core, themes, plugins, frameworks, and dependencies updated. Contact support if you are unsure whether system administration is included in your plan.

Important: unmanaged VPS and dedicated server customers

Customers using an unmanaged Cloud VPS, unmanaged VPS or dedicated server, or an unmanaged server from another provider are responsible for maintaining the security of their own server environment. This includes the operating system, PHP runtimes, control panel, web server, and application dependencies.

Before updating, identify how PHP was installed. A server may have distribution PHP packages, cPanel EasyApache PHP, CloudLinux alt-PHP, a Plesk-managed PHP build, a third-party repository package, or a custom-compiled runtime. Updating one does not necessarily update the others.

Before you change PHP on a production server

Take a backup or snapshot where practical, check application compatibility, identify the PHP versions used by websites, and note how the services are managed. Start with these inventory commands:

cat /etc/os-release
php -v
php --ini

cat /etc/os-release
php -v
php --ini

The commands above show the operating system and the default command-line PHP configuration. They do not prove that the web-facing PHP-FPM or control-panel runtime is patched. Check the actual PHP handlers used by your sites.

How to update PHP on Ubuntu

Ubuntu may publish a security-fixed package with a version string that differs from the upstream PHP release. Follow the Ubuntu security notice for your Ubuntu release and installed package.

1. Refresh repositories and apply updates

sudo apt update
sudo apt upgrade

sudo apt update
sudo apt upgrade

2. Check package status

Replace 8.3 in the example with the PHP branch installed on your server:

apt-cache policy php8.3-cli php8.3-fpm

apt-cache policy php8.3-cli php8.3-fpm

Compare the installed version with the current Ubuntu security notice: USN-8948-1. Do not assume an update is complete if the fixed package has not reached your configured repositories.

3. Restart the relevant service

sudo systemctl restart php8.3-fpm

sudo systemctl restart php8.3-fpm

If the server uses Apache mod_php instead of PHP-FPM, restart the relevant Apache service after confirming the applicable package update:

sudo systemctl restart apache2

sudo systemctl restart apache2

How to update PHP on Debian

Use Debian security packages and verify the fixed package for your Debian release. Vendor package numbers may differ from upstream PHP version numbers.

1. Update installed packages

sudo apt update
sudo apt upgrade

sudo apt update
sudo apt upgrade

2. Check the PHP package

apt-cache policy php8.2-cli php8.2-fpm

apt-cache policy php8.2-cli php8.2-fpm

Change 8.2 to match the installed branch, then check the Debian Security Tracker for the relevant package and release.

3. Restart the PHP handler

sudo systemctl restart php8.2-fpm

sudo systemctl restart php8.2-fpm

For Apache mod_php, use the appropriate Apache service instead. If PHP came from a third-party repository, control panel, or custom build, update that PHP installation using its vendor instructions.

How to update PHP on AlmaLinux

AlmaLinux servers may use distribution PHP packages or separate PHP packages supplied by a hosting control panel. Use the current AlmaLinux advisory to confirm whether the fixed production package is available.

1. Update packages from enabled repositories

sudo dnf upgrade --refresh

sudo dnf upgrade --refresh

If you specifically want to inspect PHP package updates, you can check the package manager for installed and available PHP packages. Do not force packages from a testing repository onto a production server unless you are deliberately testing with a backup and recovery plan.

rpm -qa | grep -E '^(php|alt-php|ea-php)'

rpm -qa | grep -E '^(php|alt-php|ea-php)'

Review the current AlmaLinux security advisory. A completed package update does not prove the fix was installed if the relevant package is not yet published to your enabled repositories.

2. Restart the appropriate handler

sudo systemctl restart php-fpm

sudo systemctl restart php-fpm

For Apache mod_php, the service may be named httpd. Control panels and multi-version PHP stacks may require a panel-managed restart or a version-specific service. Confirm the correct service before running a restart command.

How to update PHP on Fedora

Fedora administrators should use the current Fedora repositories and security guidance for their release.

1. Apply available updates

sudo dnf upgrade --refresh

sudo dnf upgrade --refresh

2. Verify the PHP packages

rpm -q php-cli php-fpm php-common
php -v

rpm -q php-cli php-fpm php-common
php -v

Check the official Fedora package or security information to confirm that the installed package contains the fix. If PHP was installed from a third-party repository or compiled manually, update that runtime separately.

3. Restart the relevant service

sudo systemctl restart php-fpm

sudo systemctl restart php-fpm

If the server uses Apache mod_php, restart the appropriate Apache/httpd service instead. Test the sites after the update.

How to update PHP on cPanel and WHM

cPanel EasyApache 4 can install multiple PHP branches on one server. Update every installed EasyApache PHP branch that serves websites, rather than only the default CLI version.

1. Log in to WHM as root.
2. Open Software → EasyApache 4 and check for available updates.
3. Apply the relevant vendor package updates.
4. Confirm each PHP branch used by hosted websites has the security fix.
5. Restart or reload the affected web server and PHP-FPM services, then test representative sites.

cPanel publishes its package versions and instructions in its critical PHP security release advisory. Follow that advisory if a legacy PHP branch requires extended lifecycle support.

How to update PHP on CloudLinux

CloudLinux servers can have both alt-PHP and cPanel EasyApache PHP installed. These are separate package families, and both must be checked if they serve websites on the server.

CloudLinux alt-PHP

On RPM-based systems, update available alt-PHP packages with the package manager supported by your installation:

sudo yum update 'alt-php*'

sudo yum update 'alt-php*'

On systems using DNF, the corresponding command is:

sudo dnf update 'alt-php*'

sudo dnf update 'alt-php*'

For CloudLinux alt-PHP packages supplied to Debian or Ubuntu systems, refresh the package index and apply available package upgrades:

sudo apt update
sudo apt upgrade

sudo apt update
sudo apt upgrade

Check the CloudLinux status page for branch and operating-system specific package availability. Some vendor packages contain backported fixes, so the displayed PHP version may not exactly match the upstream fixed version.

cPanel EasyApache PHP on CloudLinux

If your CloudLinux server uses cPanel EasyApache PHP, CloudLinux has published a package update procedure for its stable repository. Run these commands as root after confirming that they apply to your CloudLinux/cPanel installation:

yum clean all
yum update "ea-php*"
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

yum clean all
yum update "ea-php*"
/scripts/restartsrv_httpd
/scripts/restartsrv_apache_php_fpm

Updating alt-PHP alone does not patch EasyApache PHP, and updating EasyApache PHP alone does not patch alt-PHP. See the CloudLinux status page for the current fixed package versions and scope of the update.

Imunify360 WAF is an additional measure, not a patch

CloudLinux has published WAF rules that block a known exploit pattern when the relevant Imunify360 WAF components are enabled. This can reduce exposure, but it is not a complete fix for the underlying PHP vulnerabilities. Install the appropriate PHP package updates as soon as they are available.

How to update PHP in aaPanel, Plesk, Webuzo and DirectAdmin

aaPanel

Open the aaPanel App Store, refresh the application list, and update each installed PHP version for which the vendor provides a fixed package. Restart the affected PHP service and check every PHP version used by a website. Follow the aaPanel security update notice.

Plesk

Check the PHP handlers installed in Plesk and apply the relevant Plesk updates. Also consider the PHP version used by the Plesk panel itself, which is separate from PHP handlers serving hosted websites. Follow the Plesk security advisory.

Webuzo

Webuzo published a procedure for updating its EMPS PHP packages. As root, run the vendor-provided update command if it applies to your Webuzo installation:

/usr/local/emps/bin/php /usr/local/webuzo/cli.php --emps update

/usr/local/emps/bin/php /usr/local/webuzo/cli.php --emps update

Then verify the PHP runtime and test the sites. See the official Webuzo announcement for current instructions.

DirectAdmin

DirectAdmin users should follow the current DirectAdmin guidance for their PHP installation method, including CustomBuild where applicable. Confirm which PHP branches are installed, apply the recommended fixed builds, and check every active handler. See the DirectAdmin critical PHP updates thread. Avoid manual version overrides unless the vendor recommends them for your exact environment.

If your operating system has not released a patched PHP package yet

If the fixed package is not yet available for your operating system, PHP distribution, or control panel, contact the vendor and check its live security advisory. Do not assume that a normal package update has fixed the issue if the patched package is not available in your enabled repositories.

Critical: The following settings are temporary risk-reduction measures only. The PHP project explicitly states that they do not make an unpatched installation safe. Apply the fixed PHP release as soon as your vendor makes it available.

Mitigation for CVE-2026-109619: disable session upload progress

As an interim measure, disable PHP session upload progress in the configuration that is loaded by the affected web-facing PHP runtime:

session.upload_progress.enabled = Off

Place this setting in the active php.ini, the relevant PHP-FPM pool configuration, or a server configuration that takes effect before request parsing. Restart every affected PHP worker after changing it. Do not rely on ini_set() inside application code or on FPM .user.ini for this mitigation.

This setting blocks confirmed session-related exploitation paths associated with CVE-2026-109619, but it does not block every variant and does not fix CVE-2026-109618. Applications that rely on PHP’s built-in upload-progress feature may lose that feature. Test file uploads and related workflows after applying the setting.

Avoid blindly running a recursive find/sed script across every php.ini on a server. It may alter inactive configurations while missing FPM pool overrides, included configuration files, containers, or control-panel-managed PHP instances. Back up the relevant files and confirm the effective configuration for each web-facing runtime.

Additional temporary measures for CVE-2026-109618

The PHP advisory also discusses reducing exposure to the out-of-memory attack path by controlling PHP memory-limit behavior and limiting request sizes. These changes can affect resource use or application functionality and should be reviewed by an experienced administrator.

• For applications that do not need file uploads, PHP suggests considering a low post_max_size such as 8M. Where uploads are required, the advisory gives 32M as an example. Keep upload_max_filesize below post_max_size and choose limits suitable for the application.
• PHP documents memory_limit=-1 as a temporary way to remove the controllable PHP memory-limit failure path, preferably enforced in a way the application cannot override. This does not remove all out-of-memory risks and may change resource behavior, so do not apply it blindly on shared or multi-tenant servers.
• Apply suitable request-size and multipart-request limits at the web server or reverse proxy where possible, and test them against legitimate application traffic.

Read the complete guidance in the official PHP advisory before applying temporary mitigations.

How to verify the fix

After patching, verify the actual packages and PHP handlers used by websites. The default CLI version alone is not sufficient on a multi-PHP server.

• Check installed package versions against the relevant operating-system or control-panel advisory.
• Check active PHP-FPM or web-server services and review their logs for startup errors.
• Test important application functions, including login, sessions, file uploads, scheduled tasks, and checkout where applicable.
• Repeat the check for every PHP branch and independently managed runtime.
• Remove any temporary diagnostic or phpinfo files used during testing.

Frequently asked questions

Do SatisfyHost managed hosting customers need to patch PHP manually?

SatisfyHost has applied the relevant patches to affected PHP installations on servers under our management. Customers should continue maintaining their applications and contact support if they are unsure whether system administration is included in their plan.

What if I use an unmanaged Cloud VPS?

Unmanaged VPS customers are responsible for updating the PHP runtimes, operating system, control panel, and other server components themselves. Follow the instructions from the vendor that supplies your actual PHP installation.

Does disabling session upload progress completely fix these CVEs?

No. It reduces exposure to specific known paths for CVE-2026-109619. It does not completely mitigate that vulnerability, does not fix CVE-2026-109618, and is not a replacement for the official PHP update.

Does updating WordPress fix a PHP runtime vulnerability?

No. WordPress core, themes, and plugins should be kept updated, but a PHP runtime vulnerability must be fixed by updating or patching the PHP installation itself.

Does a successful apt or dnf command mean my server is secure?

Not necessarily. The required vendor patch must be available and installed, and every PHP runtime serving web requests must be checked. Control-panel PHP versions and custom builds may be independent of the operating system packages.

Conclusion

CVE-2026-109618 and CVE-2026-109619 require prompt action from website owners, developers, hosting providers, and server administrators. Identify each PHP runtime that serves web requests, apply the security fix from the correct vendor, restart the appropriate workers, and verify the result.

SatisfyHost has patched affected PHP installations on servers covered by our managed hosting and system administration services, including applicable managed Web Hosting, WordPress Hosting, WooCommerce Hosting, Cloud Hosting, cPanel VPS, and other managed server plans.

Customers using unmanaged Cloud VPS, unmanaged dedicated servers, or unmanaged servers from another provider should review their installations and apply the appropriate updates themselves. If a patch is not yet available, temporary mitigations may reduce exposure, but they do not replace the security update.

Official references

• PHP security advisory and temporary mitigation guidance
• PHP downloads
• PHP supported versions
• Ubuntu security notice USN-8948-1
• Debian Security Tracker
• AlmaLinux PHP advisory
• CloudLinux package and WAF status
• cPanel EasyApache PHP security release
• aaPanel security update
• Plesk security advisory
• Webuzo EMPS security update
• DirectAdmin critical PHP updates

Last reviewed: October 22, 2026. Vendor package status can change. Always check the current advisory for your exact operating system, PHP branch, and control panel before making production changes.