PHP2Shell and WordPress: Is Your Site Affected and What to Do

As of 23 October 2026, the PHP project has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and WordPress.org has said that no WordPress update is required or planned for them. Exploitation attempts are widely reported, but confirmed successful compromises are not publicly documented, and CISA has not added the flaws to its Known Exploited Vulnerabilities (KEV) catalog.

The short answer: yes, a self-hosted WordPress site can be affected, but not because of anything in WordPress. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a pair of flaws in PHP itself, the programming language and server software that runs WordPress. If your WordPress site runs on an unpatched PHP build, it is exposed. If PHP has been patched, it is not exposed to these two CVEs, whatever WordPress version you run.

That changes who has to act. The fix happens on the server, which means your web host, your IT team or whoever runs your server. This guide explains what was shown against WordPress, who patches on each kind of hosting, why plugins can't fix it, and a checklist you can work through today. For the overall story, start with what PHP2Shell is and who it affects.

Is PHP2Shell a WordPress Vulnerability?

No. The bugs are in how PHP handles memory errors and internal state between requests. PHP's own description of CVE-2026-109618 is that "out-of-memory handling can interrupt PHP while internal request data is only partially initialized." CVE-2026-109619 is described as "request-owned internal state can survive after its backing memory has been freed." Neither has anything to do with WordPress code, themes or plugins.

WordPress.org said the same thing in its Critical PHP Security Release post on 21 October 2026: "These vulnerabilities are not specific to WordPress and affect any server that hosts a PHP application. No WordPress update is required or planned for these issues."

"WordPress sites are at risk" really means "WordPress sites on unpatched PHP are at risk."

What Researchers Showed Against WordPress

WordPress was a test target, not the cause.

• Wiz reported that it could "execute code remotely without authentication on deployments of WordPress (wordpress:latest), Drupal (drupal:latest), and Joomla (joomla:latest), using their latest container images at the time of testing." Wiz's write-up says its WordPress chain used an OPcache bug (OPcache is PHP's built-in code cache), and that an upload-progress chain worked against all three CMSs. Wiz also stated: "They are representative targets - exploitation does not require one of these CMSs."
• Calif, which reported the first bug to PHP, lists WordPress 7.1.2 among the applications it confirmed, alongside Drupal, Joomla, Magento, phpMyAdmin, Nextcloud, Laravel and others.

"Without authentication" means the attacker does not need a WordPress login. "Remote code execution" means running their own commands on the server, with the permissions of the web server's account. Wiz also warns that leaked memory "may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself."

Beazley notes that no single exploit works across all PHP versions and setups. That is not a reason to wait. Our PHP2Shell exploitation status tracker keeps the dated record of what has been reported.

WordPress PHP Requirements and Why Old PHP Is Worst Off

WordPress runs on a wide range of PHP versions, which is why so many sites sit on old ones. According to the WordPress requirements page, "it's recommended your host supports: PHP version 8.3 or greater." It adds that WordPress "also works with PHP 7.4+," but "these versions have reached their official End Of Life."

Here is what each PHP branch means for PHP2Shell, as of 23 October 2026.

The old branches are the problem. PHP says "PHP 8.1 and older no longer receive updates from the PHP project," although some distributions and long-term support vendors provide backported fixes. WordPress.org's advice for self-managed servers on PHP older than 8.2 is direct: "you should consider taking your server offline while you prepare to update to a newer version of PHP." CISA gave the same advice for PHP 8.1 and earlier.

Note that "8.3" alone isn't enough information. PHP 8.3.35 is vulnerable and 8.3.36 is fixed. The full table, including distribution packages, is in PHP2Shell fixed versions. If you need to move to a newer PHP branch, our guide to WordPress PHP versions and safe upgrades covers testing plugins and themes first.

Check Your PHP Version in Site Health (and Its Limits)

WordPress shows the PHP version it is running on.

1. Log in to your WordPress dashboard as an administrator.
2. Go to Tools > Site Health, then open the Info tab.
3. Expand the Server section and read the PHP version line.
4. On the Status tab, you may also see "Your site is running an outdated version of PHP, which requires an update."

Treat the number with care. Linux distributions such as Ubuntu and AlmaLinux backport security fixes without changing the upstream version number. AlmaLinux puts it plainly: "Don't rely on php -v: our fixes are backported, so the upstream PHP version number doesn't change." A patched Ubuntu 24.04 server can still report PHP 8.3.6. So Site Health can't prove you are patched, and it can't prove you are vulnerable. If the number is below the upstream fixed release, ask your host whether the fix is in their build.

Our step-by-step guide to checking your PHP version covers the hosting panel, the command line and what to ask your host.

Who Patches: Managed, Shared or Your Own Server

Who has to act depends on who runs PHP for your site.

Automattic's PHP2Shell post says "all sites hosted with Automattic, including those on WordPress.com, WordPress VIP, WP Cloud, Pressable, and Tumblr, are safe. If you run your own servers, update now." For other managed hosts, don't assume; ask.

If you run the server, the update uses your normal package manager. These are generic examples for Debian or Ubuntu with PHP-FPM; replace 8.3 with your version:

sudo apt update
sudo apt upgrade
sudo systemctl restart php8.3-fpm

If you use Apache with mod_php, restart Apache instead (for example, sudo systemctl restart apache2). The restart is not optional. Old PHP workers keep running the old code until they are replaced.

Why Plugins and WordPress Updates Can't Fix It

Updating WordPress core, your theme and your plugins is good practice. It does not fix PHP2Shell. Cloudflare put it this way: "updating website code or a plugin(s) alone does not fix these vulnerabilities." Bitdefender added that "on mod_php, CMS updates, plugin hygiene and application hardening do not change exposure."

Security plugins are in the same position. Wordfence and similar plugins are PHP code. They run inside PHP, after PHP has started handling the request. They cannot replace or repair the PHP engine they run on. For CVE-2026-109618 on mod_php, PHP's advisory says the problem "happens entirely before any application-specific code begins execution," which means before WordPress or any plugin loads.

Scanners and file-change alerts still help you spot a compromise afterward. They are just not a patch. Our overview of WordPress security plugins explains what each type can and can't do.

A web application firewall (WAF) in front of your server is different, because it filters requests before they reach PHP. Cloudflare says its free and paid WAF customers have been protected by default since 21 October 2026, 03:02 UTC. That protection is partial. Cloudflare notes, for example, that its rule for the newer CVE-2026-115560 issue does not cover customers who changed session.upload_progress.name. WordPress.org also says your host "may already be working to update PHP and put web application firewall (WAF) rules in place," but you should still confirm PHP is updated. A WAF buys time. It is not the fix.

Interim Steps If PHP Can't Be Patched Today

If your host or team can't update PHP right away, PHP's advisory lists settings that reduce exposure. PHP stresses that "only an update is a complete solution" and that these measures "do not make an installation safe." The main ones are:

• session.upload_progress.enabled=0 in php.ini or the PHP-FPM pool, then restart every worker. Setting it with ini_set() or a .user.ini file does not work for this. Fastly notes this only affects applications that show real-time upload progress bars using PHP's built-in session mechanism, and that most upload progress bars use JavaScript instead.
• A lower post_max_size (PHP suggests 8M if you don't need file uploads, 32M if you do). This limits large media uploads, imports and backup restores, so test them.

Keep upload progress off even after patching if you don't need it. PHP's 23 October advisory on CVE-2026-115560 recommends session.upload_progress.enabled=0 until the next regular PHP release, because that separate, unlikely issue also affects patched builds. Every setting, its side effects and where to set it are in PHP2Shell interim mitigations.

The UpdraftCentral Backdoors Are a Separate Incident

In the same week, Patchstack reported that "an attacker holding valid UpdraftCentral dashboard keys is installing backdoor plugins on connected WordPress sites." UpdraftCentral is a remote management dashboard for WordPress. The installs ran between 18 October 15:32 and 19 October 09:23, and the backdoor plugins carried the description "Small maintenance toolkit: keeps option storage tidy."

This is not PHP2Shell. Patchstack says "This is not a vulnerability in UpdraftPlus... The fix is to delete your UpdraftCentral keys." It is a stolen-key problem, and the dates overlapping with PHP2Shell are a coincidence. If you use UpdraftCentral, follow Patchstack's UpdraftCentral guidance separately. Patching PHP does nothing for it, and deleting the keys does nothing for PHP2Shell.

WordPress PHP2Shell Checklist

For what to look for in logs and files, see was my site hacked through PHP2Shell.

Conclusion

As of 23 October 2026, PHP2Shell is a PHP problem that affects WordPress sites only through the PHP they run on. No WordPress, theme or plugin update fixes it, and WordPress.org has said none is planned. Confirm that PHP on your server is patched and restarted, move off PHP 8.1 or older, keep upload progress off if you don't need it, and handle the UpdraftCentral keys separately if they apply to you. If you run your own server and need help getting patched quickly, see our emergency PHP patching service. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions