PHP2Shell: Critical PHP Security Release Fixes Two RCE Flaws. What WordPress Users Need to Do

On October 21, 2026, the PHP project released emergency updates for two critical vulnerabilities, now widely known as PHP2Shell, that can let an attacker run code on almost any web server running PHP. WordPress.org published its own critical PHP security release notice the same day, urging every site owner to update PHP immediately.

This is not a WordPress bug, and there is no WordPress update to install. The problem is in PHP itself, the language WordPress runs on, which means every WordPress site in the world is affected until the server it runs on is patched.

Here’s everything you need to know about PHP2Shell: what the two flaws are, how the news leaked a day early, whether attackers are using it, which PHP versions are fixed, and exactly what you should do if you run a WordPress site.

PHP2Shell at a glance

• What: two memory-safety bugs in the PHP engine, CVE-2026-109618 and CVE-2026-109619, both rated critical with a CVSS 4.0 score of 9.2.
• Impact: unauthenticated remote code execution. An attacker who can send HTTP requests to your server may be able to run commands as the web server user, with no login and no vulnerable plugin required.
• Affected: every PHP release since 5.4.0, on Apache mod_php, PHP-FPM, LiteSpeed and FrankenPHP.
• Fixed in: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026 at 14:00 UTC. Older branches get no official release, only vendor backports.
• WordPress: affected like any PHP application, but no WordPress core, theme or plugin update is required or planned.
• Exploited: yes. Honeypot hits were seen four days before disclosure, and hosting providers reported active attacks on the morning of the release.
• What to do: check your PHP version in Site Health, update PHP or confirm your host has, restart PHP, and apply the temporary mitigations below if you can’t patch yet.

What the two PHP2Shell vulnerabilities are

Both bugs live in the way PHP sets up, handles errors in and cleans up after each web request. They are use-after-free and memory corruption flaws rather than mistakes in any application’s code, which is why clean, well-maintained WordPress sites are just as exposed as neglected ones.

CVE-2026-109618: remote code execution via out-of-memory corruption

When PHP runs out of memory, it aborts the request abruptly. According to the official advisory, if that happens before PHP has finished initialising the request’s internal data, the clean-up code can treat partly built, invalid memory as valid and act on it.

Attackers can trigger the out-of-memory condition with a crafted multipart/form-data request, the same format browsers use to upload files. PHP parses these requests before any application code runs, so WordPress never gets a chance to reject them. The PHP security team confirmed unauthenticated remote code execution against Apache with mod_php using default settings. Security firm Sansec also notes that this flaw can leak memory from other requests, including passwords, session tokens and API keys.

CVE-2026-109619: remote code execution via stale global state

PHP worker processes handle many requests in a row. The second advisory explains that when a request ends abnormally, for example with a fatal error or an out-of-memory condition, some internal state can survive pointing at memory that has already been freed. The next request handled by the same worker can then use that stale state before PHP resets it.

One confirmed path uses the session upload progress feature, which has been switched on by default since PHP 5.4. Another, on PHP 8.5 only, uses the new fatal_error_backtraces setting. Exploitation was validated on both mod_php and PHP-FPM.

The PHP security team credits researchers at Calif.io, Wiz and OpenAI with reporting the flaws, and both Calif and Wiz have said they used AI models in their research. The fixes were written by core PHP maintainers Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka and Niels Dossche.

Which PHP versions are affected and fixed

The vulnerable code dates back to PHP 5.4.0, released in 2012, so the real affected range is fourteen years of PHP releases. PHP 8.2 is itself only three months from the end of security support, so if you’re still on 8.2, this is a good moment to plan a move to 8.3 or 8.4. Our guide on how to update the PHP version in WordPress walks you through it.

For the older branches, Linux distributions and hosting panels have shipped their own backported fixes. cPanel released patched packages for ea-php74 through ea-php85, and CloudLinux went further with patches all the way back to PHP 5.2. Plesk rebuilt PHP 7.4, 8.0 and 8.1 on October 21 and recommends TuxCare’s paid extended support for 5.6, 7.2 and 7.3, which have no fix. Debian 12 and 13 and Ubuntu 24.04 and 26.04 issued security updates; Ubuntu 22.04 got a backport; Debian 11 gets nothing, because its long-term support ended in August.

How the news broke: a leak and a rushed release

Critical PHP releases are normally announced a few days ahead so that hosts can prepare. This one did not go to plan.

• October 17: Amazon Threat Intelligence later reported that its MadPot honeypot network recorded an exploitation attempt four days before anything was public. How the attacker knew about the flaws is unclear.
• October 20: The PHP security team posted an advance notice of a release on October 21 at 14:00 UTC, moved forward from October 22. Within hours, the CVE identifiers and technical details leaked on Hacker News and social media, a screenshot of an exploit tool called “PHP2Shell” circulated, and the name stuck.
• October 21, early morning: A leaked archive of vulnerability details was uploaded to VirusTotal at 02:29 UTC. By 07:34 UTC, WordPress security company Patchstack reported that hosting partners were seeing active exploitation. Cloudflare’s CTO said the company was “seeing early attacks emerging” and deployed WAF rules, including on its free plan.
• October 21, 14:00 UTC: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released. The UK’s National Cyber Security Centre published an alert, CISA urged immediate patching, and the Dutch NCSC opened a public php2shell repository to track affected products. Several Dutch websites, including the tech news site Tweakers and the Dutch NCSC’s own, went offline as a precaution.
• October 21, later: WordPress.org published its security notice, written by core committer John Blackbourn.
• October 23: The PHP project issued a follow-up informational advisory about a related, much less likely session upload progress vector, CVE-2026-115560, to be fully fixed in the next bugfix release. Sites that already disabled session.upload_progress need do nothing more.

Is PHP2Shell being exploited?

Yes, although the picture is more nuanced than the early headlines suggested. Amazon says PHP2Shell is now “broadly exploited in the wild” and recommends that incident responders look back to October 17. Security firm watchTowr reproduced both bugs and is seeing attempts against both. Wiz demonstrated unauthenticated remote code execution against WordPress and Drupal installations.

At the same time, the exploits are not point-and-click. The PHP Foundation said that none of the proof-of-concept code it reviewed after the leak was functional, and Sansec reports that most public exploits don’t work against a default PHP installation or need a separate file inclusion bug to chain with. Reliability depends on the server’s PHP build, extensions and memory layout, and mod_php on Apache is the easiest target. Mass exploitation on the scale of Log4Shell looks less likely than first feared, but targeted attacks are real, and the risk grows every day a server stays unpatched.

The scale of exposure is the worrying part. Scans by Modat found about 4.4 million PHP services on 1.9 million hosts in the ten days before disclosure, and roughly 79% of those with a readable version were running an unsupported PHP branch. PHP 7.4 alone accounted for nearly 880,000 services. Those servers have no official fix.

Does PHP2Shell affect WordPress?

Yes, every WordPress site is affected, because WordPress is a PHP application. But the fix is not in WordPress. As the WordPress.org notice puts it, “No WordPress update is required or planned for these issues.” Updating WordPress 7.1.3, your theme or your plugins does nothing for PHP2Shell. Only updating PHP on the server does.

That also means the usual WordPress defences don’t help. A security plugin runs inside WordPress, and WordPress runs inside PHP, so the attack has already happened by the time a plugin’s firewall sees the request. Sansec makes the same point about its own product. Only a server-level or network-level firewall, such as Cloudflare in front of your site, can filter the malicious requests, and even that is described by Cloudflare as a stopgap.

WordPress 7.1 officially supports PHP 7.4 through 8.5, which means a large share of WordPress sites run on branches that the PHP project no longer patches. If that’s you, this is the moment to move. Site owners on PHP 8.1 or earlier who manage their own servers are being advised by CISA and the NCSC to consider taking the server offline until it is upgraded.

What WordPress site owners should do now

1. Check which PHP version you’re running

In your WordPress dashboard, go to Tools → Site Health → Info → Server and look at the PHP version. If it shows 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, you’re patched. If it shows an older number, keep reading. Be aware that hosting panels and Linux distributions often backport fixes without changing the version number, so a lower number isn’t always bad news; your host can confirm.

2. On managed or shared hosting, confirm with your host

Most managed WordPress hosts and large shared hosts began patching on October 21 and many have published status pages. Check your host’s blog or status page, and if you can’t find a clear statement that PHP2Shell is patched, open a support ticket and ask. If your host offers a PHP version selector in its control panel, switch to the newest 8.x branch it provides.

3. On cPanel, Plesk or your own server, update now

cPanel users should run /scripts/update-packages after refreshing the package cache; patched ea-php packages are available for 7.4 through 8.5. Plesk users should update Plesk itself (which also fixes the Plesk engine’s own bundled PHP) and then update each PHP version from Tools & Settings. On a plain Linux server, run your package manager’s security update, then confirm the changelog mentions CVE-2026-109618:

# Debian / Ubuntu (replace 8.3 with your branch)
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961(8|9)'

# RHEL / AlmaLinux / Rocky
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961(8|9)'

Then restart PHP-FPM or Apache. A patched package on disk does nothing while the old worker processes are still running. If you run more than one PHP version, or PHP inside Docker containers, update and restart each one; rebuilt official Docker images are available for the supported branches, but running containers don’t update themselves.

4. If you’re on PHP 8.1 or older

There is no release from php.net for you. Your options are a backported package from your distribution, hosting panel or an extended support vendor, or, better, an upgrade to PHP 8.3 or 8.4. WordPress and almost all maintained themes and plugins run happily on 8.3 and 8.4, and the speed improvement alone is worth it. Test on a staging site first; our guide to updating PHP in WordPress explains how.

5. If you can’t patch today, apply the temporary mitigations

The PHP security team is clear that there is no complete configuration-only fix, but these settings reduce exposure. They must go in php.ini, the PHP-FPM pool or the server configuration, not in ini_set() or .htaccess, and all PHP workers must be restarted afterwards:

; Closes the confirmed CVE-2026-109619 session path
session.upload_progress.enabled = 0

; PHP 8.5 only: closes the backtrace path
fatal_error_backtraces = 0

; Reduces the CVE-2026-109618 OOM path (watch memory use, restore after patching)
memory_limit = -1
post_max_size = 8M

Keep session.upload_progress.enabled off even after patching unless you know you need it; WordPress doesn’t. If your site has no file uploads from the public, you can also block multipart/form-data requests at the web server or CDN, but remember that this breaks media uploads in the WordPress admin and some contact forms, so test afterwards. If you use Cloudflare, make sure attackers can’t bypass it by reaching your origin server’s IP address directly.

6. Check for signs of compromise

Because attacks were under way before the fix, patching alone doesn’t prove you’re clean. Review your web server and PHP error logs from October 17 onwards for unusual multipart requests, PHP workers spawning shells, or spikes in out-of-memory errors. Look for new or modified PHP files in wp-content/uploads, unknown administrator accounts and unexpected scheduled tasks. If you find anything, follow our hacked WordPress site recovery guide and rotate every password and API key stored on the server, since the first flaw can leak memory contents as well as run code.

What PHP2Shell means for the WordPress ecosystem

PHP2Shell is the most serious PHP vulnerability in years, and it lands on an ecosystem that has been slow to let go of old PHP. WordPress still supports PHP 7.4, a branch that stopped receiving security fixes in 2022, and the exposure scans above suggest hundreds of thousands of servers are still on it. The WordPress.org notice points readers to the project’s PHP compatibility page, and it would not be surprising to see renewed pressure to raise the minimum supported version.

It also shows the limits of application-level security. No amount of plugin updates, strong passwords or WordPress hardening would have stopped this one. The lesson for site owners is to treat the PHP version as part of your security posture: keep it on a supported branch, know who is responsible for updating it, and make sure that person moves quickly when the PHP project says “critical”.

Finally, PHP2Shell is a reminder to keep backups you can restore from. Our tutorial on backing up WordPress to Dropbox is a good place to start, and uptime monitoring will tell you if a server that’s been taken offline for patching hasn’t come back.

WPInterface themes and PHP 8.5

WPInterface themes are built with lean, standards-compliant code and kept compatible with current PHP 8 releases, so moving to a patched, supported PHP branch won’t break your site’s design. If you’ve been holding back a PHP upgrade because of an old theme, this is a good week to switch. See our WordPress themes, or read about the October 2026 theme update.

Let us handle it for you

If you’d rather not work through server updates and log reviews yourself, the WPInterface team can help:

• VIP Support: a $29 priority ticket. We’ll check your PHP version, confirm your host has patched PHP2Shell and apply mitigations if needed.
• WordPress Malware Removal: if you suspect your site was hit before the patch, we clean it, close the holes and rotate credentials.
• WordPress Migration: stuck on a host that still runs PHP 7.4? We’ll move you to a modern, patched server.
• WordPress Care Plans: ongoing updates, backups and monitoring, so the next critical release is handled before you read about it.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the nickname for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, disclosed on October 21, 2026. Both can allow an unauthenticated attacker to run code on a server running PHP.

Do I need to update WordPress?

No. The flaws are in PHP, not WordPress. WordPress.org has confirmed that no WordPress update is required or planned. You need to update PHP on the server, or make sure your host has.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older branches have no official release, but cPanel, CloudLinux, Plesk, Debian, Ubuntu and others have published backported packages for some of them.

Will a WordPress security plugin protect me?

No. Plugins run inside PHP, and the attack happens before PHP hands the request to WordPress. Only a patched PHP, or a firewall in front of the server such as Cloudflare, can block it.

How do I know if my host has patched?

Check Tools → Site Health → Info → Server for the PHP version, then check your host’s status page or ask support. Hosts often backport fixes without changing the version number, so a direct answer from your host is the most reliable confirmation.

Is PHP2Shell being exploited?

Yes. Amazon, Cloudflare, Patchstack and watchTowr have all reported exploitation attempts, some starting before the public disclosure. Working exploits need specific server conditions, so not every attempt succeeds, but unpatched servers are at real risk.

Final thoughts

PHP2Shell is rare: a critical, unauthenticated remote code execution flaw in the language itself, affecting fourteen years of releases, with exploitation under way before the fix shipped. The good news is that the fix is simple. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart your PHP workers, and you’re done.

If you’re on an older branch, treat this as the push you needed to move to a supported one. And if you’re on managed hosting, don’t assume: check your Site Health screen, read your host’s announcement, and ask if anything is unclear. We’ll update this article as the PHP project and hosting providers publish more information.