Only check systems you own or are responsible for. This page and our checker work from version numbers you type in. Nothing here tests, probes or scans a site.
Short answer
The php2shell flaws (CVE-2026-109618 and CVE-2026-109619) are in PHP, the server software underneath WordPress, not in WordPress, your theme or your plugins. Wordfence’s notice says WordPress automatic updates will not fix them and that PHP has to be updated by your host or on your own server (Wordfence). Open Tools > Site Health > Info > Server and read the PHP version. If it is below 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or you are on 8.1 or older), get your host to update PHP.
Why it matters: the PHP Group says the flaws can allow unauthenticated remote code execution, meaning someone with no login may be able to run code on your server (php.net advisory). Background: php2shell: what it is and how to fix it.
Step 1: Check your PHP version in Site Health
- Log in to WordPress admin.
- Go to Tools > Site Health, open the Info tab and expand Server.
- Read PHP version (WordPress.org: update PHP).
| What you see | What it means |
|---|---|
| 8.5.12 or higher, 8.4.27 or higher, 8.3.36 or higher, 8.2.35 or higher | At or above the PHP Group’s fixed release for that branch. |
| Same branch but lower (for example 8.3.30) | Below the upstream fix. NVD lists 8.2.* below 8.2.35, 8.3.* below 8.3.36, 8.4.* below 8.4.27 and 8.5.* below 8.5.12 (GHSA-w8hw-w9fx-j79w). Update PHP, unless your host tells you it patches in place and keeps your version number: some hosts do, so ask and see hosting status. |
| 8.1, 8.0, 7.4 or older | The PHP Group made no fixed release for these, only minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves. Move to a supported branch, or ask your host whether it ships a back-ported fix (old branches). |
| A number that looks old, but PHP comes from a Linux distribution or vendor | Fixes are often back-ported, so the number may not change after patching. Compare with your vendor’s fixed package version, not the upstream number (fixed versions). On shared hosting, ask your host. |
Two traps:
- “8.3 or higher” is no longer enough. WordPress.org’s general advice says that if you are on PHP 8.3 or higher you don’t need to update PHP, and it recommends 8.3 or greater (requirements). That is advice about supported branches. For this issue, 8.3 below 8.3.36 is still affected.
- The CLI can differ from the website.
php -vin a terminal can show a different PHP from the one serving your site. Site Health runs inside the web request, so trust it for the website.
Type your number into the checker to compare it with the fixed versions.
Step 2: Find out who updates PHP for you
PHP is installed on your server, so you change it in your host’s settings or ask the host to do it (WordPress.org). On most managed and shared hosting the host updates PHP; on a VPS, a dedicated server or any server you run yourself, you or your developer do (Wordfence).
Managed WordPress hosts
What each host’s own page said when we checked on 22 Oct 2026. Hosts update these pages, so open the link before you decide. “Protected” is the host’s word and does not say which PHP version you run, so confirm with Site Health.
| Host | What it says | Source |
|---|---|---|
| WordPress.com (Automattic) | “If your site is hosted on WordPress.com, WordPress VIP, WP Cloud, Pressable, or Tumblr, your site is already protected.” No PHP version given. Applies to sites hosted by Automattic, not self-hosted WordPress. | Automattic |
| Pressable | “Pressable sites are already protected against both vulnerabilities.” Customers need no action. | Pressable status |
| Pantheon | Patched PHP is deployed on all live environments (PHP 8.2 or later and all LTS versions) and on all pre-production customer environments. “Free/sandbox environments will be updated over the next 24-48 hours.” Network-level mitigations stay in place; no customer action required. | Pantheon status |
| WP Engine | “WP Engine has finished the deployment of security patches for two critical PHP vulnerabilities on our platform. The patches have been applied to your PHP version, and no action is needed from you.” It names 7.4.33.17, 8.2.35, 8.4.27 and 8.5.12 (7.4.33.17 is WP Engine’s own build of PHP 7.4). | WP Engine status |
| Flywheel | “WP Engine has finished the deployment of security patches for two critical PHP vulnerabilities on the Flywheel platform. The patch has been applied to your PHP version, and no action is needed from you.” | Flywheel status |
| Kinsta | “All sites are protected, the PHP security updates have been rolled out across the platform” (incident resolved 08:26 UTC on 22 Oct). Its earlier updates listed patches for PHP 7.4, 8.0, 8.1, 8.2, 8.3, 8.4 and 8.5 rolling out, and said Cloudflare firewall mitigations would stay in place until further notice; the final update does not mention them. | Kinsta status |
| Cloudways | “The PHP security patch rollout is complete, and all active servers have been successfully updated.” (10:11 UTC on 22 Oct). Patches for all applications on Autonomous were applied by 01:02 UTC. Interim configuration-level mitigations were deployed earlier, and the support team is contacting a small subset of customers whose environments need additional assistance. | Cloudways status |
| Nexcess | “The rollout is progressing, and teams are checking that the appropriate update is applied for each environment.” (22 Oct, 14:42 UTC). Its 19:28 UTC update says it is still assessing the remaining environments. Its 21 Oct update had said no patches had been rolled out to production yet. | Nexcess status |
Shared hosting
| Host | What it says | Source |
|---|---|---|
| SiteGround | Server-level mitigation on all servers; “there’s nothing you need to do.” Posted before the PHP release; it does not name patched PHP builds. | SiteGround |
| Bluehost, HostGator | “Our teams continue to work on deploying patched PHP builds across our remaining hosting infrastructure. The majority of these platforms are now up-to-date” (update stamped Oct 22nd 18:15 est). Customers who manage their own VPS or dedicated servers should watch for emails about their services. Earlier updates said mitigations stay in place as an extra layer and may limit upload file size. | Bluehost, HostGator |
| GoDaddy | Managed Hosting for WordPress: “We have patched all PHP versions on Managed Hosting for WordPress. You don’t need to take any action.” Windows Hosting: also patched (update of 01:20 UTC on 22 Oct), no action needed. Web Hosting: “We have patched all PHP versions on Web Hosting. You don’t need to take any action.” (update of 13:30 UTC on 22 Oct). VPS owners update PHP themselves. | GoDaddy |
| Hostinger | Says its own tests found its platform is not vulnerable and that it added an extra layer of protection. At 06:44 UTC on 22 Oct it said “PHP upgrades are now complete across all managed hosting servers.” Some sites show PHP 8.5.11 instead of 8.5.12; Hostinger says this is expected, and that a Build Date of 21 Oct 2026 or later in PHP Info means the fix is applied. No action is needed on Web Hosting, Agency Hosting or cPanel Hosting plans; VPS clients manage PHP themselves. | Hostinger status |
More hosts, with the date we checked each: hosting status. A host’s “rolling out” or “mitigation” is not proof that your site is on a fixed PHP. If Site Health still shows an affected number, ask the host in writing when your plan gets the fixed version.
Control panels
- cPanel: the EasyApache 4 25.91 release (21 Oct) says it “fixes two critical PHP vulnerabilities” in ea-php74 through ea-php85 (cPanel release notes). Steps: cPanel guide.
- Plesk: fixed PHP builds are available for PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on Plesk for Linux and Plesk for Windows. On Linux, the end-of-life 7.4.33, 8.0.30 and 8.1.34 keep their version numbers; Plesk says builds made on 21 Oct 2026 include the fixes. Install the Plesk update (Plesk KB). Steps: Plesk guide.
- Your own VPS: Ubuntu and Debian, or the general 3-step walkthrough.
Step 3: Before you jump to a new PHP branch
Updating inside your branch (say 8.3.30 to 8.3.36) is a patch update and rarely breaks anything. Moving to a different branch (say 8.1 to 8.3) can break old plugins and themes. Take a full backup first. This is the WordPress.org checklist (source):
- Back up the site and database. A restore also needs your host to put the old PHP version back.
- Update WordPress, themes and plugins under Dashboard > Updates, then check the site still works.
- Run the PHP Compatibility Checker plugin. WordPress.org says it “isn’t perfect” and may miss items or flag false positives. Ask the plugin or theme author about anything it flags, or replace the plugin.
- Switch PHP in your host panel (or ask your host), then load the home page, log in, and test forms and checkout.
- If it breaks, ask the host to restore the previous PHP version, then restore your backup. Don’t stay on an affected version: fix the plugin, then try again.
Check that your WordPress version supports the branch you pick in the WordPress compatibility table.
PHP 8.2 gets security fixes only until 31 Dec 2026, 8.3 until 31 Dec 2027 and 8.4 until 31 Dec 2028 (supported versions), so 8.2 is a short stop. If you must stay on a branch that has no fixed release, a plugin cannot fix it; ask your host for a vendor back-port or extended-support build.
Do not rely on plugins or a firewall as the fix
- Security plugins and web application firewalls (filters in front of your site) can add a layer, but the PHP Group says: “There are no complete mitigations, updating is the only safe choice” (php.net).
- Wordfence’s release notice (21 Oct) tells you to update PHP and lists no firewall rule. Its follow-up post (22 Oct) says its firewall protects the WordPress application layer only, and that “updating and restarting PHP is essential” (Wordfence).
- Patchstack says: “Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor’s patched package”, and warns against unofficial “fix” plugins and copy-pasted snippets (Patchstack).
- Sucuri: “WAF protection does not replace patching PHP on your origin server” (Sucuri status). Cloudflare says the same (guide).
Step 4: Verify
-
Reload Tools > Site Health > Info > Server and read the PHP version again.
-
If you run the server yourself, restart PHP (this briefly interrupts requests) and check the package version. Adjust the service name to your setup; RHEL-family uses
php-fpmandhttpd.php -vshows the command-line PHP, so trust Site Health for the website:sudo systemctl restart php8.3-fpm sudo systemctl restart apache2 # only if you use mod_php php -vDistro numbers are compared against the vendor’s fixed package, not the upstream number: see Ubuntu and Debian.
-
Enter the version in the checker, and open a few pages of your site to confirm it still works.
Want help with your exact setup?
If you would rather not work out the steps for your host and WordPress version yourself, we offer a $49 personal patch plan: written steps for your exact setup by email within 24h. Details at /fix-service/. We never log in to your server.
Independent site, not affiliated with WordPress.org, Automattic, the PHP Group or php.net.