PHP2Shell: two critical PHP flaws, and what to do about them

On 21 October the PHP project shipped an emergency security release for two critical vulnerabilities in PHP itself, nicknamed PHP2Shell. Either one can let an attacker run code on a server without logging in, through nothing more than a crafted web request. Details leaked a day before the planned disclosure, and attacks against unpatched servers were seen from the day the fix came out.

If you run PHP anywhere, on Cosmoner or not, update it this week.

What is affected

The bugs are in PHP, not in WordPress, Laravel or any other application, so keeping your plugins up to date does not protect you. Every PHP installation that serves web requests is in scope: Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The PHP project rates mod_php as the most exposed, because an attack can succeed before your application's code runs at all.

• CVE-2026-109618 (CVSS 9.2). When PHP runs out of memory partway through setting up a request, it can be left working with half-built internal data.
• CVE-2026-109619 (CVSS 9.2). Internal state from one request can outlive the memory behind it, so the next request handled by the same PHP worker can act on leftover data.

Code runs with the permissions of the PHP process, which means it can read your files, your configuration and any database passwords or API keys stored there.

Fixed versions

PHP 8.1 and older no longer receive updates from the PHP project. Some Linux distributions and long-term support vendors ship patched packages, but the safe move is to upgrade to a supported version.

If you use Cosmoner web hosting

Patched builds are available for PHP 8.4, 8.3 and 8.2. Open your hosting's overview in the control panel and press Update now next to Security update available. The hosting restarts on the new build, which interrupts your sites for a few seconds. If something breaks, Roll back returns it to the previous build for 7 days.

If your hosting is still on PHP 8.1, there is no patched build, and there will not be one. Change its PHP version to 8.4 or 8.3 from the overview. Test your sites afterwards, and use Roll back if a plugin or framework is not ready, but plan the move for the next few days rather than the next few months. See PHP versions.

PHP 8.2 is patched, but its security support ends on 31 December 2026. This is a good moment to move it to 8.4 too.

If you run PHP in an app or a container

An app built from your repository gets PHP when it is built, so redeploy it to pick up a fixed release. If you deploy your own container image, rebuild it on an updated base image, such as php:8.4-apache or php:8.4-fpm, and deploy the new image. Either way, check that the PHP version it reports is at least the fixed one in the table above.

On any server you manage yourself, install the update and then restart every PHP process: Apache, PHP-FPM, queue workers and anything else that loads PHP. A process that was already running keeps the vulnerable code in memory until it restarts.

Can I just change a setting instead?

No. The PHP project is clear that there is no complete mitigation and that updating is the only safe choice. If you cannot update straight away, it suggests these settings to narrow the window, set in php.ini or the FPM pool configuration and followed by a restart of every PHP worker:

session.upload_progress.enabled = 0
post_max_size = 8M

Setting them from your application with ini_set() or a .user.ini file does not help. On 23 October the PHP project also recommended keeping session.upload_progress.enabled off until its next regular release, which will fix a further, less likely attack through the same feature.

Treat these as a stopgap for a day or two, not a fix. Update, restart, and you are done.