On October 21, 2026, the PHP project released fixes for two critical security flaws in PHP itself. They are known as CVE-2026-109618 and CVE-2026-109619, and together they are nicknamed "php2shell". Both are rated 9.2 out of 10. In the worst case, an attacker who sends a specially crafted request to a website can run their own code on the server, without logging in.

The PHP project is clear that updating PHP is the only complete fix. That is what we are doing, and this post explains where things stand.

#The short version

  • Windows hosting, PHP 8.2 to 8.5: patched. The fixed PHP releases went live on all of our Windows web servers within about 15 minutes of the PHP project publishing them.
  • Windows hosting, PHP 5.2 to 8.1: patched. The PHP project no longer releases these versions, so we built patched versions ourselves and installed them on all of our Windows web servers early on October 22.
  • Windows hosting, PHP 8.6 release candidate: patched. We updated it to 8.6.0 RC4, which includes the fix. It is still a preview release and should not be used for live sites.
  • cPanel hosting: patched. Our cPanel server's OS vendor, CloudLinux, built the fix into all 16 PHP versions on that server, and we installed the updates on the evening of October 21. The PHP version numbers did not change, so your site shows the same version as before, but it now includes the fix.
  • Linux hosting in Core: in private beta. Patched PHP 8.2 to 8.5 builds are ready for its public launch.
  • Node.js: the Node.js project also released security updates on October 21, 2026. None is rated critical. We updated Node.js on our servers to the fixed releases on the night of October 21.

#What you need to do

Most customers don't need to do anything.

If your site runs the PHP 8.6 release candidate, it is patched, but it is still a preview release, so we recommend PHP 8.5 for live sites. As always, keep your own apps and plugins up to date. If you're not sure what your site uses, open a ticket and we'll check it for you.

For the geeks

CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w, CVSS 4.0 score 9.2). PHP uses longjmp() to bail out when a request runs out of memory. If that happens while request memory is reachable but not fully initialized, request shutdown can act on invalid state. The advisory lists several multipart parsing behaviors that let a request run out of memory while staying under post_max_size. The confirmed exploit is unauthenticated remote code execution against Apache mod_php, before any application code runs. Source analysis shows PHP-FPM is also susceptible.

CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp, CVSS 4.0 score 9.2). Some global state in a PHP worker can still point at memory from a request that has already finished. A later request on the same worker can use that stale state before it is reset, which is a use-after-free. The advisory confirms remote code execution against mod_php, and against mod_php and PHP-FPM through the session upload progress path.

Who is affected: per php.net, all PHP installations serving web requests, including PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. Our Windows servers run PHP through FastCGI under IIS. The fixed upstream releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older no longer get releases from the PHP project, but its security team published minimal source backports for 7.4, 8.0 and 8.1. The PHP 8.6 preview line got the fixes in 8.6.0 RC4.

Timing: php.net gave advance notice on October 20 and released the fixes on October 21 at 14:00 UTC (10:00 AM ET). Ubuntu notes that public disclosure was moved forward one day after a leak. Our Windows servers were running 8.2.35, 8.3.36, 8.4.27 and 8.5.12 by about 10:10 to 10:16 AM ET. Our patched PHP 5.2 to 8.1 builds and PHP 8.6.0 RC4 were on all of our Windows web servers early on October 22.

Windows, PHP 5.2 to 8.1: where the fixes in our builds came from:

  • 7.4 to 8.1: built from the PHP security team's upstream backports.
  • 7.2 and 7.3: backported from the upstream fixes.
  • 7.0 and 7.1: backported by a community security researcher.
  • 5.6: backported by another community security researcher.
  • 5.2 to 5.5: backported in-house, with help from a C developer.

These builds are installed on all of our Windows web servers.

cPanel: CloudLinux ships these fixes as backports and keeps its own version numbers, so the usual check is the package changelog, not the PHP version string. Our cPanel server has the fixed packages for all 16 PHP versions it offers.

Linux hosting in Core: the patched builds for public launch are php-82-8.2.35-a1, php-83-8.3.36-a1, php-84-8.4.27-a1 and php-85-8.5.12-a1. When Linux hosting leaves private beta, PHP 8.1, 8.0, 7.4 and older will be listed as unpatched for these flaws.

Configuration: php.net lists some settings that narrow specific attack paths, and is clear that none of them makes an unpatched server safe. session.upload_progress.enabled is off on every server that runs customer PHP, which php.net names for the confirmed session path of CVE-2026-109619. php.net's stopgap for CVE-2026-109618 is to remove the PHP memory limit (memory_limit=-1). We did not do that. Every site keeps a memory limit, and we updated PHP instead.

Node.js: the October 21, 2026 Node.js security release fixes ten issues in the 22.x, 24.x and 26.x lines, up to high severity. One is a Brotli decoder out-of-bounds write that can allow remote code execution (CVE-2026-111497). The fixed versions are 22.23.4, 24.22.1 and 26.12.1. End-of-life Node.js lines are always affected.

#What we did

  • Windows, PHP 8.2 to 8.5: installed the fixed releases on all of our Windows web servers on the morning of October 21.
  • Windows, PHP 5.2 to 8.1: built patched versions and installed them on all of our Windows web servers early on October 22.
  • Windows, PHP 8.6 preview: updated to 8.6.0 RC4, which includes the fix.
  • cPanel: installed our OS vendor's fixed packages for all 16 PHP versions on the evening of October 21.
  • Linux hosting in Core: built patched PHP 8.2 to 8.5 for launch.
  • Settings already in place: expose_php is always off, so your sites don't advertise their PHP version. max_input_nesting_level is set to suit the apps we host. post_max_size is set at a sensible global level. memory_limit is never unlimited, and ranges from 128M to 1G depending on your package. session.upload_progress.enabled is off. These settings are good hygiene. They do not replace the update.
  • Node.js: updated Node.js on our servers to the fixed releases on the night of October 21.

If you have questions about your site, open a ticket and we'll check it for you.