PHP SECURITY FLAW · OCTOBER 2026

PHP2Shell: is my WordPress site safe? How to check, and what to do today.

By Eddie Machaalani, founder of Zarla · LinkedIn · Updated October 2026

Two flaws in PHP, the software that runs WordPress, Drupal, Joomla and Magento sites, let someone take over a web server that hasn't been patched. Fixed PHP versions came out on 21 October 2026. Updating WordPress, your theme or your plugins doesn't fix it: your web host has to patch PHP. Here's how to check whether they have, in plain words.

The three things to do today

Every fact dated and linked to its source · No sign-up, nothing to download

The short version

  • What it is: two serious flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell). A web server running an unpatched PHP can be taken over by someone who has never logged in.
  • Who it touches: any website on a server running PHP 5.4 through 8.5.11. That includes most WordPress, Drupal, Joomla, Magento and Laravel sites, because PHP is what runs them.
  • The fix: the server's PHP has to be updated to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Your web host does this, not WordPress. Updating WordPress, themes or plugins does not fix it.
  • Today: ask your host whether PHP is patched (not scheduled, patched), take a backup, and check your WordPress users for an administrator you don't recognize.
  • Not every site is in this: a site that doesn't run on PHP isn't affected. Published Zarla sites are static pages served from a CDN. There's no PHP, no plugins and nothing for you to patch, so this flaw doesn't reach them.

The short answer

Last updated 22 October 2026, 4:50 pm AEDT. We re-check the sources below as the story moves.

Your WordPress site is safe from this flaw once the server it runs on is on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Until then it isn't, whatever version of WordPress you're on. The flaw is in PHP, the software underneath WordPress, which your web host installs and updates. So the question to ask today isn't "is WordPress up to date" but "has my host patched PHP".

Two things are true at once. The flaw is serious: PHP's own team says there are no complete workarounds and updating is the only safe choice, and CISA, the US government's cybersecurity agency, told organizations on 21 October to patch immediately, and to take a site offline if it can't be patched or runs PHP 8.1 or older (CISA). And the fix is simple and already out: hosts have been able to apply it since 14:00 UTC on 21 October, and WordPress.com announced the same day that every site it hosts was protected (WordPress.com). For most owners, the whole job is one message to the host and a five-minute check.

What happened, and when

Dates and times are in UTC, the way the sources report them (Sydney is 11 hours ahead; New York is 4 hours behind).

  • 20 October 2026. PHP announced that two critical security fixes would be released the next day at 14:00 UTC (php.net). Details of the two flaws leaked before that time (Cybernews); the release still went out as scheduled.
  • 21 October, early morning. Cloudflare switched on protections for the sites it fronts at 03:02 UTC and reported early use against servers before the fix existed (Cloudflare).
  • 21 October, 14:00 UTC (the announced time). PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, each fixing both flaws (php.net). The two flaws, found and reported by Wiz Research, are CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 on the CVSS v4 scale, and together nicknamed PHP2Shell. Just before 14:00 UTC, Patchstack's data showed only probing, with no hard evidence of a site being taken over (Patchstack).
  • 21 October. CISA, the US government's cybersecurity agency, told organizations to apply the patch immediately, and that anyone who can't update, or is still on PHP 8.1 or older, "should take PHP-based systems offline until they can be patched or updated" (CISA). The UK's National Cyber Security Centre issued an alert and the EU's CERT-EU issued advisory 2026-018 (Patchstack). Government websites in the Netherlands and Finland were taken offline while fixes were installed, local-government sites in France were disconnected, and services in Denmark, including a national school platform, were affected (Newsweek).
  • 21 October. Hosts started patching. WordPress.com announced that every site it hosts was already protected (WordPress.com); Malwarebytes' advice for everyone else was to ask your host to confirm the fixes are installed, not just scheduled (Malwarebytes).

Who it affects. PHP runs almost 70% of websites whose server-side language is known, according to the tracker W3Techs (Cybernews); WordPress, Drupal, Joomla, Magento and Laravel all run on it. Every PHP version from 5.4 to 8.5.11 is affected by at least one of the two flaws (Patchstack). What matters for your site is one number: the PHP version on the server it runs on.

This isn't a WordPress problem. In Cloudflare's words, "these flaws are in the PHP runtime, so updating website code or a plugin(s) alone does not fix these vulnerabilities" (Cloudflare); Search Engine Journal puts it as "updating WordPress or its plugins will not update PHP" (Search Engine Journal). WordPress, your theme and your plugins are fine; the ground they stand on needed a patch, and your host owns the ground.

THE FIVE-MINUTE CHECK

How to check whether your host has patched PHP

WordPress shows you the PHP version it's running on. Compare it with the four fixed releases.

01

Open Site Health in WordPress

Log in to your WordPress admin and go to Tools, then Site Health. Click the Info tab at the top, then open the Server section. The PHP version is listed there. If you can't see Tools, your login isn't an administrator; ask whoever set up the site to check for you.

02

Compare it with the four fixed versions

Patched means 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a newer number on the same line (8.4.28 counts; 8.4.26 doesn't). If it shows 8.1 or anything older, there's no release from the PHP project for that line: the host either applies a vendor-backported fix (ask for it in writing) or moves the site to a supported version. One wrinkle: Linux distributions got the patches in advance and ship the fix as an update to the version they already run, so on some hosts the number can look old while the fix is in. If the host says so, ask them to confirm it in writing.

03

Not patched? Message your host today

Use the message in "The three things to do today" on this page. Ask for a date, not a promise. Check whether your host has a status page about PHP2Shell first; the message gives them the exact question to answer.

04

Check again tomorrow

Hosts patch in waves. Site Health updates the moment the server does, so look again the next day. Keep the host's reply; if a problem turns up later, the date they patched is the first thing anyone will ask.

The three things to do today

None of these needs a developer. Together they take about twenty minutes.

1. Ask your host whether PHP is patched. Patched, not scheduled. Open a support ticket or chat with your host and paste this:

Hi, I'm checking on the PHP2Shell security fix (CVE-2026-109618 and CVE-2026-109619). Which PHP version is my site, [your website address], running right now, and is it one of the fixed releases: 8.5.12, 8.4.27, 8.3.36 or 8.2.35? If it isn't patched yet, when will it be? If my site is on PHP 8.1 or older, what's the plan to move it to a supported version? Thanks.

If you run your own server, or a developer does, the same question goes to them. If the site is on WordPress.com, WordPress VIP, WP Cloud or Pressable, the host announced on 21 October that every site it runs was protected (WordPress.com). On any other host, check for a status page first.

2. Take a backup. Most hosts have a backup button in the control panel; if yours doesn't, a backup plugin does the same job. Take one now and keep a copy somewhere that isn't the server, such as your computer or a cloud drive. A backup from before any trouble is what lets a host put your site back the way it was.

3. Check for an administrator you don't recognize. In WordPress, go to Users, then All Users, and filter by the Administrator role. You should recognize every name. If there's one you don't, don't delete it yet: change the passwords of the accounts you do recognize, tell your host, and ask them to check the server. Search Engine Journal's advice is the same, and adds a look for unfamiliar files on the server once the patch is in, which is a job for the host.

Done all three? That's the whole list for today. Patching is the host's job; your job was to ask the question and to have a backup if they're slow.

If your host can't or won't patch

Three situations come up, and each has a plain next step.

"It's scheduled." PHP released the fix on 21 October; a host that hasn't applied it yet should be able to tell you when it will, and it's fair to ask for a date. Until then, CISA's advice is that anyone who can't update immediately "should take PHP-based systems offline until they can be patched or updated" (CISA). For a small business site that means asking the host to show a temporary holding page with your phone number and email, so the site isn't reachable while it's unpatched. Your Google Business Profile, your phone and your email keep working.

"Your site is on PHP 8.1 (or 8.0, or 7.4)." No fixed release from the PHP project exists for those versions. Some hosts get a vendor-backported fix instead (php.net and Patchstack both say to ask your vendor); if yours says it has applied one, ask them to confirm it in writing. Otherwise the host has to move your site to 8.2 or newer, and CISA's advice for a site still on 8.1 or older is to take it offline until it's updated (CISA). Search Engine Journal's advice for a site on 8.1 or older is to back it up and arrange the upgrade (Search Engine Journal): that is the move described above, with the patch applied on the new version. Our own experience: most WordPress sites run on a newer PHP without trouble, and a plugin that breaks on it was already out of date and is worth replacing.

"We put a firewall in front of it." Good, and not the same thing. A firewall such as Cloudflare's blocks the known ways of reaching the flaw, and Cloudflare itself has said people kept changing their approach to get around the rules (Cloudflare). Cloudflare's own chief technology officer called firewall rules a stopgap (via Malwarebytes); PHP's own position is that there are no complete workarounds (php.net). Keep the firewall and still get PHP patched.

And if the answer is a shrug, that's information too. A host that can't tell you which PHP version you're on, or when it will be fixed, will give you the same answer next time. The hosting guide covers what to look for in a host, and what you can run without one.

PHP2Shell: your questions, answered

Is my WordPress site safe?

It's safe from this flaw once the server it runs on has PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or newer on the same line). Until then it isn't, whatever version of WordPress you're on. Check Tools, then Site Health, then Info, then Server for the PHP version, and ask your host if it isn't one of the four. Sites on WordPress.com and Automattic's other hosting (WordPress VIP, WP Cloud, Pressable) were protected by the host itself on 21 October, by its own announcement; for any other host, its status page or its reply to your message will say.

Does updating WordPress, my theme or my plugins fix it?

No. The flaw is in PHP, the software your web host runs underneath WordPress, and updating WordPress or its plugins doesn't change the PHP version. Keep WordPress updated anyway, for all the usual reasons; just don't take a green WordPress dashboard as a sign this one is handled. The only fix is the host updating PHP.

How do I know if my host patched PHP?

Look at the PHP version in WordPress (Tools, Site Health, Info, Server) and compare it with 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If it matches or is newer on the same line, you're patched. If not, ask the host and get the answer in writing; some hosts ship the fix as an update to the version they already run, so the number can look old while the fix is in, and only they can confirm that. Check whether your host has a status page about PHP2Shell first.

What is PHP2Shell?

The nickname for two flaws in PHP, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 and fixed on 21 October 2026. Each one lets someone who has never logged in run their own code on a web server that is still on an unpatched PHP, which means taking the server over. The flaws were found and reported to PHP by Wiz Research; the nickname attached itself when the details leaked on 20 October, the day before the fix.

Which PHP versions are affected, and which are fixed?

Every PHP version from 5.4 to 8.5.11 is affected by at least one of the two flaws. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older no longer receive releases from the PHP project, so a site on those versions either gets a vendor-backported fix from its host or moves to 8.2 or newer; PHP has published minimal source fixes for 7.4, 8.0 and 8.1 for people who build PHP themselves.

My site is on PHP 8.1 or older. What now?

Ask your host to move it to PHP 8.2 or newer and then apply the fix, and take a backup before they do. In our experience most WordPress sites run on a newer PHP without trouble; if a plugin or theme breaks, it was already out of date and is worth replacing. No fixed release from the PHP project exists for 8.1 or older; some hosts apply a vendor-backported fix instead, so ask whether yours has, and get it in writing. If there's no backport and the host can't move you, CISA's advice for a site on those versions is to take it offline until it's updated, which for a small business means a temporary holding page with your contact details.

Does a firewall or a security plugin protect me?

Partly, and only for now. A firewall in front of the site, such as Cloudflare's, blocks the known ways of reaching the flaw, and Cloudflare reported people changing their approach to get around the rules. A WordPress security plugin runs inside PHP itself, so it isn't a substitute for the patch. Keep whatever you have and still get PHP patched; PHP's own position is that updating is the only complete fix.

Is this WordPress's fault?

No. The flaws are in PHP itself, the software that runs WordPress; as Cloudflare puts it, updating website code or a plugin alone does not fix them. WordPress, Drupal, Joomla, Magento and Laravel all run on PHP, so they're all in the same position: fine on a patched server, exposed on an unpatched one. The decision that matters is your host's.

Should I take my site offline?

Only if your host can't give you a date for the patch, or your site is on PHP 8.1 or older with no move planned. CISA recommends taking an unpatched PHP system offline until it can be patched or updated, CERT-EU advised the same in Europe, in the form of isolating a site from the public internet until the fix is in, and several governments did exactly that on 21 October. The right move for most owners is to ask, back up and check again tomorrow. If you do take it down, ask the host for a holding page with your phone number and email rather than a blank error.

How will I know if something already went wrong?

Signs to look for: a WordPress administrator you didn't create, pages or links on your site you didn't add, a sudden warning from Google Search Console, or your host contacting you. If you see any of them, change your passwords, tell your host and ask them to check the server from a clean backup. If you see none, get the patch confirmed and move on.

Sources

Every fact on this page comes from one of these, read on 22 October 2026. If a source changes, this page changes with it; the "Last updated" line at the top says when we last looked.

If you'd rather not deal with this next time

Published Zarla sites are static pages served from a CDN. There's no PHP, no plugins and nothing for you to patch, so this flaw doesn't reach them. If you'd rather not be the one chasing a host about patches next time, you can bring your WordPress site across to Zarla: paste your site's address and it rebuilds your pages, words and photos in a new design in a few minutes, free to see and edit, and you pay when you publish. Zarla keeps your old page addresses where it can and redirects the ones that change, helping you keep the Google standing you've built, and your current site stays live until you point your domain at the new one. Bring your site across.