PHP2Shell: the critical PHP RCE flaw WordPress sites must patch

TL;DR: On 21 October 2026, the PHP project shipped emergency security releases for two critical flaws in PHP's core engine, nicknamed PHP2Shell and discovered by Wiz Research. They are memory-safety bugs triggered when PHP hits a fatal error (especially running out of memory) while handling a request, and they can be chained into unauthenticated remote code execution. Because the bug is in PHP itself, not in your plugin or theme, a fully updated WordPress or WooCommerce site on an unpatched PHP version can still be exposed. The permanent fix is to move to a patched PHP release (8.5.12, 8.4.27, 8.3.36 or 8.2.35 per current reporting, verify against php.net), or to ask your host to do it. Temporary settings and a WAF reduce risk but are not a substitute.

What PHP2Shell actually is

PHP2Shell is the name given to two vulnerabilities in the PHP core engine, disclosed publicly on 21 October 2026 by Wiz Research alongside the PHP project's patched releases.

• CVE-2026-109618: a use-after-free in the way PHP unserializes upload-progress data, which can leak process memory remotely. Wiz demonstrated it as pre-authentication remote code execution against default WordPress, Drupal and Joomla container images.
• CVE-2026-109619: a use-after-free in fatal-error backtrace handling combined with an OPcache type confusion, demonstrated against Drupal and WordPress.

Both belong to the same family: PHP hits a fatal error, often an out-of-memory condition caused by a crafted multipart request, and leaves stale pointers or stale internal state behind in the worker. A later request handled by the same worker can then read memory that belongs to someone else, or corrupt memory in a way an attacker can steer. Wiz chained those primitives into a working unauthenticated exploit, and says AI assistance helped build it.

Wiz's own headline puts severity as high as CVSS 9.2. Treat that as the ceiling reported for the pair rather than a score confirmed for each individual CVE.

Why this one is different from a plugin vulnerability

Most WordPress security advice, including much of what this blog has published, is about keeping plugins, themes and core updated. PHP2Shell is a reminder that there is a layer underneath all of that.

The flaw lives in the language runtime. Wiz states that exploitation does not depend on application code, so even a trivial "Hello World" script on an affected PHP version can be reachable. One of the memory-disclosure paths can surface leaked data through a PHPSESSID response cookie even if the application never calls session_start().

The practical consequence is simple: you can have every plugin patched, a hardened admin login, and a clean malware scan, and still be exposed until the PHP version underneath is updated. That update is normally controlled by your hosting provider or server administrator, not by anything inside WordPress.

Who is affected, and how much

Wiz reports that every PHP release from the last decade, back to PHP 5.4, is affected by at least one of the two bugs. Other reporting says the flaws apply to all PHP deployments that serve web requests, whether through PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed or FrankenPHP.

That covers practically every WordPress and WooCommerce site on the internet. A few details matter for how urgent it is for you:

• Attackers need only network access. No login, no plugin and no user interaction.
• mod_php is rated highest risk by the PHP team, since an unauthenticated request can trigger the attack before any application code runs.
• Unsupported PHP is the worst position. PHP 8.1 and older no longer receive updates from the PHP project. Minimal source backports were reportedly made for 7.4, 8.0 and 8.1, but sites still running those versions should be planning a migration, not hoping a backport reaches them.
• Exploit reliability varies with PHP version, configuration and application behaviour, which is why a working proof of concept does not mean every server falls over equally.

On in-the-wild activity, sources differ slightly. Wiz's write-up does not report observed exploitation, while BleepingComputer reports that Cloudflare's CTO said early attacks were already being seen before patches shipped. The safe reading is to assume scanning and exploitation attempts are under way or imminent.

Patched PHP versions

According to BleepingComputer's report of the PHP advisory, the fixed releases are:

PHP branch	Fixed version
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1, 8.0, 7.4	Minimal source backports only, no longer supported upstream
7.3 and older	No official fix, migrate

Wiz's article links to the official release notice rather than listing numbers, so confirm the exact versions against the PHP release announcement dated 21 October 2026 before you rely on this table. Linux distributions and long-term-support vendors may ship the fix as a backported package that keeps the old version number, so a version string alone does not always tell you whether you are patched. Check your distribution's security advisory for these CVE numbers.

What to do today: a step-by-step checklist

1. Find your PHP version. In WordPress, open Tools, then Site Health, then the Info tab, and expand Server. Or check the PHP selector in your hosting control panel.
2. Ask your host about the patch. If you are on shared or managed hosting, the host controls PHP. Ask directly whether the PHP2Shell fixes (CVE-2026-109618 and CVE-2026-109619) are deployed and on which versions.
3. If you manage your own VPS, update PHP through your package manager or your PHP repository, then restart PHP-FPM or Apache so workers pick up the new build. A package upgrade that is not followed by a restart leaves the old code running.
4. Move off unsupported PHP. If you are on 8.1 or older, schedule an upgrade to a supported branch. Test on a staging copy first, since plugin compatibility is the usual blocker.
5. Enable a WAF layer (covered below) as a stopgap while you patch.
6. Review logs for the warning signs listed further down.
7. Take a fresh backup before changing PHP versions, so a rollback is possible if a plugin misbehaves.

If you are a HostCloud customer, PHP version selection and updates are handled at the server level, so the practical step is to confirm your account is running a patched build rather than changing anything inside WordPress.

Temporary mitigations if you cannot patch yet

The PHP team has published interim hardening steps and is explicit that they do not fully protect against exploitation. Official patches are the only permanent fix. If you must wait, these reduce exposure:

For CVE-2026-109618 (out-of-memory path)

• Set memory_limit=-1, preferably locked so applications cannot override it, for example with php_admin_value in the FPM pool or Apache configuration.
• Set a low post_max_size: 8M if you do not need uploads, 32M if you do.
• Use a container or cgroup memory limit that kills only the affected worker.

For CVE-2026-109619 (fatal-error path)

• Set session.upload_progress.enabled=0 and restart all workers.
• On PHP 8.5, set fatal_error_backtraces=0 and restart all workers.
• Remove invalid or deprecated per-request settings that emit diagnostics before PHP is fully initialised. Hiding errors with error_reporting, display_errors or @ does not help.
• Fix any attacker-reachable fatal errors and execution timeouts in your own code.

Note the unusual advice to set memory_limit=-1. It runs against the usual WordPress tuning guidance covered in the PHP memory limit post, so treat it as a short-term emergency measure, not a long-term configuration.

What a WAF like Cloudflare does and does not do

Cloudflare deployed default WAF protection from 3:02 am UTC on 21 October 2026, roughly nine hours before public disclosure, and says it applies automatically on all plans with the WAF enabled, including Free. It uses seven "Generic Rules - Anomalous Execution" rules plus a full-transaction rule that can block a response before leaked data reaches the requester.

Two cautions apply:

• Cloudflare itself says this is defence in depth, not a fix. It does not claim coverage of every exploit variant.
• Professional, Business and Enterprise customers should confirm the managed ruleset is deployed in block mode, not just log mode.

If your site already sits behind Cloudflare, this is a worthwhile safety net while patching. It does not replace the PHP update.

Signs someone may already be probing your site

Because the bug sits below the application layer, WordPress logs may show little. Wiz suggests looking at server and access logs for:

• Unusual multipart requests followed by memory-limit errors
• Repeated HTTP 500 responses
• Unusually large or malformed PHPSESSID response cookies
• Unexplained PHP worker churn or restarts

If you see these patterns, patch first, then run a malware scan and review recently modified files (the malware scanning comparison and the Fail2ban post cover this ground), rotate any secrets stored in wp-config.php, and force a password reset for administrators.

A comparison table

Factor	Plugin or theme vulnerability	PHP2Shell (PHP runtime flaw)
Where the bug lives	A specific plugin or theme	PHP core engine
Fixed by	Updating the plugin or theme in WordPress	Updating PHP on the server
Who controls the fix	You, from the WordPress dashboard	Usually your host or server admin
Needs a vulnerable plugin installed	Yes	No
Authentication required	Often	None
Reduced by a clean, updated WordPress	Yes	No
Interim protection	Disable or remove the plugin	Hardening settings and WAF, not complete
Permanent fix	Plugin update	Patched PHP release

FAQs

Is my WordPress site vulnerable if all my plugins and themes are up to date?

Possibly yes. PHP2Shell is a flaw in PHP itself, so plugin and theme updates do not close it. What matters is the PHP build running on your server, which only your host or server administrator can update.

Which PHP version should I be running right now?

A patched build on a supported branch: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 according to current reporting, subject to confirmation on php.net. If you are on 8.1 or older, plan a move to a supported branch, since upstream no longer maintains those versions.

I am on shared hosting. What can I do?

You cannot patch PHP yourself on most shared plans. Contact your host and ask whether the fixes for CVE-2026-109618 and CVE-2026-109619 are deployed. Meanwhile, put the site behind a WAF such as Cloudflare, keep uploads limited, and take a backup.

Does changing the PHP version in my hosting panel fix it?

Only if the version you select is a patched build. Selecting a newer branch in the panel helps only if the host has already installed the fixed release for that branch. Ask the host to confirm the exact version.

Will Cloudflare or another WAF fully protect me?

No. A WAF blocks many known exploit patterns and Cloudflare has deployed rules for this, but it is an extra layer. Cloudflare itself recommends patching PHP regardless. Make sure the managed ruleset is in block mode.

Should I really set memory_limit to -1?

Only as a temporary measure from the PHP team's interim guidance, ideally locked at the server level so applications cannot override it. It removes a normal safety limit, so revert it once you are on a patched PHP build.

How do I know if my site has already been hit?

Look for repeated HTTP 500 errors after multipart requests, memory-limit errors, oversized or malformed PHPSESSID cookies and unexplained PHP worker restarts. Because the flaw works below the application, logs may be sparse, so a malware scan and a file integrity check after patching are sensible.

Conclusion

PHP2Shell is serious precisely because it sidesteps the usual WordPress defences: no vulnerable plugin, no login, and a flaw present in every PHP release of the last decade. The fix is not complicated, but it sits at the server layer, which means the first job is to find out whether your host has deployed the patched builds.

Check your PHP version today, confirm the patch status with your host, move off any unsupported PHP branch, and keep a WAF in block mode as a safety net while you do. Interim hardening helps, but only the patched release closes the hole.

If you would rather not manage PHP patching yourself, HostCloud handles runtime updates at the server level so your sites stay on patched builds. See our hosting plans at https://hostcloud.in.

Sources:

• PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, Wiz Research
• PHP ships emergency patches for critical PHP2Shell flaws, BleepingComputer
• Cloudflare deploys protections against php2shell vulnerability, Cloudflare