PHP2Shell checklist for WordPress: patch PHP first, then check nothing broke

By Branden Williams

PHP2Shell is a pair of critical flaws in PHP itself, the language WordPress runs on. The fix shipped on October 21, 2026, and getting it onto your site is the job that matters most this week. This checklist walks through it in order: find your PHP version, get it patched, then confirm your site still works, including the parts that earn you money.

The short version

  1. Find your PHP version: in WordPress, go to Tools → Site Health → Info → Server.
  2. Make sure it's a patched release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or newer. Your host does this part.
  3. Afterward, check your key pages, /ads.txt, your ads, your analytics and your forms.

What PHP2Shell is, briefly

PHP2Shell is the nickname for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Either one can let an attacker run code on a web server without logging in, and the PHP project rates both 9.2 out of 10 (CVSS v4.0). Any server that runs PHP to answer web requests is affected, which includes nearly every WordPress host.

Two facts shape what you should do:

  • A WordPress, plugin or security-plugin update can't fix it. The flaw is in PHP, so the fix is a new PHP version, installed by whoever runs your server.
  • There's no workaround that counts as a fix. The PHP project's advice is direct: "There are no complete mitigations, updating is the only safe choice."

Step 1: Find your PHP version

The quickest way is inside WordPress:

  1. Log in to your dashboard.
  2. Go to Tools → Site Health, then open the Info tab.
  3. Expand Server and look for PHP version. It shows the full number, such as 8.3.36.

You can also find it in your hosting control panel (often under "PHP Version," "Select PHP Version" or "MultiPHP Manager"), or ask your host's support team.

Write down the whole number, not only the first two parts. 8.3.30 and 8.3.36 are both "PHP 8.3," but only one of them is patched.

Step 2: Check whether your version is patched

Your PHP version starts with Patched from Notes
8.5 8.5.12
8.4 8.4.27
8.3 8.3.36
8.2 8.2.35 PHP 8.2 stops getting security fixes on December 31, 2026, so plan a move to 8.3 or newer.
8.1, 8.0, 7.x or older No official release The PHP project no longer updates these. Some hosts and Linux vendors patch them on their own, but the lasting fix is moving to a supported version.

One wrinkle: some hosts and Linux distributions, including Ubuntu and AlmaLinux, build the fix into their own PHP packages without changing the version number to match. If your number looks older than the table but your host says you're patched, ask them to confirm it covers both CVEs.

Step 3: Get patched

On most managed WordPress hosting, your host updates PHP for you. Many did it on October 21 or 22. Don't assume, though: confirm. A short message to support does it:

Is my site running a PHP version that's patched for PHP2Shell (CVE-2026-109618 and CVE-2026-109619)? Which version is it on, and when was it applied?

If your hosting panel lets you pick the PHP version yourself, how big a step you take decides how much there is to check afterward.

Staying on the same version line (for example, 8.3.30 to 8.3.36) is the gentlest change. These releases fix bugs and security problems without changing how PHP behaves, so it's the lowest-risk way to get patched.

Moving to a newer version line (for example, 8.1 to 8.3) is where older plugins and themes can stop working. The ones most at risk haven't been updated in a year or more. If you're on 8.1 or older, you'll need this bigger step, so prepare for it:

  1. Take a full backup of files and database, and make sure you know how to restore it. Many hosts have a one-click backup and restore.
  2. Update WordPress, your theme and your plugins first. Current versions are far more likely to support newer PHP.
  3. Use a staging copy if your host offers one. Switch PHP there first and click around before you touch the live site.
  4. Save a "before" record: copy the contents of yoursite.com/ads.txt into a text file and take screenshots of your home page and two or three important pages. Step 4 compares against these.

If something does break after a version change, fix it forward. Going back to an older, unpatched PHP version reopens the hole PHP2Shell left.

Step 4: Check that nothing broke

Run through this list after any PHP change, including one your host made for you. It takes about fifteen minutes. Use a private or incognito browser window, so you see what visitors see and your login doesn't hide anything.

Pages

  • Your home page and a handful of important pages load: your most-visited posts, your contact page, and your shop or checkout if you have one.
  • No page shows "There has been a critical error on this website," and none of them is blank white.
  • No lines like Warning:, Deprecated: or Fatal error: are printed into the page.
  • No shortcodes appear as plain text, like [gallery] or [contact-form-7 id="42"]. A visible shortcode means the plugin behind it stopped running.
  • Pages built with a page builder (Elementor, Divi, Beaver Builder and others) still look styled, not like plain text on a white page.

Money and measurement

  • yoursite.com/ads.txt still opens and matches the copy you saved. If it shows "not found," your ad networks may stop paying for impressions.
  • Ads still appear where they should. Check with any ad blocker turned off.
  • Your analytics tool shows your own visit in its real-time view.
  • The next day, check your ad network dashboard for a sudden drop in impressions or earnings.

Behind the scenes

  • You can still log in to WordPress, and Tools → Site Health doesn't show new critical issues.
  • Check the inbox for your WordPress admin email. When a plugin or theme causes a fatal error, WordPress sends a message titled "Your Site is Experiencing a Technical Issue." It names the culprit and includes a recovery-mode login link.
  • Send yourself a message through your own contact form, and make sure it arrives.

If something did break, the recovery-mode email above usually names the plugin or theme at fault. Log in with its link, deactivate that plugin, and check whether an update for it is available. Your host's error log names the culprit too. If a plugin you depend on has no PHP-compatible version, contact its developer or look for a maintained replacement.

Prefer it done for you?

If you'd rather not do this yourself, I'll handle the upgrade: I test on a staging copy first, upgrade PHP, check your key pages, ads.txt and ad code before and after, and fix whatever the upgrade breaks. See how the done-for-you PHP upgrade works.

Sources