PHP CVE-2026-109618 and CVE-2026-109619, Response, Actions and Next Steps

On 21 October 2026, the PHP project released security updates addressing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. Both vulnerabilities affect PHP’s internal handling of memory and request state, potentially allowing attackers to execute code on vulnerable servers without logging in.

Because PHP underpins a large share of the web, including many hosting environments, cPanel immediately assessed the impact across its products and has since been releasing updates and guidance for customers and partners.

This post outlines the vulnerabilities, summarizes cPanel’s response, and explains what administrators should do next.

What Was Addressed 

On 21 October 2026 at 13:30 UTC, the PHP project published fixes in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both vulnerabilities are rated CVSS v4.0 9.2.

CVE-2026-109618 allows remote code execution through memory corruption during out-of-memory handling. PHP enforces its memory_limit setting by aborting a request that exceeds the limit. This can interrupt PHP while internal request data, such as a multipart file upload, is only partially initialized. Request cleanup may then try to free memory that was never initialized, and that memory may still hold attacker-influenced data from earlier allocations.

CVE-2026-109619 allows remote code execution through stale global state. Internal state owned by a request can survive after its backing memory is freed, for example after a fatal error. A later request handled by the same worker may use that stale state before normal initialization resets it.

Every PHP installation that serves web requests is potentially at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers mod_php the highest-risk configuration. End-of-life branches (PHP 8.1 and older) are also affected and no longer receive updates from the PHP project. The PHP security team has published minimal source backports for PHP 7.4, 8.0 and 8.1.

Public proof-of-concept code has begun to circulate, increasing the likelihood of exploitation attempts.

This is a vulnerability in PHP itself, not in cPanel & WHM or WP Squared. Products that bundle or depend on PHP are affected to the extent they use an unpatched PHP runtime.

How We Responded 

cPanel took part in the PHP project’s coordinated disclosure, so fixed packages were built and tested before the public release. Once fixes were public, we rolled out updated PHP packages, product releases and mitigations. EasyApache 4 PHP updates were on our mirrors within minutes of PHP’s public release, and fixed builds for every supported cPanel & WHM version followed within an hour.

The status below reflects what had been published as of 23 October 2026.

cPanel & WHM and WP Squared 

Updated PHP packages and an automated fixer were released for cPanel & WHM. WP Squared 11.138.1.18 was released with security fixes and an updated WP Toolkit. Administrators should apply updates through their normal update process.

1. EasyApache 4 v25.91 (October 21): ea-php82, ea-php83, ea-php84 and ea-php85 updated to 8.2.35, 8.3.36, 8.4.27 and 8.5.12. ea-php74, ea-php80 and ea-php81 received the PHP project’s backported fix, so customers on PHP 7.4, 8.0 and 8.1 under EasyApache 4 are covered too. EasyApache 4 packages for PHP 7.3 and older did not receive this fix.

2. EasyApache 4 v25.92 (also October 21) followed with updated ea-php74-meta, ea-php80-meta and ea-php81-meta packages, so the CVE backport is listed in their change logs too. No further PHP code change was needed.

3. cPanel & WHM 11.138.0.18, 11.136.0.50, 11.134.0.66 and 11.110.0.153 update the PHP that cPanel & WHM itself runs on (cpanel-php84 8.4.27, and cpanel-php81 8.1.34-2 on 110). All four are flagged as security releases.

4. An automated fixer prompts servers to install these updates, and updates cPanel’s own PHP on older versions 112 through 132.

5. WP Squared 11.138.1.18 is live on all WP Squared tiers.

Change logs: EasyApache 4 and cPanel & WHM 138 (same pattern for 136, 134 and 110). Full details: Critical PHP Security Release: CVE-2026-109618 and CVE-2026-109619 

TuxCare 

TuxCare released fixes for distribution PHP on several extended-support operating systems, with further releases in progress.

Recommended Actions 

1. Update PHP. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install the fixed package from your operating system vendor, control panel or LTS provider. Restart PHP-FPM, Apache and any other PHP worker processes after updating.

2. Update cPanel products. Apply the latest updates for cPanel & WHM and WP Squared listed above.

3. Replace unsupported PHP versions. If you run PHP 8.1 or older, use a vendor that provides backported fixes, build from the PHP project’s source backports, or upgrade to a supported branch.

4. Check third-party repositories. Community repositories may not have fixed packages on release day. Confirm with your repository maintainer or switch to distribution packages or a supported build.

5. Check architecture coverage. Some package repositories published fixed builds for amd64 before arm64. Verify that every host, including arm64, is actually running a fixed version.

6. Review containers and tooling. Rebuild container images, CI runners and internal tooling that embed PHP, not only production web servers.

cPanel & WHM customers who need to stay on end-of-life PHP versions can purchase Extended Lifecycle Support for PHP.

Temporary Mitigations 

Updating PHP resolves both vulnerabilities. The measures below, from the PHP project’s guidance, reduce exposure to specific attack paths but do not replace the update.

For CVE-2026-109618:  

1. Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration.
   
2. Set a low post_max_size (for example 8M, or 32M where uploads are required) and keep upload_max_filesize below it.
   
3. Enforce request size, field count and multipart limits at the web server or proxy.
   
4. Use container or cgroup memory limits as an availability boundary. Do not use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation failure.

For CVE-2026-109619:  

1. Set session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration, then restart every worker. Do not rely on ini_set() or .user.ini.
   
2. On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
   
3. Remove invalid or deprecated per-request settings that emit diagnostics before initialization.
   
4. Fix fatal errors and timeouts that attackers can reach.  

Where patching is not immediately possible, consider isolating internet-facing applications from public networks until a fix is applied and verified.

On 23 October 2026 the PHP project recommended keeping session.upload_progress.enabled=0 until its next regular bugfix release, even on patched versions, to fully protect against a related vector (CVE-2026-115560). It only affects applications that change session.serialize_handler at runtime. If you applied this setting for CVE-2026-109619, keep it in place. cPanel & WHM administrators can set it in WHM’s MultiPHP INI Editor.

Working Closely with Partners 

We are working with hosting partners and operating system vendors on legacy and non-standard configurations, including end-of-life PHP versions and multiple architectures. Partner feedback on coverage gaps is shaping follow-up releases. If you are a partner with a specific configuration question, contact your cPanel account representative or support.

Next Steps 

We will continue to update our cPanel support article as additional releases and packages become available. Please refer to Critical PHP Security Release: CVE-2026-109618 and CVE-2026-109619 for the most current version and coverage information.