On 21 October 2026 the PHP project published two critical vulnerabilities affecting a broad range of PHP versions.
This is a summary of what they are, what we did about them, and what you may notice as a result.
CVE-2026-109618 and CVE-2026-109619, both scored 9.2 (Critical) under CVSS 4.0. In a nutshell, the first involves PHP's handling of memory exhaustion while it is still setting up an incoming request: the cleanup path can act on data that was never fully initialized. The second involves state belonging to one request outliving it and being reused by a later request on the same worker process.
This is a general description, but one thing worth flagging, because it circulated widely: several early public write-ups described the underlying cause incorrectly. The original claim was retracted by its own author within a day. We verified the advisories against the PHP project directly rather than acting on the secondary reports, which is why our response targeted the right conditions from the start.
On the 21st Oct, at 14:00 UTC The PHP project published advisories and source releases, we assessed exposure and PHP environment configurations to all our nodes and our vendor packages were not immediate to the platform we operate - so we had a immediate temporary hardening which took place on the same day closing multiple paths for both CVEs.
At the same time, we implemented firewall rules in our Web Application Firewall - built specifically to block requests that could be flagged as taking advantage of these CVE.
Between the 21-23 Oct patched builds started to be released and were installed as soon as they were reachable, PHP workers restarted on each server.
During this time our platform vendor issued the security fix into the existing PHP release rather than shipping a new version number. A fully patched server still reports PHP 8.2.34, while the upstream fix is labelled 8.2.35 (for example). This means the PHP version number shown in cPanel is not a reliable way to tell whether your server is patched.
The build date shows clearly that packages were built on the 21Oct even if had the 'old' version such as 8.2.34.
PHP.INI Adjustments:
session.upload_progress.enabled is off. This is the feature that lets a page poll PHP for the progress of a file upload. It is part of the mechanism one of the two flaws relies on, so we disabled it across all PHP versions. Uploads are not affected, this is a simple feedback feature.
Maximum request and upload sizes were reduced temporarily to 32 MB per request and 16 MB per file, narrowing the window in which the first vulnerability can be triggered.
fatal_error_backtraces off on PHP 8.5 simply limits the details PHP prints when a fatal error occurs. It affects diagnostic output only, and only on PHP 8.5.
We found no evidence of exploitation. We have carefully checked for the distinctive traces when an attempt to take advantage of these vuln fails, related to the PHP worker crash. This means simply an absence of evidence, and we will describe it as exactly that rather than as a guarantee.
There is no recommendation we can give, if you have blocked access to your website, note that patches have been implemented and you can allow for visits.
Regardless of this CVE, keep your applications and plugins updated! The vast majority of vulnerabilities we see on shared hosting come from outdated application code, not from the PHP interpreter.
We are happy to help, please open a ticket if you have questions
Friday, October 23, 2026
