PHP ships emergency patches for two critical flaws that allow unauthenticated code execution
On October 21, 2026 the PHP team released emergency security versions for two critical flaws that can lead to remote code execution without authentication. CVE-2026-109618 and CVE-2026-109619 are both rated 9.2 on CVSS v4.0, and the fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
PHP released emergency versions for two critical flaws
The PHP project's security advisory dated October 21, 2026 says PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 close two critical vulnerabilities that can allow unauthenticated remote code execution. It treats every PHP installation that serves web requests as at risk and urges all users to update right away. The flaws are being called PHP2Shell; PHP's own announcement does not use that name, while Cloudflare and the press do. According to BleepingComputer, researchers have begun using the name.
The process began a day earlier. On October 20 PHP gave advance notice and scheduled the release for October 21 at 14:00 UTC, reserving the right to publish sooner if details leaked or exploitation appeared in the wild. BleepingComputer writes that security researchers at Calif, Wiz and OpenAI found the flaws. In OpenAI's own account, Calif used GPT-5.6 Sol to find one critical flaw, while Wiz independently discovered and reported both. Linux distributions and LTS vendors got the patches in advance.
Two flaws turn a memory error and stale state into code execution
The advisory labels CVE-2026-109618 as remote code execution through out-of-memory corruption: when memory runs out, PHP can be interrupted while internal request data is only partly initialized, and request cleanup may treat the invalid data as valid. CVE-2026-109619 works through stale global state: request-owned internal state can outlive the memory behind it, and the next request served by that same worker can pick it up. The advisory lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as exposed ways of running PHP, with mod_php at highest risk. PHP says an exploit has been demonstrated against mod_php in which a request without credentials sets off the attack before the application's own code has started.
The picture differs for older versions. The PHP project has stopped updating 8.1 and earlier; for people who compile PHP themselves, the security team published small backport patches for 7.4, 8.0 and 8.1, and some distributions and LTS vendors ship backported fixes, so the advisory points people to their vendor. The PHP 8.2.35 release note also puts the 8.2 branch's end of life at December 31, 2026. Interim mitigations include memory_limit=-1, a low post_max_size and session.upload_progress.enabled=0, but the advisory says these reduce exposure without making an installation safe and that only updating is a complete fix. It also advises against RLIMIT_AS or RLIMIT_DATA, since they could trigger the vulnerable allocation failure.
Reports on in-the-wild activity differ, and the scale is large
On attacks the sources do not say the same thing, so each claim stays with its source. PHP says an exploit has been demonstrated for mod_php. Cloudflare's own blog says the flaws leaked before the official release date and that it observed attack traffic aimed at its customers. According to BleepingComputer, Cloudflare CTO Dane Knecht confirmed the company saw early attacks aimed at both flaws before the patches, and he called Cloudflare's WAF rules temporary. TechCrunch writes that, according to OpenAI, researchers found the flaws before attackers did, so there were no reports of exploitation in the wild. Cloudflare switched on its default protection at 03:02 UTC on October 21, roughly nine hours before public disclosure, adding seven new rules to its Free Managed Ruleset. Its blog says: "Keep Cloudflare WAF protections enabled while patching." The company adds that a WAF is an extra layer, that code or plugin updates do not close the flaws, and that the PHP update has to be applied by the administrator or hosting provider.
On scale, BleepingComputer cites VirusTotal estimates of more than 5.1 million internet-facing PHP servers, about 3.8 million of them with at least one open port, and says PHP powers roughly 75 to 80 percent of websites; TechCrunch cites roughly 70 percent. BleepingComputer also reports that the UK NCSC told organizations to update immediately or take systems offline until patched. Search Engine Roundtable, citing Reuters, says some European government, school and hospital websites went offline on Wednesday. The same article says Google's John Mueller advised anyone taking a site down for an unplanned update to return HTTP 503 rather than timeouts, 404s or 500s, and noted that this can be done outside PHP, through DNS or a CDN.
The sources say nothing about Türkiye, so this section is commentary
We opened all eight source pages for this article and none of them mentions Türkiye. Which PHP version Turkish hosting providers run, when they will patch, whether local institutions were affected and whether any Turkish authority has issued a warning cannot be answered from these sources. This section is therefore not a fact drawn from them but explicitly UNALSOFT commentary.
Our reading is that most small and mid-sized business sites run on PHP-based systems such as WordPress, and the PHP version is usually managed by the hosting provider. TechCrunch reports that WordPress calls the flaw not specific to WordPress and tells site owners on its CMS to get their servers patched together with their hosting companies. A plugin update therefore does not close this hole; the real question is when the provider applies the patch. We covered what a PHP version requirement means for online stores on September 29, and that article is independent of these flaws.
The UNALSOFT view
We reduce this story to three questions for a site owner: which PHP version your hosting provider runs, when the patch will be applied, and how search visibility is protected if the site has to go down for the update. Mueller's 503 advice answers the last one plainly: during maintenance, return a response that states the downtime is temporary instead of letting requests time out. That is why in website design we treat settling version, patching and the maintenance window as its own early step. Because the sources carry no data about Türkiye, this article proposes no local legal or technical conclusion.
Sources
PHP.net, security advisory (front page) · PHP.net, 2026 news archive · Cloudflare Blog, WAF protections against the PHP vulnerabilities · BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws · BleepingComputer, PHP warns admins of two critical flaws · Search Engine Roundtable, Google and PHP2Shell · OpenAI, coordinated disclosure of critical vulnerabilities · TechCrunch, ancient PHP holes panic the internet
Do you know which PHP version your site runs and whether it is patched?
A short conversation is enough to settle which version your hosting provider runs and what the maintenance plan is.