Critical PHP flaws CVE-2026-109618 and 109619: what to do today

On Wednesday 21 October 2026 at 14:00 UTC the PHP security team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2 out of 10. According to PHP they allow unauthenticated code execution on the server, before any of your application's code even runs. The identifiers and a tool nicknamed PHP2Shell leaked a day before the release, so attackers had a head start and hosting providers rolled out stopgap measures. This article sums up what is officially confirmed, how providers are responding and what each kind of site owner should do. Updated 21 October 2026, 18:30 UTC: added the official release details, version numbers, backports and the rollout status at CloudLinux and nextHosting.

What happened: the fix is out, details leaked a day early

The official notice on php.net from Monday 20 October was short: a release on Wednesday at 14:00 UTC, two critical vulnerabilities rated CVSS v4.0 9.2, no identifiers and no affected components. The identifiers and the word "RCE" therefore surfaced elsewhere first. CERT-EU published Advisory 2026-018 on the evening of 20 October about possible unauthenticated remote code execution in all versions from PHP 5 onwards, and a post on Hacker News cited a "reliable source" talking about scores as high as 10.0 and a disclosure on 22 October. PHP pulled the release forward to 21 October; the official score is 9.2.

The release landed exactly on schedule. Alongside the four fixed stable versions, PHP 8.6.0 RC4 shipped with the same fixes for those testing the next branch, and PHP published a security advisory with details of both bugs. The flaws were reported by four researchers listed under handles in the GitHub advisories, including people from Wiz and OpenAI; the fix was written by four PHP core team members including Jakub Zelenka. The MITRE and NVD records were still only reserved at the time of writing.

What the bugs do: memory in an inconsistent state, not one specific function

A day before the release the community guessed the problem sat in session.upload_progress. The official description is broader and more interesting. Both bugs are in the PHP core, not in a specific extension, and concern how PHP handles a request's memory on a fatal error.

CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w). When PHP hits out-of-memory, it jumps out of the current context via longjmp(). In some situations request memory is reachable before it is fully initialised, and request cleanup then treats invalid data as valid. An attacker can push a request into OOM through the multipart parser without exceeding the configured limits.

CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). A PHP worker keeps global state between requests (errors, session, objects, extension state) that points into the previous request's memory. If a fatal error or timeout interrupts a request before that state is reset, the next request handled by the same worker can use the freed state, a classic use-after-free. Two paths are confirmed: INI diagnostics raised before request initialisation, and the session.upload_progress handler. On PHP 8.5 the state of fatal_error_backtraces adds a third.

PHP is explicit about who is most exposed: Apache with mod_php, where an unauthenticated exploit was demonstrated with no application involvement. FrankenPHP is likely susceptible for the same reasons, PHP-FPM is susceptible in principle (for the second bug the upload-progress exploit was validated on FPM too; for the first no complete FPM exploit was built) and LiteSpeed/LSAPI is likely susceptible but unvalidated. An attack typically takes several attempts, and both requests, the one that corrupts the state and the one that abuses it, must be served by the same worker.

The practical conclusion of both advisories is the same: updating is the only complete fix. Disabling upload progress or setting memory_limit are partial measures according to PHP, and no combination of settings makes an installation safe.

Who is affected: every branch, including the unsupported ones

Every PHP installation serving web requests is affected, which means WordPress, PrestaShop, Joomla and most e-commerce platforms. The difference is who gets the fix and how.

The supported branches 8.2, 8.3, 8.4 and 8.5 received official fixes. Branches 7.4, 8.0 and 8.1 are end-of-life and would normally get nothing. Given the severity, PHP made an exception and published minimal source backports for 7.4, 8.0 and 8.1. They are meant for people building from source or without an LTS vendor; there are no ready-made packages. Linux distributions and LTS vendors received the patches in advance, so packages should follow quickly. Why an old PHP version is a risk rather than just a performance problem is covered in our guide PHP versions and hosting risk. This Wednesday is a textbook example.

Is it being exploited? Cloudflare, CloudLinux and Patchstack reported the first attempts matching the leaked pattern on Wednesday morning, before the fix was out. The CISA KEV catalogue did not list the bugs at the time of writing. With September's WordPress core flaw, hours passed between disclosure and mass scanning; this time attackers held a tool before admins held a patch.

How providers are responding: nextHosting, CloudLinux and Cloudflare

Among Czech hosts, nextHosting (the Exon.io brand) is communicating most concretely on its status page. The provider's timeline for Wednesday 21 October:

CloudLinux, whose Alt-PHP and Imunify360 underpin a large share of shared hosting worldwide, is running its own incident. In the morning it pushed ModSecurity rules blocking the known exploit shape to Imunify360 (rulesets 8.83 to 8.85 over the day), and from 14:39 UTC it has been releasing fixed alt-php packages for every version from 5.2 to 8.5. The order is telling: the first packages out were alt-php74 (EL6 through EL10, Debian 10 and 11, Ubuntu 16.04 through 26.04), then alt-php80 and alt-php81, exactly the versions PHP itself does not package. cPanel's ea-php74 to ea-php85 are scheduled for EasyApache4 v25.91, and TuxCare ELS released fixed PHP 7.0, 7.2, 7.4 and 8.0 for old distributions. At the time of writing (18:22 UTC) the incident was still open and packages for 8.2 to 8.5 were not yet listed.

Cloudflare, according to its CTO, deployed WAF rules against the known vectors to all plans including Free. That only helps sites whose origin accepts traffic exclusively from Cloudflare addresses. Other Czech and Slovak providers have not commented publicly; the larger ones most likely follow CloudLinux's rollout, since they run on its technology.

What to do today, depending on where your site runs

Shared-hosting customer. The provider patches PHP on the server; here is what you can do:

1. Check which PHP version your site runs (hosting control panel, or Site Health in WordPress). If it is 7.4, 8.0 or 8.1, switch to the highest version your host offers and your site can handle. A backport exists, but whether your host deploys it is up to them.
2. Confirm your provider has deployed the fix. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; with Alt-PHP the version number does not change, so rely on the provider's announcement. If your host has published nothing, ask support specifically.
3. Expect upload restrictions. If the provider blocks multipart requests or has tightened its WAF, forms with attachments, product imports or media uploads may fail. That is not a bug in your site and should clear once the fix is in.
4. Keep a fresh backup off the hosting account. If a compromise happens, it is the only quick way back.

VPS or own-server admin. Here the responsibility is yours:

1. Update now to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's package with this fix. Distributions received the patches in advance, so they should not lag by days.
2. Restart every worker. PHP-FPM, Apache, FrankenPHP and LiteSpeed. Without a restart the old code keeps running, and for the second bug a long-lived worker is the heart of the problem.
3. If you cannot update immediately, PHP published interim measures with the explicit note that they do not make an installation safe: memory_limit = -1 enforced via php_admin_value in FPM or the Apache config so applications cannot override it; a low post_max_size (8M without uploads, 32M with them); session.upload_progress.enabled = 0 in php.ini or pool config, not via ini_set() or .user.ini; and on PHP 8.5 also fatal_error_backtraces = 0. Restart workers after every change. The second advisory also mentions pm.max_requests = 1, which makes every request considerably more expensive.
4. Sites on unsupported PHP should either be rebuilt from the official source backport or isolated until vendor packages are available.

Developers and agencies. Go through your client list by PHP version and host. Clients on Apache with mod_php and on old branches at providers without CloudLinux are today's highest-risk group and will probably need migrating, not just updating.

Summary

With the fix out, the picture is clearer, not calmer. Both bugs are in the PHP core, affect every web SAPI, and the most exposed setup is Apache with mod_php, still common on cheaper hosting. The only complete fix is updating to 8.5.12, 8.4.27, 8.3.36 or 8.2.35; every interim setting is partial according to PHP. The good news is that PHP exceptionally published source backports for 7.4 to 8.1 and CloudLinux shipped packages for the old branches first during the afternoon. nextHosting's response is worth noting not because it is painless, but because the provider transparently describes what it temporarily broke for customers. Over the coming days the thing to watch is how fast other hosts roll out the fix and who bothers to say so.