If you run a WordPress site, clicking “update” in your dashboard will not protect you from PHP2Shell, the pair of critical PHP flaws patched on October 21, 2026. The bugs sit in PHP itself, the language runtime underneath WordPress, so the fix has to happen on the server. This PHP2Shell WordPress guide explains which PHP builds contain the fix, which hosts said they had already patched, and how your server setup changes the risk.
Where it stands: As of Oct. 21, Automattic said its WordPress.com, VIP, WP Cloud, Pressable and Tumblr platforms were protected, and GoDaddy said Managed WordPress was patched. GoDaddy’s ordinary shared and Windows hosting was still waiting on a vendor for patched PHP packages at its last update.
Why doesn’t a WordPress update fix PHP2Shell?
Because WordPress is an application written in PHP, and PHP2Shell is a flaw in the PHP engine that runs it. Automattic puts it bluntly: “This is a runtime fix, so updating WordPress, your theme, or your plugins will not protect you on its own.” Cloudflare makes the same point, saying that changing website code or a plugin “alone does not fix these vulnerabilities.”
That matters because a clean, fully updated WordPress install is still exposed if the host’s PHP build is old. Vercel’s bulletin names WordPress alongside Drupal, Laravel and Magento as affected whenever they sit on a vulnerable runtime. Our PHP2Shell overview covers the two CVEs themselves.
Which PHP versions contain the fix?
The PHP project released one fixed build per supported branch: 8.5.12 for 8.5, then 8.4.27, 8.3.36, and finally 8.2.35 for the 8.2 branch. Anything on those branches below those numbers is affected. The project’s advisory says the bugs “can allow unauthenticated remote code execution”, which means an outsider without a login could run commands on the server.
Two caveats trip people up:
- Distribution version strings look different. Linux vendors backport the fix into their own packages. Ubuntu’s USN-8948-1, for example, lists the Apache module for 24.04 LTS as libapache2-mod-php8.3 version 8.3.6-0ubuntu0.24.04.13. That build is patched even though “8.3.6” looks older than 8.3.36.
- There is no setting that fully replaces the update. PHP says “There are no complete mitigations, updating is the only safe choice.” Temporary hardening steps exist in the official advisories, but they reduce exposure rather than remove it.
Which hosts have patched, and which are waiting?
Hosts were at different stages by the end of release day. The table summarises what each company said publicly on Oct. 21; check your own host’s status page for anything newer.
| Host or platform | What it said on Oct. 21 |
|---|---|
| WordPress.com, VIP, WP Cloud, Pressable, Tumblr | Already protected (Automattic) |
| GoDaddy Managed WordPress | All PHP versions patched, no action needed |
| GoDaddy Web Hosting and Windows Hosting | Waiting for a vendor’s patched PHP packages |
| cPanel/WHM servers (per GoDaddy) | Patched builds in EasyApache 4, plus backports for 7.4, 8.0, 8.1 |
| Laravel Forge servers | Forge’s automatic updates do not patch PHP |
| Ubuntu 22.04, 24.04, 26.04, 26.10 | Fixed packages in USN-8948-1 |
| Remi RPM repository | No release-day updates (CERT-EU) |
The Forge line deserves attention. Laravel’s documentation says “Laravel Forge’s automatic security updates do not patch PHP”, so Forge users have to update PHP themselves. The same logic applies to any VPS: if you manage the server, you own the PHP update.
Firewall vendors offered a stopgap rather than a fix. Cloudflare said its managed rules were switched on automatically for every plan with its WAF (web application firewall) enabled, including free accounts, and Google Cloud said Cloud Armor managed rules were available. Neither changes the PHP code on your server.
Does your server setup change the PHP2Shell WordPress risk?
Yes. The way PHP is wired into the web server affects how easy the bugs are to reach, though no common setup is listed as safe. PHP’s advisory treats every installation answering web traffic as exposed, and its list names LiteSpeed, FrankenPHP, php-cgi and PHP-FPM as well as Apache’s mod_php.
- mod_php (PHP loaded inside Apache): PHP considers this the highest-risk configuration, because a demonstrated attack can fire before any WordPress code runs.
- PHP-FPM (a separate pool of PHP worker processes): the official picture is mixed. The GitHub advisory for CVE-2026-109618 says FPM is susceptible by source analysis but “no complete FPM exploit has been demonstrated for this SAPI.” The PHP Foundation, covering both bugs, says code execution “was also confirmed on PHP-FPM through application-level code paths.”
- Red Hat’s view: Red Hat rates CVE-2026-109618 “Important” rather than critical, noting that standard RHEL deployments use PHP-FPM and that reliable exploitation “requires precise heap manipulation and timing.”
The practical reading: FPM sites face a narrower path, not a closed one. Patch either way.
What to do if your site runs on an older PHP
The PHP project says “PHP 8.1 and older no longer receive updates from the PHP project.” It did publish minimal source backports for 7.4, 8.0 and 8.1, aimed at people who compile PHP themselves or lack a long-term-support vendor, and GoDaddy reports that cPanel backported the fix to its 7.4, 8.0 and 8.1 packages.
Those are lifelines, not long-term homes. Automattic also flags that PHP 8.2 reaches end of life on December 31, 2026, and recommends 8.3 or newer. Our guide to unsupported PHP versions covers that long tail.
A short checklist for WordPress owners
- Find your PHP version. Your hosting control panel shows it, and so does the Site Health screen inside WordPress admin.
- Compare against the fixed builds for your branch, or your distribution’s security notice if the host uses vendor packages.
- Ask your host in writing whether the PHP runtime on your plan has the October 21 fix, not whether WordPress is current.
- If you manage the server yourself (VPS, Forge, cPanel), update PHP and restart its workers so the new build actually loads.
- Treat a firewall rule as a stopgap until the runtime is patched.
Whether attackers are already using the bugs is a separate question, covered in is PHP2Shell being exploited. On the GitHub advisory’s own terms, a successful attack means running code with the permissions of the web worker account.
Frequently Asked Questions
Does updating WordPress fix PHP2Shell?
No. PHP2Shell is a flaw in the PHP runtime that runs WordPress, not in WordPress itself. Automattic and Cloudflare both say that updating WordPress, themes or plugins does not fix it; the server has to run a patched PHP build.
Which PHP versions fix PHP2Shell?
Upstream, the fix is in 8.2.35 for the 8.2 branch, 8.3.36 for 8.3, 8.4.27 for 8.4 and 8.5.12 for 8.5. Linux distributions such as Ubuntu ship the fix under their own package version numbers, so check your vendor’s notice rather than comparing numbers.
Is my WordPress.com or managed WordPress site safe from PHP2Shell?
Automattic says sites on WordPress.com, WordPress VIP, WP Cloud, Pressable and Tumblr are already protected. GoDaddy says it patched PHP on its Managed Hosting for WordPress. For other hosts, ask whether the PHP runtime itself was updated.
Is PHP-FPM safer than mod_php against PHP2Shell?
Lower risk, not zero. PHP rates mod_php as the highest-risk setup. Its GitHub advisory says no complete FPM exploit had been demonstrated for one of the bugs, but the PHP Foundation says code execution was also confirmed on PHP-FPM through some application paths.
What if my site runs PHP 8.1 or older?
The PHP project no longer issues updates for 8.1 and older. It published minimal source backports for 7.4, 8.0 and 8.1, and some vendors such as cPanel have backported fixes, but moving to a supported branch is the durable answer.
Sources
- Security advisory: Critical remote code execution vulnerabilities, update now — PHP.net (PHP security team), October 21, 2026
- Your Sites Are Protected Against the PHP2Shell Vulnerabilities — Automattic, October 21, 2026
- Important PHP security update: What website owners need to do — GoDaddy, October 21, 2026 (updated 19:30 UTC)
- PHP security advisory (CVE-2026-109618, CVE-2026-109619) — Laravel Forge documentation, October 21, 2026
- Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 — Google Cloud Blog, October 21, 2026
- USN-8948-1: PHP vulnerabilities — Ubuntu Security Notices (Canonical), October 21, 2026
- CVE-2026-109618 — Red Hat Customer Portal, October 21, 2026
- RCE via OOM corruption (GHSA-w8hw-w9fx-j79w) — php/php-src GitHub Security Advisory, October 21, 2026
- Today’s PHP Security Release, and How We’re Strengthening PHP Security — The PHP Foundation, October 21, 2026
- Cloudflare deploys protections against php2shell vulnerability — Cloudflare Blog, October 21, 2026
- PHP security advisory: php2shell (CVE-2026-109618, CVE-2026-109619) — Vercel Knowledge Base, October 21, 2026
- Critical Vulnerabilities in PHP (Security Advisory 2026-018) — CERT-EU, October 21, 2026
This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.