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. On a Windows server, the builds to run are the rebuilt packages PHP posted on 26 October (8.5.12-1, 8.4.27-1, 8.3.36-1 or 8.2.35-1), which also fix a separate flaw in a compression library.
  • 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 30 October 2026, 7:19 am 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); on 26 October it added both flaws to its Known Exploited Vulnerabilities catalog, its list of flaws it has seen used against real systems. On 28 October it added a Linux flaw to the same catalog, saying it can be used together with the two PHP flaws to take full control of a server (CISA catalog); the fix for that one has been in regular Linux updates since May 2026 (NVD), so the question for your host is whether the server is taking its updates, and has been restarted, as well as whether PHP is patched. 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).
  • 23 October. PHP posted a short informational advisory suggesting that hosts also turn off one setting, session upload progress (session.upload_progress.enabled=0), until its next regular bugfix release (php.net). It closes an unlikely edge case that needs an unusual mix of server configuration and application code, so PHP is handling it in its normal release cycle. The setting was already listed in the 21 October advisory; a host that applied it then has nothing more to do. The four fixed releases of 21 October still stand, and the host message on this page now asks about the setting too.
  • 26 October. CISA added both flaws, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities catalog, its list of flaws it has seen used against real systems, and revised its alert to say so (CISA). The catalog entries give US federal civilian agencies until 29 October to apply the fix (CISA catalog). An earlier revision, on 23 October, had added a detection rule for server logs and links to partner agencies' guidance. The advice itself hasn't changed: update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or take the system offline until you can.
  • 26 October. PHP posted rebuilt Windows packages, 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 (php.net). They are the same four PHP releases with an updated copy of Brotli, a compression library, inside, fixing a separate flaw in it (CVE-2026-111497), which in PHP's Windows builds can be reached through the cURL extension when automatic response decompression is turned on; it's off by default, though an application can turn it on. In PHP's words, the -1 "identifies a Windows package rebuild with updated dependencies", and "the PHP runtime versions remain unchanged". So: on a Windows server the -1 builds are now the ones to run; for Linux or macOS there's nothing new from PHP, and the four releases of 21 October still stand.
  • 28 October. CISA added a flaw in the Linux kernel, the core of the Linux system, CVE-2026-46300, to its Known Exploited Vulnerabilities catalog, saying it "can be chained with" the two PHP flaws "to implant PHP webshells and run commands as root" (CISA catalog). In plain words: the PHP flaws get someone onto an unpatched server, and the Linux flaw then hands them full control of it, so a server needs the Linux fix as well as the PHP update. US federal civilian agencies have until 31 October to apply it. The Linux fix isn't new: the flaw was published, with its fix, on 23 May 2026 (NVD), and Linux distributions have carried it in their regular kernel updates since May 2026, so a server that has been taking its updates, and has been restarted since, already has it. For an owner it adds one question to the host message on this page: is the server's kernel up to date, and has it been restarted?

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. On a Windows server, ask for the rebuilt packages PHP posted on 26 October (8.5.12-1, 8.4.27-1, 8.3.36-1 or 8.2.35-1): Site Health shows the same PHP number either way, so only the host can confirm it.

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? On 23 October the PHP project also suggested setting session.upload_progress.enabled=0 on the server until its next regular release. Is that in place for my site? If my site runs on a Windows server, is it on the rebuilt Windows packages PHP posted on 26 October (8.5.12-1, 8.4.27-1, 8.3.36-1 or 8.2.35-1)? If it runs on a Linux server, is the kernel up to date with the fix for CVE-2026-46300, which CISA listed on 28 October as one that can be used together with the PHP flaws, and has the server been restarted since that update? 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. On a Linux server you manage yourself, that means two things: update PHP to a fixed release, and run the system's regular updates, kernel included, then restart the server, because a new kernel only takes over after a restart (the fix for the Linux flaw CISA listed on 28 October, CVE-2026-46300, has been in those updates since May 2026). 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); since 26 October both flaws are on its Known Exploited Vulnerabilities catalog, its list of flaws it has seen used against real systems, with US federal civilian agencies given until 29 October to apply the fix (CISA catalog). 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. On a Windows server the builds to run are the rebuilt packages of 26 October, 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1, which carry the same PHP releases plus a fix for a separate flaw in a compression library.

My site is on a Windows server. Is there anything extra?

One thing. On 26 October PHP posted rebuilt Windows packages, 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1: the same four fixed releases with an updated copy of Brotli, a compression library, inside, which fixes a separate flaw in it (CVE-2026-111497). In PHP's Windows builds that flaw can be reached through the cURL extension when automatic response decompression is turned on, which is off by default, though an application can turn it on. The PHP version number doesn't change, so Site Health can't tell you whether the rebuild is in; ask your host for the -1 builds by name, and the host message on this page does. For Linux or macOS there's nothing new from PHP: the four releases of 21 October still stand.

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 30 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.