Why Forgotten Sites Become a PHP Patch Problem

PHP's security team released fixes on Wednesday, 21 October 2026, for two critical flaws, both rated CVSS v4.0 9.2, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The flaws, CVE-2026-109618 and CVE-2026-109619, sit in PHP itself, the open-source scripting language, rather than in any one application.

Details circulated before that date. Cyber Daily reports that the embargoed release had been due Thursday at 11 a.m. ET, and that watchTowr confirmed the leaked information was real and reproduced one of the flaws. The PHP team's advance notice said it could release sooner if details became public or evidence of active exploitation appeared.

Patchstack says the flaws could let attackers run code on affected servers. Cyber Daily describes both as remote code execution flaws.

What PHP's Advance Notice Says

The notice, posted on 20 October, encourages all PHP users to prepare now so they can upgrade as soon as the release is available. It said full details, affected versions and fixed versions would be published with the release, and the 21 October advisory names the fixed versions.

The notice's two triggers for an earlier release are details of either flaw becoming public, and evidence of active exploitation appearing in the wild.

Patchstack says details leaked on 20 October, before coordinated disclosure. Cyber Daily reports that watchTowr's chief executive said patches were not yet available but expected the release to come significantly faster than the Thursday slot.

Who Applies a Runtime Patch

Patchstack reports that PHP core developers say updating PHP is the only full mitigation. It says any site on a vulnerable PHP version is exposed, and it names WordPress, Drupal, Magento, Joomla and Laravel among them. SecureLayer7's list of platforms that a core PHP flaw could reach adds Shopware and WooCommerce.

Neither source confirms that a given WordPress or Drupal site is affected. PHP's advisory says every PHP installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, so what matters is the PHP version on the server.

Patchstack advises: “If you’re on managed hosting, ask your host when they will apply it.” It advises anyone running an end-of-life PHP version to ask their host about upgrade options now.

Patchstack also advises finding every PHP install, including servers, containers, staging sites and software that bundles PHP. It warns against unofficial fixes, such as plugins and copy-pasted snippets, which it says are unverified and can break sites.

Patchstack's page also covers a separate incident. It says an attacker holding valid UpdraftCentral dashboard keys is installing backdoors on connected WordPress sites, and it advises deleting those keys.

Unmaintained Sites and Unsupported Branches

SecureLayer7 says a large share of PHP in the wild sits on shared hosting and older stacks that nobody actively maintains. It calls end-of-life PHP the hard problem.

Independent estimates put the number of internet-facing hosts on unsupported PHP versions in the high hundreds of thousands, according to SecureLayer7. It cites one estimate at roughly 884,000.

If the affected range reaches back to PHP 5.4, SecureLayer7 says servers on PHP 8.1, 7.x or 5.x will very likely never receive an official patch. It notes that PHP currently supports 8.2 and later. PHP released no new versions for 8.1 and older, but its security team published minimal source backports for 7.4, 8.0 and 8.1, which a host or agency that builds PHP from source can apply.

Exploitation Reports Differ by Source and Date

Patchstack says hosting partners have reported multiple active exploitation incidents. Its timeline places that report at 07:34 UTC. At 07:43 UTC, the same timeline records Cloudflare's chief technology officer saying Cloudflare is seeing early attacks and has deployed initial WAF rules for known exploit vectors.

Patchstack's own telemetry shows probing so far, with no hard evidence of breaches. It says it is unclear whether Cloudflare and others see probes or complete attacks, and that this could change once update details are public.

As of 20 October, SecureLayer7 says no in-the-wild exploitation has been confirmed. It reports that a leaked proof of concept called PHP2Shell is circulating, and it advises against downloading exploit bundles from unofficial pages.

SecureLayer7 attributes to security researchers an expectation of mass attacks within roughly 15 minutes of the PHP release. It describes that figure as a forecast rather than a measurement.

watchTowr says it will wait for PHP's patches before publishing further technical details.

The accounts therefore differ in what they describe. Patchstack reports incidents and probing, SecureLayer7 reports no confirmed exploitation, and watchTowr has so far described its reproduction of one of the flaws.

Severity and Affected Versions Remain Disputed

PHP's advance notice rates both flaws 9.2. Patchstack says 9.2 is the official rating and that some early reports gave 10.0. Cyber Daily reports that watchTowr considers both flaws a 10.

Affected versions are also contested. Cyber Daily reports that watchTowr says PHP 5, 6, 7 and 8 are affected. SecureLayer7 says reporting ranges from PHP 8 only to PHP 5.4.0 and later, and says that range is officially unconfirmed as of 20 October. PHP's 21 October advisory does not list affected version ranges; it names the fixed versions, 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Patchstack also reports, citing Japanese outlet ITmedia, emergency maintenance at several services believed to be linked to the flaw, including Shadowverse: Worlds Beyond. It also reports, citing Dutch broadcaster NOS, that Dutch government services, including DigiD and MijnOverheid, and the Dutch National Cyber Security Centre's site, are being taken offline as a precaution until the patch is out. The developers of The SEO Framework also took their servers offline.

Stop-Gaps Before the Patch and Their Limits

Patchstack's early analysis points to PHP's session upload-progress feature and to multipart file uploads. It suggests setting session.upload_progress.enabled to Off and session.use_strict_mode to 1, and says upload progress bars will stop working while uploads still go through. For blocking multipart requests, it advises matching loosely and case-insensitively, and testing first, because legitimate uploads can break.

SecureLayer7 describes the upload-progress setting as an unverified, community-suggested stopgap based on a speculated root cause. It says this may not close every path and is no substitute for patching. It considers turning the feature off sensible because the feature is rarely needed. It calls blocking large multipart POST requests a reasonable hardening step. Patchstack lists the same change among partial mitigations, suggested by some researchers until a patch can be applied.

Patchstack says these measures only reduce exposure. For high-risk sites that cannot be patched immediately, it says going offline or into maintenance mode is an option, and that the UK's NCSC gives similar advice.

SecureLayer7 treats virtual patching as a temporary delay rather than a fix. It warns that memory-corruption flaws of this kind are often reachable in ways that signature rules miss. CERT-EU, which SecureLayer7 cites, advises isolating internet-facing PHP applications where immediate patching is not feasible. Patchstack reports that Cloudflare's chief technology officer said the company's initial rules help only if the server accepts traffic exclusively from Cloudflare. Those initial rules are available to all customers, including free ones. Patchstack says the rules are a stopgap only, updated as new vectors appear.

Both sources say the stop-gaps are not a substitute for updating PHP. PHP's own advisory agrees: it says there are no complete mitigations and that updating is the only safe choice.