PHP2Shell: What the Critical PHP Vulnerabilities Mean for WordPress Sites
On October 20, 2026, details of two critical PHP vulnerabilities leaked before the fix was ready. This article explains what happened, which sites are affected, and the practical steps WordPress agencies can take before and after the fix.
We’ll update this article as new official information comes out.
On October 20, 2026, details of two critical vulnerabilities in PHP leaked before a fix was ready. PHP is the language WordPress runs on, so almost every WordPress site could be affected. Here’s what happened, what it means for your client sites, and what to do now.
TL;DR
- Two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619 (nicknamed “PHP2Shell”), can let attackers run their own code on a server.
- PHP rates both 9.2 out of 10 on the CVSS v4.0 scale. The fix is out: update to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12.
- The problem is in PHP, not in WordPress or a plugin. Security plugins can’t block it.
- What to do: check each site’s PHP version, take a backup, coordinate with your host to update PHP and restart it, then check your sites for signs of an attack.
The PHP2Shell security threat explained
Security researchers found two critical vulnerabilities in PHP: CVE-2026-109618 and CVE-2026-109619, nicknamed “PHP2Shell”. Both allow remote code execution. This means an attacker could run their own commands on a server from anywhere on the internet, without logging in, and take over every site on that server.
The researchers reported the problem privately, so PHP could prepare a fix. The details were meant to stay secret until October 22, after the fix was out. That would have given everyone time to update before attackers knew what to look for.
That’s not what happened. On October 20, details of both vulnerabilities leaked publicly before the fix was ready.
On October 21, PHP released the fix and published two official advisories (CVE-2026-109618 and CVE-2026-109619). The first can be triggered by specially crafted file-upload requests that make PHP run out of memory. The second uses leftover data that PHP keeps between requests. Both can let an attacker take over the server.
What it means for WordPress
Most WordPress security news is about a plugin or theme. This one is different, because the problem is in PHP itself. Every time someone visits a WordPress site, PHP runs first and then loads WordPress and its plugins.
That has two big consequences. Updating WordPress, plugins or themes won’t stop a potential security attack, only a new PHP version does. Also, security plugins and firewalls that run inside WordPress can’t block it. They only start working after PHP has already handled the request.
Which sites are affected
According to CERT-EU, the vulnerabilities could affect all PHP versions from PHP 5 onwards.
| PHP version | Fix expected? | Fixed version |
| 8.5 | Yes | 8.5.12 |
| 8.4 | Yes | 8.4.27 |
| 8.3 | Yes | 8.3.36 |
| 8.2 | Yes | 8.2.35 |
| 8.1 and older | No, these versions are end of life | None. Upgrade to PHP 8.2 or later. |
What WordPress agencies can do for their portfolios
The official advice from the PHP team is to update as soon as the release is available. CERT-EU also advises: If you can’t update quickly, consider taking public-facing sites off the internet until you can.
Here are some practical steps for WordPress agencies:
1. Check the PHP version of every site.
Make a list of your client sites and the PHP version each one uses. Sites on PHP 8.1 or older need a plan to upgrade. WordPress.org lists the PHP versions it recommends.
With WP Umbrella: you can see the PHP version of every connected site, and the site health checks flag versions that no longer get security fixes. This turns step 1 into a quick check instead of a site-by-site job. With WP Umbrella’s MCP connector, you can also ask your AI assistant: “Which of my sites run PHP 8.1 or older?”
2. Make sure you have a clean backup ready to be restored.
Make sure every site has a recent clean and complete backup stored away from the server, before and after the PHP update. If something goes wrong, you can go back to a clean copy.
With WP Umbrella you can backs up your sites automatically, on a schedule that works best for you. You can also take a backup manually, right before your site’s PHP version is updated. Backups are stored offsite, on WP Umbrella’s own servers. This way you still have a clean copy even if your host’s server is unresponsive. If something goes wrong, you can restore a clean version of your site from your WP Umbrella dashboard with one click.
3. Work with your hosts.
On most hosting plans, only the host can update PHP. Check whether your hosts have already contacted you about PHP2Shell.
If they haven’t, you can ask them “When will you install the fixed PHP version?”, “Will you restart PHP afterwards, so the new version is actually used?”, “For sites on PHP 8.1 or older, will you add the fix to those versions, or do I need to upgrade?”.
6. Check your sites for signs of an attack.
Check each site for suspicious activity:
- New admin users you didn’t create
- PHP files you don’t recognize, especially in the uploads folder
- Other unusual activity, such as changed core files
With WP Umbrella: on sites with the Security Add-on, the Security Activity Log tracks every activity that happens on the site, such as the creation of new admin accounts or changes to core files. On top of that, the malware scanner runs daily and alerts you right away if anything needs your attention.
Final thoughts
PHP2Shell is a reminder that WordPress security doesn’t stop at WordPress. This time, the risk sat in PHP, the language underneath it, and the fix came from a PHP update instead of a security plugin.
Most of your clients will never hear the name PHP2Shell, and that’s how it should be. What they’ll notice is that their sites kept running while you checked PHP versions, coordinated with hosts and confirmed every site was updated. That quiet work is a big part of what a care plan is for.
If you want to dig into the technical details, PHP’s official advisories for CVE-2026-109618 and CVE-2026-109619 explain exactly what was fixed.