{"id":18259,"date":"2026-10-22T06:53:40","date_gmt":"2026-10-22T12:53:40","guid":{"rendered":"https:\/\/www.supportpro.com\/blog\/?p=18259"},"modified":"2026-10-22T06:59:16","modified_gmt":"2026-10-22T12:59:16","slug":"php-cve-2026-109618-and-cve-2026-109619-what-hosting-teams-should-do-now","status":"publish","type":"post","link":"https:\/\/www.supportpro.com\/blog\/php-cve-2026-109618-and-cve-2026-109619-what-hosting-teams-should-do-now\/","title":{"rendered":"PHP CVE-2026-109618 and CVE-2026-109619: What Hosting Teams Should Do Now?"},"content":{"rendered":"\n

HP CVE-2026-109618 and CVE-2026-109619<\/strong> are critical remote code execution vulnerabilities disclosed on October 21, 2026. Both vulnerabilities could allow attackers to execute code on affected PHP servers without authentication. PHP has released patched versions, so hosting providers should identify vulnerable installations and apply the appropriate updates promptly.<\/p>\n\n\n\n

Updating WordPress, plugins, and themes alone does not protect a website from vulnerabilities in the underlying PHP runtime. If a server still runs a vulnerable PHP version, the website may remain at risk even when its applications are fully updated.<\/p>\n\n\n\n

For web hosting companies, fixing these vulnerabilities requires more than updating a single server. One server may run multiple PHP versions, several PHP-FPM pools, and hundreds of customer websites. Hosting environments may also include containers and custom application setups, making it harder to identify every affected installation.<\/p>\n\n\n\n

Even one missing vulnerable PHP installation can leave part of the hosting infrastructure exposed.<\/strong><\/p>\n\n\n\n

To build a repeatable response process for newly reported vulnerabilities, read our article on how to assess whether a newly published CVE affects your servers<\/a>.<\/p>\n\n\n\n

This article explains CVE-2026-109618 and CVE-2026-109619<\/strong>, identifies the PHP versions with upstream fixes, and outlines how hosting teams can identify affected installations, apply patches, and verify that their updates resolve the issue.<\/p>\n\n\n\n

<\/p>\n\n\n\n

What Are CVE-2026-109618 and CVE-2026-109619?<\/strong><\/h2>\n\n\n\n

PHP disclosed two critical vulnerabilities that can lead to remote code execution (RCE). Remote code execution means an attacker can run code remotely on a vulnerable application or server.<\/p>\n\n\n\n

Both vulnerabilities received a CVSS v4.0 score of 9.2, indicating critical risk. The PHP announcement identifies installations handling web requests as affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.<\/strong><\/p>\n\n\n\n

CVE-2026-109618: Remote Code Execution Through Memory Corruption<\/strong><\/h3>\n\n\n\n

This vulnerability involves how PHP handles out-of-memory (OOM) errors.<\/strong><\/p>\n\n\n\n

When PHP encounters an out-of-memory condition, it may interrupt the current execution context before it initializes all internal request data. During request cleanup, PHP may then treat invalid or uninitialized data as valid.<\/p>\n\n\n\n

This can lead to memory corruption and remote code execution.<\/p>\n\n\n\n

For hosting providers<\/strong>, this matters because an affected PHP installation may process requests from public websites<\/strong>. An attacker doesn’t need a valid hosting account to exploit a vulnerable request-handling path.<\/p>\n\n\n\n

CVE-2026-109619: Remote Code Execution Through Stale Internal State<\/strong><\/h3>\n\n\n\n

The second vulnerability occurs when PHP retains references to internal state after freeing the memory that supports it. A later request handled by the same PHP worker may access these outdated references before PHP properly initializes the relevant state. Under affected conditions, an attacker could exploit this flaw to execute code remotely.<\/p>\n\n\n\n

For hosting providers, this makes PHP updates and worker restarts<\/strong> especially important. Long-running PHP workers may keep handling requests after an update unless the hosting team restarts the affected processes. In shared hosting environments, teams should verify that every affected PHP installation has received the correct patch and that the relevant workers have restarted successfully.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Which PHP versions are affected?<\/strong><\/h2>\n\n\n\n

The PHP team fixed four branches. Make sure you run at least these versions:<\/p>\n\n\n

\n
\"What<\/a><\/figure>\n<\/div>\n\n\n

Anything older than these is at risk.<\/p>\n\n\n\n

What about PHP 8.1 and below? The PHP team no longer supports those branches, so they got no official fix. Your control panel or OS vendor may have added the fix on their own, which is called a \u201cbackport.\u201d For example, cPanel has published backported fixes for PHP 7.4, 8.0 and 8.1, and CloudLinux is patching its PHP Selector versions. PHP below 7.4 on a plain cPanel server may get no fix at all.<\/p>\n\n\n\n

Don\u2019t trust the version number alone. A server may show PHP 8.1.x and still be patched, because the vendor fixed it behind the scenes. Check the package changelog to be sure (we show how below).<\/p>\n\n\n\n

Do this for every PHP version on the server, including old sites nobody has touched in years.<\/p>\n\n\n\n

<\/p>\n\n\n\n

How to Patch CVE-2026-109618 and CVE-2026-109619<\/strong><\/h2>\n\n\n\n

Updating PHP across a hosting environment requires more than running a single command. The following steps help hosting teams identify affected installations, apply the correct patches, and verify the results.<\/p>\n\n\n\n

1. Inventory Every PHP Installation<\/strong><\/h3>\n\n\n\n

Start by identifying the PHP versions installed across production servers, development systems, containers, and other environments that handle web requests.<\/p>\n\n\n\n

On Linux, run: php -v<\/strong><\/p>\n\n\n\n

On RPM-based systems, run:<\/p>\n\n\n\n

rpm -qa | grep -E ‘^(php|ea-php)’<\/strong><\/p>\n\n\n\n

For a broader inventory, check:<\/p>\n\n\n\n