Two critical PHP flaws require more than one version check
The PHP project has released security updates for two critical vulnerabilities that can allow an unauthenticated attacker to execute code on a server handling web requests.
The issues CVE-2026-109618 and CVE-2026-109619 are each rated CVSS v4.0 9.2. PHP says all installations serving web requests are in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The project considers mod_php the highest-risk configuration because a demonstrated attack can be triggered before application code runs.
The complete response is not simply “update PHP once.” Shared-hosting servers often run several PHP branches, control-panel PHP components, and vendor-backported packages at the same time. Administrators need to identify, update, restart, and verify each active handler.
What administrators should do now
1. Inventory every PHP handler serving websites, including supported and end-of-life branches.
2. Update through the platform or operating-system vendor's supported channel. Vendor backports may keep an older-looking PHP version number.
3. Update control-panel PHP separately, including cPanel's internal PHP and Plesk's `sw-engine` where applicable.
4. Restart Apache, PHP-FPM, LiteSpeed, LSAPI, or the relevant PHP workers so the patched code is loaded.
5. Verify every active handler after maintenance, not only the server's default `php` command.
6. Review web and WAF logs for unusual multipart uploads, session-upload-progress requests, and vendor-provided indicators.
What happened
Both vulnerabilities occur inside PHP's handling of request data rather than in a particular content management system or website plugin. This is why the issue can affect many different applications and hosting platforms at once.
CVE-2026-109618: remote code execution through memory corruption
CVE-2026-109618 involves PHP's out-of-memory handling. Processing a specially crafted request can interrupt PHP while internal request data is only partly initialized. Cleanup code may then treat invalid data as valid, leading to memory corruption and possible remote code execution.
PHP's temporary guidance includes reducing controllable request sizes and reconsidering memory-limit behavior. These steps address particular paths and can have operational side effects. They do not replace the update.
CVE-2026-109619: stale request state reused by another request
CVE-2026-109619 can leave request-owned internal state behind after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.
One confirmed attack path involves PHP's session upload progress feature. Setting `session.upload_progress.enabled=0` in a server-level PHP configuration and restarting all workers reduces exposure to that path, but PHP explicitly warns that it does not block every possible variant.
cPanel & WHM
cPanel released EasyApache 4 version 25.91, which fixes both CVEs in `ea-php74` through `ea-php85`.
cPanel also updated the internal PHP used by panel interfaces and bundled applications such as Roundcube:
- cPanel & WHM 138.0.18
- cPanel & WHM 136.0.50
- cPanel & WHM 134.0.66
- cPanel & WHM 110.0.153, using a backported fix for internal PHP 8.1.34
On CloudLinux systems, CloudLinux reports additional fixed EasyApache packages from `ea-php52` through `ea-php85`. Confirm the applicable package source and changelog rather than assuming the displayed PHP version alone proves coverage.
Plesk
Plesk has rebuilt and distributed PHP packages for 7.4, 8.0, 8.1, 8.2, 8.3, 8.4, and 8.5 on Plesk for Linux. Fixed PHP 8.2 through 8.5 packages are also available on Plesk for Windows.
For the supported upstream branches, the fixed destinations are:
| PHP branch | Fixed release |
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Plesk's backported PHP 7.4.33, 8.0.30, and 8.1.34 packages retain the same version numbers. Plesk instructs administrators to distinguish the fixed builds by their October 21, 2026 build date.
The Plesk interface uses a separate PHP component called `sw-engine`. Plesk 18.0.81 Update 4 fixes this component on Linux and Windows. The equivalent fix for Plesk 18.0.80 is still pending and planned for Update 11 at the time of verification.
CloudLinux, TuxCare, and Imunify360
CloudLinux has released fixed `ea-php52` through `ea-php85` packages for CloudLinux 7, 8, 9, and 10.
The `alt-php` and native-PHP picture is more granular. At verification:
- fixed `alt-php` packages for CloudLinux 7, 8, and 9 are available through the TuxCare ELS ALT PHP repository while normal stable-repository rollout continues
- CloudLinux 10 obtains most fixed `alt-php` packages through that repository
- CloudLinux for Ubuntu 22.04 has broad fixed `alt-php` coverage in stable
- native PHP fixes are in stable for PHP 8.2 and 8.3 on CloudLinux 9 and PHP 8.2 on CloudLinux 8, while other streams remain in testing or early rollout
CloudLinux backports keep their own version numbers. The recommended confirmation is to look for the CVE identifiers in the package changelog, for example:
`rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'`
For `alt-php`, CloudLinux provides this example:
`rpm -q --changelog alt-php82-common | grep -E 'CVE-2026-(109618|109619)'`
Security advisory metadata is not yet available for every package, so security-only update filters may not list the fixes. Follow CloudLinux's documented regular-update path for the relevant package family.
Imunify360 rulesets 8.83 through 8.85 add detection and blocking for known exploit requests. Ruleset 8.84 extends relevant blocking to LiteSpeed. CloudLinux notes that these rules focus on the session-upload-progress path and do not fully cover CVE-2026-109618's out-of-memory path.
Update versus temporary mitigation
The distinction is important:
- Updating PHP or installing a vendor backport fixes the vulnerable code.
- Restarting services loads the patched code into active workers.
- Changing PHP settings reduces exposure to specific attack paths.
- A WAF rule blocks requests matching known patterns.
Only the first two steps complete remediation. PHP says there is no complete mitigation that replaces updating.
If a patched package is not yet available, review the full PHP advisory before applying temporary settings. Commonly discussed measures include disabling session upload progress at the server level, limiting request sizes, and enforcing corresponding limits at the web server or proxy. Test operational effects, document the change, restart all affected workers, and remove temporary settings only after confirming the vendor fix.
How to verify the update
A reliable completion check covers more than the default PHP command:
- list every PHP branch assigned to hosted websites
- confirm each branch reports the vendor-fixed release, build date, or changelog entry
- confirm cPanel internal PHP or Plesk `sw-engine` is fixed
- restart the relevant web server and PHP workers
- test representative websites, uploads, login flows, control-panel access, and webmail where applicable
- verify Imunify360 ruleset 8.85 where the WAF is enabled
- record the result for every server or node in the fleet
On Plesk for Linux, Plesk documents checking a specific handler directly. For example:
/opt/plesk/php/8.3/bin/php -v
For vendor-backported packages, use the vendor's changelog or build-date check. A lower version number does not necessarily mean the package is unpatched, and a patched default CLI binary does not prove that every website handler is fixed.
Reference Sources
- PHP security advisory and fixed releases: https://www.php.net/
- cPanel & WHM release notes: https://docs.cpanel.net/release-notes/release-notes/
- Plesk security advisory: https://support.plesk.com/hc/en-us/articles/44397729587351-Vulnerability-CVE-2026-109618-and-CVE-2026-109619-Remote-code-execution-in-PHP-shipped-with-Plesk
- CloudLinux live status: https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5
- CloudLinux package status and Imunify360 guidance: https://blog.cloudlinux.com/php-cve-2026-109618-and-cve-2026-109619
