Website owners and hosting providers should update PHP now. The PHP project released emergency fixes on October 21, 2026, for two serious flaws that could let an attacker run code on a web server without logging in. A site can still look normal while its server runs an affected version.
October 25 update: A separate PHP advisory issued October 23 describes a rare, still-unpatched way to run code on a server. The October 21 PHP releases listed below fix the two earlier flaws, not this third issue. If your application changes its session storage format while starting a session, ask your host or server administrator to review the new advisory. PHP recommends disabling session upload progress until the next regular bugfix release. Most applications do not use the unusual settings needed for this issue.
For the two October 21 flaws, the fixed PHP releases are 8.3.36, 8.4.27, 8.5.12 and 8.2.35. Check the version selected for your site in your hosting panel. If a fixed release is not available, ask your host about an update or a documented vendor backport.
What happened?
Both bugs affect how PHP handles web requests. One involves cleanup after an out-of-memory error; the other can leave old internal data available to a later request. The PHP team says the risk is especially high for sites using PHP as an Apache module, but other ways of serving PHP are also in scope. The issues are tracked as CVE-2026-109618 and CVE-2026-109619.
These are potential routes to server compromise, not a report that every PHP website has been hacked. The PHP team says there is no complete workaround: updating is the safe fix.
What changed on October 23?
The PHP project reserved CVE-2026-115560 for a different, unlikely code-execution path. It says an application must first configure session.serialize_handler as php_binary or php_serialize. The application must then change that setting to php with ini_set() before session_start() runs. Session upload progress must also be enabled. PHP says applications that never change this setting at runtime can leave upload progress enabled.
PHP plans a full advisory and a fix in its next regular release. It has not said that the October 21 releases fix this third issue. Its recommended temporary step is session.upload_progress.enabled=0. This was already recommended for a path involving the earlier session-related flaw. If your administrator applied that measure, PHP says no further action is needed for this new path. The advisory does not claim widespread exploitation or that all PHP websites are compromised.
What should a website owner do?
- Check your site’s PHP version. In Plesk, open Domains → your domain → PHP Settings. In cPanel, open Software → MultiPHP Manager and find your domain. These pages show the selected version and the versions you can choose from. If cPanel says Inherited, check the displayed effective version or ask your host which server default applies.
- Choose a fixed version if one is available. For this advisory, the fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12 (or later releases on those branches). Back up your site and database before switching versions. If the panel has no fixed version available, ask your host to install one or confirm that its current package includes a documented backported fix. Changing a selection in the panel does not install new PHP packages.
- Test your site. After the change, check the homepage, admin area, forms and any checkout flow. If something breaks, use your backup and contact your host.
For server administrators
Plesk: Check Tools & Settings → Updates for PHP updates. On an RPM-based server, update the affected Plesk PHP packages and extensions through the trusted Plesk repository. Confirm each domain uses a patched PHP handler.
cPanel/WHM: In WHM → Software → EasyApache 4, use Run system update to update installed packages. If the fixed PHP branch is not installed, check Customize in EasyApache 4 and review the proposed package changes before Provision. Then check each domain in WHM → Software → MultiPHP Manager. A hosting customer can only choose versions made available to the account in cPanel’s MultiPHP Manager.
For the October 23 issue: Check whether an application changes session.serialize_handler at runtime as described above. Until PHP ships a fix, consider PHP’s recommended session.upload_progress.enabled=0 in startup/server configuration and restart the PHP workers so it takes effect. The earlier PHP advisory says not to rely on ini_set() or a per-directory .user.ini for this mitigation. Confirm the effective setting for each PHP handler and test any upload forms that depend on progress reporting. A managed-hosting customer should ask their provider to make and verify this change. Do not mistake a web firewall rule for a PHP patch: Cloudflare says its protection for this issue does not cover sites that changed the default upload-progress field name.
On either panel, verify that the installed package contains the fix (or a documented vendor backport), PHP-FPM is running, and each site still responds. Keep package-signature checks enabled. Other distributions and third-party PHP providers may use different package names or backport the fix without changing the visible PHP version.
PHP 8.1 and older are no longer maintained by the PHP project. A hosting provider may supply its own supported backport, but it should be able to identify the patched package. Otherwise, plan a move to a maintained PHP branch. PHP 8.2 is fixed at 8.2.35, but reaches end of life at the end of 2026.
Source: PHP security advisory, October 21, 2026. Check your hosting provider’s update channel for the package that actually fixes your server.
Image: official PHP logo by Colin Viebrock, CC BY-SA 4.0; background adapted by The Hosting Times. Composite licensed under CC BY-SA 4.0.