PHP2Shell: The Critical PHP Flaw That Can Take Over Your Website — Check Your Version Today

On October 21, the PHP team released an emergency security update for two critical flaws — together nicknamed PHP2Shell — in PHP itself, the technology underneath WordPress and most of the web. The flaws let an attacker run code on an unpatched server without any login at all. The PHP team rates them 9.2 out of 10, critical.

This is not a WordPress bug, a plugin bug, or a theme bug. It sits underneath all of them — which means updating WordPress does not fix it. Only your server’s PHP version does.

What PHP2Shell actually is

PHP is the engine that runs about 69% of the world’s websites whose technology can be identified — including WordPress, which alone powers roughly 40% of all websites. The two flaws (CVE-2026-109618 and CVE-2026-109619) are memory errors inside that engine. With a specially crafted web request, an attacker can corrupt PHP’s memory and take over the process that runs your website — reading data, planting hidden files, and using your server as their own, all as your website’s account.

Because the attack happens inside PHP before your site’s own code even runs, no plugin, firewall setting, or WordPress update can patch it. The fix has to happen at the server level.

The fixed versions — and the hard truth for older sites

The emergency release of October 21 fixed the flaws in these versions:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

If your site runs one of those versions (or a hosting-provider build dated October 21 or later), you are patched.

Here is the part many site owners have not heard yet: there is no patch for PHP 8.1 or older. Those versions are past their supported life, and the PHP team is not releasing a fix for them. Roughly a third of PHP websites still run those older versions. If that is your site, patching is not an option — upgrading PHP is the only safe move, and it should happen now, not at the next redesign.

Attackers are not waiting

This is not a theoretical risk:

• Attack probes were recorded as early as October 17 — before the fix was even public.
• By October 24, security researchers had confirmed working break-ins against test servers.
• On October 26, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its Known Exploited Vulnerabilities catalog — the federal list of flaws confirmed to be used in real attacks — with a remediation deadline of October 29.

When a flaw is this public, automated scanners sweep the internet for unpatched sites. The question is not whether your site will be probed. It is whether the probe finds a patched server.

What to do today

1. Check your exact PHP version. In WordPress, go to Tools → Site Health → Info → Server. You need the full number — “PHP 8.3” is not enough; 8.3.36 is patched, 8.3.25 is not. On cPanel hosting, look under Software → MultiPHP Manager, and confirm the exact point release with your host.

2. Update — or upgrade. If you are on 8.2, 8.3, 8.4, or 8.5, apply the patched release for your branch. If you are on 8.1 or older, plan a version upgrade: update WordPress core, plugins, and themes first, take a full backup, and test on a staging copy before switching — a version jump can break older plugins.

3. Restart PHP after patching — the step almost everyone misses. A patched server keeps running the old, vulnerable code in its existing PHP processes until those workers are restarted. Ask your host, in writing, whether PHP was patched and the PHP workers restarted. Both halves matter.

4. Test your site like a customer. After any update, click through your contact forms, checkout, logins, and search. A small number of sites hit a crash bug in the newest patches (related to a component called SimpleXML) — that is a reason to test carefully, not a reason to delay patching.

5. Look back to October 17. Because probing started before the announcement, a patched server is not automatically a clean one. Check for PHP files you don’t recognize, new admin users, and unfamiliar scheduled tasks (cron jobs) — or have someone check for you.

How McBorrough can help

This week we launched a dedicated service for exactly this: our PHP Security Update & Emergency Fix — a version audit, a full backup before anything changes, the patch or version upgrade, the PHP worker restart most providers skip, compatibility testing, a compromise scan, and a written confirmation when your site is verified protected. It starts with a free PHP version check: tell us your site and we will tell you exactly where you stand.

If your current provider has not mentioned PHP2Shell to you at all, that silence is information. Check your site with us or read about the PHP Security Update & Emergency Fix service.

Questions we are hearing

Does updating WordPress fix PHP2Shell?
No. WordPress.org has confirmed no WordPress update is required or planned for this — the flaw is in PHP, below WordPress. Only updating the server’s PHP version fixes it.

How do I check my PHP version?
WordPress: Tools → Site Health → Info → Server. You need the full version number, not just “8.3.”

My host says I’m fine. How do I verify?
Ask for two things in writing: the exact PHP version your site runs, and confirmation that PHP workers were restarted after the October 21 patches. A patched version number plus a restart is a complete answer; anything vaguer is worth a second look.

I’m on PHP 8.1 or older. What now?
There is no patch coming for your version. Your safe path is an upgrade to a supported, patched branch (8.3 or 8.4), done with a backup and staging test so nothing breaks. This is the most urgent case — treat it as this week’s work, not next month’s.

Sources: PHP.net security advisory (October 21, 2026); The PHP Foundation, “Today’s PHP security release” (October 21, 2026); CISA alert and Known Exploited Vulnerabilities catalog (October 21–26, 2026); CERT-EU advisory 2026-018; W3Techs server-side language statistics (October 2026).