Update
Added after the original note below. PHP published the patches this afternoon. The sections under this box are that note, written before these builds were public.
The advisory names the fixed builds. Install one of these, restart PHP, and read the version back from the process serving traffic:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Source packages, and Windows source and binaries, are on the downloads page. Linux distributions and long-term support vendors received the patches ahead of the public note, so check those packages before building from source. The volunteer repository at rpms.remirepo.net will not have these builds today. PHP's advice is to use distribution packages, or build from source.
PHP 8.1 and older are outside the project's own updates. Some distributions still ship a backport. For people building from source, or without a vendor backport, the security team also published minimal source backports for PHP 7.4, 8.0, and 8.1.
CVE-2026-109618 - RCE via OOM corruption. On the supported branches, anything below PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 is affected. Scored CVSS v4.0 9.2: network, no privileges, no user interaction. Attack complexity is high, and the running setup has to meet the conditions in the advisory. The confirmed impact is unauthenticated remote code execution as the account the web worker runs as. Confidentiality, integrity, and availability of that process are high.
PHP leaves the request with longjmp() when it runs out of memory. If that happens while request memory is only partially initialised, shutdown can read or branch on the invalid state. The allocation that failed does not have to be the memory that is invalid. The advisory names use after free (CWE-416), improper handling of an exceptional condition (CWE-755), access of an uninitialised pointer (CWE-824), uncontrolled sequential allocation (CWE-1325), and incorrect initialisation of a resource (CWE-1419).
Where it was checked - Complete remote code execution was validated over HTTP against Apache mod_php, on default input and memory limits, before any application code runs. mod_php still runs request shutdown when startup has already failed. PHP-FPM exits the child when startup fails, which closes that path. After a normal FPM startup, an out-of-memory exit can still leave invalid state for shutdown. The advisory treats FPM as susceptible, and records that no complete FPM exploit has been demonstrated. Source review puts FrankenPHP with mod_php, so an attack that does not depend on the application is likely. LiteSpeed LSAPI follows the FPM model: application-specific exploits are likely there, and were not validated. php-cgi stays in the range named on the PHP release note. This advisory does not add a separate check for it.
CVE-2026-109619 - Unauthenticated remote code execution via stale global state (GHSA-6wmf-4rv5-p3rp). Request-owned internal state can survive after the memory behind it has been freed. A later request on the same worker can use that stale state before normal initialisation resets it.
The fix - The patch stops using longjmp() for out-of-memory, so shutdown no longer sees that invalid state. A release that contains the patch is the only complete mitigation. If the binary cannot go on immediately, set and enforce memory_limit=-1 so no pool, directory, or application puts a finite limit back, then restart every worker. That removes the predictable per-request limit. It is not complete. An underlying allocation failure can still take the old path. Do not use RLIMIT_AS or RLIMIT_DATA. A container memory limit is not a substitute unless the killed worker is replaced on its own. Also follow the remediation on GHSA-6wmf-4rv5-p3rp for CVE-2026-109619.
The PHP security team published an advance notice on 20 October 2026 for a critical security release that is scheduled for today, Wednesday 21 October, at 14:00 UTC (15:00 in the UK). It covers two vulnerabilities, both critical rated at CVSS v4.0 9.2. The notice asks every PHP user to be ready to upgrade the moment the builds are available. The details reached social media this morning. PHP's notice says it may publish earlier than 14:00 UTC when that happens, or if either issue shows up in active exploitation.
What is public
PHP's notice still holds the root cause and the fixed version numbers for the 14:00 UTC release. The names and the impact are already public. They leaked on social media ahead of the coordinated window, and by this morning they were circulating with CVE numbers attached.
The pair is CVE-2026-109618 and CVE-2026-109619. Reporting describes both as remote code execution in PHP itself. Someone who can reach a vulnerable PHP process could get that server to run commands. watchTowr told BleepingComputer the issues are real, and that it has reproduced CVE-2026-109618. It is holding the technical write-up until the patches ship. Huntress published the same picture this morning. watchTowr's FAQ is the page being updated as the leak spreads, and CERT-EU has issued a note on the pair.
The leaked posts scored both at 10.0 and put the range at every PHP from version 5 onward. PHP's notice scores both at CVSS v4.0 9.2. The affected-version list is still due with the builds. Until that list arrives, plan for the wider range in the leak, against the 9.2 score PHP has published. No fixed build number is public yet.
The blast radius
The issues are in the PHP runtime and the blast radius is every service executing PHP on a version the release names. That is a huge blast radius given the number of sites that run PHP (over 70% of the web).
These are some of the most popular products we see running PHP on the affected runtimes, and there are many more:
- WordPress and WooCommerce. In the W3Techs cut from 20 October, WordPress was 39.6% of all sites. That share runs on PHP.
- Drupal, Joomla, and TYPO3. The other long-running CMSs on the same runtime.
- Craft CMS, Statamic, Concrete CMS, and ExpressionEngine. Smaller CMSs, same PHP.
- Magento Open Source and Adobe Commerce. Self-hosted shops.
- PrestaShop and OpenCart. Self-hosted shops.
- Laravel and Symfony, including the custom applications built on them. A framework update leaves this in place. The PHP binary underneath is the patch.
- Moodle, MediaWiki, Nextcloud, Matomo, and SuiteCRM. Widely deployed PHP applications outside the CMS list.
- phpMyAdmin, WHMCS, cPanel, and Plesk. Admin and billing tools that run on PHP, often on the same machine as the site.
Shopify, Wix, Squarespace, and Webflow sit with the vendor. The vendor ships the platform update. A self-hosted WordPress, Drupal, Magento, or Laravel app is on the server you operate, or the host operates for you, and that PHP is the one this release is for.
The supported branches today are 8.2, 8.3, 8.4, and 8.5. PHP 8.2 is on security fixes only, through 31 December 2026. Anything older is end of life. Today's packages cover the supported branches, so those sites need a move onto one of them on the same timetable as the patch. PHP 8.6 is still a release candidate, with RC4 planned for 22 October, so a production site stays on 8.2, 8.3, 8.4, or 8.5. The release note will name the versions the packages actually fix, so read that list before treating a branch as clear.
What we are doing
All affected Pendulum clients we host are already on the holding pattern, and we encourage other providers to do the same:
Non-critical services - PHP is disabled, and the service cache in front of them is disabled. Those boxes are idle on this runtime: no PHP process answering, and no stored dynamic response being served in its place. They come back once the patched PHP is installed and the running version has been checked.
Services that have to stay up - temporary rules on the web application firewall, in place to reduce exposure across the gap. The rules stay until the patched PHP is the process serving traffic, and then they come off. The rule covers the wait. The upgrade closes the issue.
When the builds are public we install them, restart PHP so the new binary is the one in memory, and read the version back from the running service. The upgrade is finished when that version matches the release.
If you run the server
Have the list of services that still execute PHP and be in a position to upgrade at 15:00 UK, or earlier if PHP moves the release forward.
Where a service can be off for the afternoon, disable PHP and disable the cache in front of it. Where it has to stay up, a temporary WAF rule is the holding measure, kept until the patched runtime is verified. This will only be in place for a few hours.
Upgrade from the builds PHP publishes with the release, restart the PHP process after the install, and read the version back from the running service.
The skipped process
Tenable reports that Cloudflare's Dane Knecht is seeing early attacks, and that the company is updating its rules as new variants appear. He called the rules a stopgap and pointed operators at today's 14:00 UTC release. The attacks are underway before that build exists.
Proof-of-concept code is going up in public repositories while the patch is still unpublished. The shortcut is a coding assistant. The leak goes in, a script comes out, and the repository is public the same hour. The established process has an order. You confirm the issue with the vendor. You hold the proof until the patched build is out. You publish so the people running the servers can test the fix. watchTowr reproduced CVE-2026-109618 and kept the write-up back. That is the process.
A public proof this morning hands a script to anyone scanning for PHP, hours before the binary that closes the issue is on the mirrors. An assistant will draft that script. Publishing it is a human decision, and that decision is what is widening the window. The useful note is still the one PHP ships at 14:00 UTC, with the versions and the fixed builds. PHP's notice stays the source for the release itself.