Two Critical PHP Vulnerabilities: Emergency Security Patches Released

Emergency PHP security updates have been released

On October 20, the PHP Security Team issued advance warning of two critical vulnerabilities. The emergency security releases were published on October 21, 2026. The project has now identified the vulnerabilities as CVE-2026-109618 and CVE-2026-109619, both rated Critical with a CVSS 4.0 score of 9.2.

These are vulnerabilities in the PHP runtime itself, not defects introduced by WordPress, a particular application plugin, or the cPanel & WHM control panel. Consequently, upgrading application code alone does not remove the underlying risk. Administrators must verify the PHP binaries actually serving web requests.

According to the PHP project, unauthenticated remote code execution may be possible under certain conditions. The risk covers multiple server integrations, including PHP-FPM, php-cgi, Apache mod_php, FrankenPHP and LiteSpeed. The official advisory highlights mod_php as a particularly serious exposure.

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

CVE-2026-109618 involves memory corruption during out-of-memory handling. A failure can occur while PHP is only partially initializing internal request data. If cleanup then interprets that incomplete structure as valid, unsafe memory operations may follow. Depending on the runtime and request conditions, this can result in remote code execution.

CVE-2026-109619 concerns stale global state. Request-related internal data can survive after the underlying memory has been freed. A later request handled by the same PHP worker may use that stale state before normal initialization has reset it. This is another route to memory corruption and potentially remote code execution.

The project has confirmed that some attack paths need no prior authentication and may run before an application's own PHP code begins executing. That does not mean every PHP website is exploitable in exactly the same way, but it makes the PHP runtime update a priority independent of application-level fixes.

Which PHP releases contain the fixes?

The PHP project published four patched upstream releases on October 21. Sites running those supported branches should upgrade to the relevant release, or to a later version that includes the same fixes.

PHP 8.1 and older do not receive regular security releases from the PHP project. However, Linux distributions and extended lifecycle support vendors may provide backported fixes for older PHP branches. In those environments, an older upstream version number does not necessarily imply an unpatched package. The exact package release and the vendor's security announcement are authoritative.

The PHP team also provided limited source backports for PHP 7.4, 8.0 and 8.1. These help certain operators build patched legacy runtimes, but they should not be confused with a renewed upstream support commitment.

Why cPanel and EasyApache environments require extra checks

cPanel has separately notified administrators about both CVEs. The vendor emphasizes that the flaws are in PHP, rather than in cPanel & WHM's own code. Its notice addresses the cPanel 110, 134, 136 and 138 branches and states that fixed packages will be distributed through the usual cPanel and EasyApache update channels.

An important distinction is that the cPanel version and the PHP version are not the same thing. Updating cPanel to a newer build does not prove that every installed PHP runtime has received the fix. Likewise, the cPanel build numbers in a security notice must not be mistaken for patched PHP version numbers.

EasyApache 4 manages EA-PHP packages, and a single cPanel host may have several versions installed concurrently. Administrators should verify which version each virtual host uses, which EA-PHP packages are installed, and whether their package distributor has published the corresponding security builds.

CloudLinux ALT-PHP and legacy applications

CloudLinux systems introduce another package family: ALT-PHP, frequently selected per hosting account through PHP Selector. EA-PHP and ALT-PHP do not necessarily receive updates at the same moment or through identical repositories. Both require verification where they are installed.

CloudLinux HardenedPHP and extended lifecycle support can supply security backports for older applications that cannot immediately be moved to a current PHP branch. Nevertheless, a support subscription does not by itself demonstrate that this specific pair of fixes is already installed. Administrators should compare installed package releases with the current vendor advisory.

On heavily consolidated hosting servers, an inventory based only on the default command-line PHP executable is inadequate: a website might be using a different PHP-FPM pool, LSAPI runtime or PHP Selector version.

Imunify360 WAF rules help, but cannot replace patches

CloudLinux published Imunify360 ModSecurity rules for known public attack patterns, including a blocking rule in the 8.83 ruleset. Updated rules can reduce exposure when the web application firewall is enabled, correctly configured and operating in enforcement mode.

It is important not to confuse an installed ruleset with proof that every exploit path is blocked. The vulnerabilities originate in PHP internals, and a WAF only sees the HTTP traffic patterns it was designed to detect. The official PHP advisory expressly states that there are no complete configuration-only mitigations.

The correct course remains to deploy verified patched PHP packages, keeping WAF protection as an additional defense rather than a substitute.

Temporary settings are risk reductions, not a complete fix

For CVE-2026-109619, disabling session.upload_progress.enabled before request parsing can block confirmed session-related attack paths. The PHP project warns that changing this option from application code, or relying on per-directory overrides that take effect too late, is insufficient. PHP workers must use the intended setting.

For CVE-2026-109618, the advisory describes reducing exposure by controlling PHP memory behavior, upload size and request limits. Those measures carry operational trade-offs, and none closes all possible routes into the affected memory-handling code.

Administrators unable to patch a public-facing service promptly should consider additional restrictions or temporary isolation based on the service's exposure and business requirements. There is no responsible basis for declaring a vulnerable server safe simply because one PHP setting has been changed.

How to audit installed PHP packages safely

On an RPM-based cPanel or CloudLinux system, the following command provides a starting inventory of installed EA-PHP and ALT-PHP packages. It only reads the package database; it does not install or remove anything.

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

The command-line output of php -v is not enough to establish which PHP release serves a particular website. Review cPanel MultiPHP Manager, CloudLinux PHP Selector and the actual virtual host or pool configuration.

Once security packages are available, verify the precise installed RPM release and the vendor changelog. Confirm that application workers are using the new binaries, then check PHP-FPM or LSAPI processes, web server status, site behavior and application error logs.

What administrators should do now

The upstream patches are already public. Availability in cPanel, CloudLinux and other downstream package repositories may follow a different release schedule. This distinction matters when a distribution deliberately preserves an older upstream version number while backporting a security fix.

Inventory every PHP runtime, compare installed packages with vendor advisories, deploy supported updates as they become available and verify the result at the application-serving process level. Pay particular attention to websites tied to end-of-life PHP releases.

The October 21 disclosures have moved the situation beyond the preliminary warning stage. The relevant question is no longer when PHP will release fixes, but whether each production runtime is actually running a build containing the fixes.

Official references

• PHP Security Team — October 21, 2026 security advisory and releases
• CloudLinux — PHP package security update status
• cPanel — EasyApache 4 documentation

Related technical articles

• Critical cPanel security update — patch preparation and verification
• cPanel malware persistence — cron jobs, backdoors and recurring infections