PHP CVE-2026-109618 and CVE-2026-109619: What the Emergency PHP Patch Means for Your WordPress Site

On October 21, 2026, the PHP project released emergency updates for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619. They sit inside PHP itself, not in WordPress, a plugin, or a theme. That means no plugin update and no clean-up of your own code can fix them. The only complete fix is a newer PHP.

We updated PHP on MagicWP quickly, and we have retired the old versions that no longer get regular fixes. This article explains what the two flaws are, which versions contain the fix, what to do if you run your own server, and what we changed on our side.

TL;DR

• Both flaws are rated 9.2 on the CVSS v4.0 scale and can allow an unauthenticated attacker to run code on a web server, according to the PHP project.
• The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Updating WordPress or plugins does not fix this.
• On MagicWP, PHP has been updated to those four versions. PHP 7.4, 8.0 and 8.1 are no longer available.
• Config changes such as session.upload_progress.enabled=0 reduce exposure but are not a fix. PHP says updating is the only safe choice.
• If you manage your own server, update the PHP package, then restart every PHP worker.

What did PHP fix on October 21, 2026?

PHP published a security advisory describing two vulnerabilities in the runtime, both rated critical. Each scores 9.2 on CVSS v4.0, with no privileges and no user interaction needed. The project gave a day of notice. On October 20 it said a security release was scheduled for 14:00 UTC on October 21, and that it could go out earlier if details became public.

Press coverage has nicknamed the pair php2shell. The PHP project's own advisory does not use that name, so you will see both terms.

Both advisories are public on the php-src GitHub repository (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp), and the PHP news page carries the summary and update instructions.

How do these flaws work, in plain terms?

Both bugs are about what PHP does when a request goes wrong halfway through. They are memory handling bugs, the kind where PHP reads or frees memory it should not touch. That is why the result can be code execution rather than just a crashed page.

CVE-2026-109618: running out of memory at a bad moment

When PHP runs out of memory, it jumps out of whatever it was doing and abandons the request. The advisory says that in some places request memory is already reachable before it has been fully set up. If an allocation fails at that point, PHP leaves that memory in an invalid state. The shutdown step then reads it.

An attacker does not need a huge request to cause this. The advisory lists several multipart upload tricks that can push PHP into running out of memory while staying inside its apparent limits. One is a multipart request with no usable declared content length. Another is a part carrying an unrestricted number of headers, which take far more memory inside PHP than on the wire. A third is a pile of empty file fields, which do not count toward max_file_uploads but still create arrays.

The patch removes that jump for out-of-memory errors. PHP now waits for a safe point and stops gracefully, and if memory use reaches a second, higher threshold it ends the process immediately with _exit().

CVE-2026-109619: leftovers from the previous request

PHP workers are long-lived processes that handle many requests one after another. PHP keeps some global state, such as error, session, and object state, that points at memory belonging to one request. That state has to be cleared before the memory is released. The advisory describes cases where it is not cleared, for example because a fatal error cut an operation short. Fatal errors include timeouts and out-of-memory failures. The next request on the same worker can then touch memory that has already been freed, before PHP has finished starting that request.

For this one, an attacker needs two steps: a first request that leaves stale state behind, and a later request on the same worker that uses it. The advisory confirms two paths. One is a PHP 8.5 feature, fatal_error_backtraces. The other is session upload progress, which is switched on by default and does not need your code to call session_start().

Who is affected?

The PHP advisory says every installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It singles out mod_php as the highest risk.

The reason is specific. Apache's mod_php always runs the shutdown step, even when request startup failed. The advisory says a demonstrated exploit can trigger the attack with one unauthenticated request before any application code runs. In that setup, a site with perfectly written code is still exposed.

PHP-FPM behaves differently, because FPM exits the worker when startup fails. For CVE-2026-109618, the advisory says source analysis supports FPM as susceptible, but no complete FPM exploit has been shown. For CVE-2026-109619, the session path was validated against both mod_php and FPM, though the FPM route depends on a suitable operation inside the application.

Two more points are worth knowing. The confirmed impact includes memory disclosure as well as code execution, and code runs with the permissions of the web worker account. Also, because the flaws live in the runtime, they apply to WordPress sites the same way they apply to any other PHP application.

Which PHP versions contain the fix?

The advisories list four branches as affected below these versions, and fixed in them:

PHP 8.2 reaches end of life on December 31, 2026, and the 8.2.35 release notice says so directly. If you are on 8.2, update to 8.2.35 now and plan a move to a newer branch. WordPress.org currently recommends PHP 8.3 or greater, so 8.3 or newer is a sensible target. Dates and recommendations change, so check the php.net supported versions page and the WordPress.org requirements page when you plan.

Linux distributions and long-term-support vendors received the patches in advance. A package from your distribution may carry the fix under an older-looking version number, so check the package changelog for the CVE number instead of trusting the version string alone.

What did MagicWP do?

We updated PHP on MagicWP to the fixed release for each branch we offer: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Because the flaws are in the runtime, this was a platform-level change, and not something site owners had to fix inside WordPress.

We also removed PHP 7.4, 8.0, and 8.1 from availability. The PHP project no longer updates 8.1 and older. For 7.4, 8.0, and 8.1, the PHP security team did publish minimal backports on source branches, aimed at people who build PHP from source or have no access to a long-term-support vendor. That is a workaround for a specific day, not a maintained release line, and every new advisory would put you in the same position again. In our view, customer sites should not run on a version that only gets fixes this way.

If you have code that was written for one of those retired versions, test it on a supported version before you rely on it. WordPress.org says WordPress also works on PHP 7.4 and later, but it labels those older versions as end of life and says they may expose your site to security problems. Use staging to try a newer PHP without touching your live site, and take a backup first. MagicWP keeps daily off-site backups with one-click restore, and you can take an on-demand backup before any change.

How do I check which PHP version my site runs?

If you run your own server, or you want to confirm what your host is doing, start with the version that serves web requests. This is not always the same as the command-line version.

In WordPress, open Tools, then Site Health, then the Info tab, and look under Server. The menu names can shift between WordPress versions, so treat this path as a guide. Over SSH, WP-CLI shows the PHP binary and version it uses:

wp cli info

To see what your command-line PHP reports, and to check whether a distribution package already includes the fix, you can run these on a Debian or Ubuntu style system. The package name depends on your setup, so replace the placeholder:

php -v
apt changelog <php-package-name> | grep CVE-2026-109618

On RPM-based systems, the equivalent is rpm -q --changelog <php-package-name>. If the CVE does not show up and the version is below the fixed releases in the table, you are probably not patched yet.

After you install the update, restart Apache, PHP-FPM, and any long-running PHP workers. The advisory stresses restarting every worker, because an old process keeps running the old code until it is replaced.

What if you cannot update yet?

PHP's guidance is direct. Only an update is a complete fix, and the steps below reduce exposure to specific attack paths without making a server safe. Use them only as a bridge until you can update.

For CVE-2026-109618, the advisory suggests setting memory_limit=-1 in a way applications cannot override, for example with php_admin_value in the FPM pool or the Apache configuration. It also suggests a low post_max_size, such as 8M if the site needs no uploads and 32M if it does, with upload_max_filesize kept below it. Enforce size, field-count, and part-count limits at the web server or proxy as well.

For CVE-2026-109619, disable session upload progress and restart every worker. On PHP 8.5, also turn off fatal error backtraces. A pool file might look like this, with your own limits in place of the example values:

; FPM pool configuration (file path varies by distribution)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[session.upload_progress.enabled] = 0
; PHP 8.5 only:
php_admin_value[fatal_error_backtraces] = 0

There are three things to watch. First, memory_limit=-1 removes PHP's own cap, so a runaway script can eat all the memory on the machine. The advisory suggests a container or cgroup limit as an availability boundary, ideally one that kills only the affected worker. Second, do not use RLIMIT_AS or RLIMIT_DATA as a substitute, because they can trigger the same vulnerable path. Third, session.upload_progress.enabled=0 blocks the confirmed session paths but not every variant, and fatal_error_backtraces=0 blocks only the one confirmed backtrace path.

For CVE-2026-109619 specifically, the advisory says there is no complete configuration-based mitigation at all. It also asks you to remove deprecated or invalid INI settings that print warnings before a request starts, and to fix any attacker-reachable fatal errors or timeouts. Hiding warnings with error_reporting, display_errors, or the @ operator does not help.

What changes after you update?

The fix adds a new hard memory limit. When PHP reaches it, the process ends immediately with _exit(), without the usual cleanup. So after you update, review memory_limit and post_max_size against what your application really needs, and test heavy pages such as imports, exports, and large uploads.

The CVE-2026-109619 advisory also suggests keeping session.upload_progress.enabled off even after you patch if you do not use the feature, since it is rarely used and rarely tested. If your site does not use it, that costs you nothing.

Is anyone exploiting these flaws?

This part changes quickly, so read it as a snapshot from October 21, 2026. Cloudflare said it saw attack traffic against its customers while the details were leaking ahead of the planned release. It also said attackers were changing their payloads to try to get past its firewall rules, and it deployed rules that block by default for customers on its WAF. The Hacker News reported that no source had confirmed a successful break-in at the time it published. A watchTowr update from the morning of October 21 also listed no reported exploitation.

Cloudflare itself says to patch even with those protections on. A WAF is another layer, not a repair, and the PHP advisory says that for these flaws only updating is complete. Check the PHP news page and the sources named at the end of this article before you act on any claim about exploitation, because new reports could change the picture within hours.

Frequently Asked Questions

Do I need to update WordPress or my plugins to fix these flaws?

No. CVE-2026-109618 and CVE-2026-109619 are flaws in the PHP runtime, so updating WordPress, a theme, or a plugin does not remove them. The fix comes from a PHP update, which on a managed host is something the host applies, and on your own server comes from your package manager or a source build. Keep WordPress and plugins current for their own reasons, but treat this as a PHP task.

Which PHP version should I run today?

Run the newest branch your site supports, patched to the fixed release: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. WordPress.org currently recommends PHP 8.3 or greater. PHP 8.2 reaches end of life on December 31, 2026, so if you are on it, update to 8.2.35 now and plan to move up. Always test the new version on a staging copy first.

Is a web application firewall enough?

No. Cloudflare, which deployed default firewall protections for these flaws, says customers should still patch PHP and keep the firewall on as an extra layer. The PHP advisory says that updating is the only complete mitigation, and that configuration changes only reduce exposure to some attack paths. A firewall can block known request patterns, but it cannot change how the runtime handles memory.

Can I use the configuration workarounds instead of updating?

Only as a short bridge. Setting memory_limit=-1, keeping post_max_size low, and turning off session.upload_progress.enabled each close specific paths. For CVE-2026-109619, PHP says no configuration change fully mitigates it. If you must wait, apply the settings, restart every worker, add limits at the web server, and update as soon as you can.

What about PHP 7.4, 8.0, and 8.1?

The PHP project no longer updates 8.1 and older. For 7.4, 8.0, and 8.1, the PHP security team published minimal source backports for people who build PHP themselves, and some distributions and long-term-support vendors ship their own fixes. MagicWP has removed these three versions. If your code needs one of them, test it on a supported version, because staying on an unsupported branch means facing the next advisory without a patch.

Will updating PHP break my site?

These are point releases within a branch, not a jump to a new major version, so most sites should see no change. The fix does change how PHP behaves when memory use reaches its hard limit, so review your memory and upload limits and test imports and large uploads. Move to a new branch, such as from 8.2 to 8.3, only after testing on staging, with a backup ready.

How would I know if someone tried to exploit this on my server?

It is hard to be sure, and the advisory warns that missing errors in your logs do not prove safety. The researchers, as reported by The Hacker News, suggest watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oddly large PHPSESSID response cookies, and unexplained restarts of PHP workers. If you suspect a break-in, restore from a backup taken before the date in question and rotate secrets, because the flaws can expose memory.

Do these flaws affect sites that are not using WordPress?

Yes. They affect PHP in general, and the PHP advisory covers every installation that serves web requests. The advisory lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. Cloudflare says the flaws affect web servers running PHP 5.4 or later, which is a far wider range than the branches PHP still patches.

Conclusion

The short version is simple. CVE-2026-109618 and CVE-2026-109619 are runtime bugs, rated 9.2 by the PHP project, and the fix is PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Config tweaks help a little, a firewall adds a layer, and neither replaces the update. If you run your own server, update, restart every worker, and then recheck your memory limits.

On MagicWP, we updated PHP to those versions quickly and retired PHP 7.4, 8.0, and 8.1, so those flaws are not something you need to patch yourself in WordPress. If you are weighing where to host a site that needs to keep up with PHP fixes like this, take a look at MagicWP's managed WordPress hosting and its security features.