PHP flaw (PHP2Shell): is your website at risk? What to do now

This is not a WordPress bug, and it is not a plugin. It sits in PHP itself, the language behind a large share of the world's websites. That is why the reach is so wide. Here is what matters if you own a website and do not write code: what happened, how to tell if you are exposed and what to ask your hosting company today.

What happened

On October 21, 2026, the PHP project shipped an emergency update for two critical flaws, CVE-2026-109618 and CVE-2026-109619. Researchers nicknamed the pair PHP2Shell.

In plain English: an attacker can send a request to your website and run commands on the server, with no login and no password. The technical term is remote code execution. PHP itself rated both flaws 9.2 out of 10 on the CVSS 4.0 scale.

One detail matters a lot. The attack happens before your site's own code starts running. Datadog reproduced the flaw and confirmed it: no login screen on your site can stop it, because PHP handles the malicious request first.

The same day, CISA, the US government's cybersecurity agency, published the alert "Critical Vulnerabilities in PHP Require Immediate Patching". The title says it all: patch now.

The dates explain the urgency:

• October 17. Amazon (AWS) logged the first exploit attempt, four days before a fix existed.
• October 21. The fixed versions came out. When CISA published its alert, it had not yet seen a successful attack. But the attempts were already happening.
• October 23. Unit 42, from Palo Alto Networks, reported the first confirmed break-in: a government body in Europe.

Who is exposed

Every PHP installation that serves web traffic, according to PHP. That covers the common ways to run PHP on a server: Apache with mod_php (the highest risk, according to PHP), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. If those names mean nothing to you, that is fine. It means almost any setup is on the list.

The flaws go back to PHP 5.4, released more than ten years ago, and run all the way to 8.5, the newest release.

In practice, you are exposed if you have:

• A WordPress site. WordPress runs on PHP. So does a WooCommerce store.
• A Joomla, Drupal, Magento or Moodle site. All of them run on PHP.
• A custom PHP system, like a client portal, an internal dashboard or your own online store.
• A forgotten old site. That campaign page on a subdomain, or the old site nobody switched off at another host.

The scale: according to W3Techs, in October 2026, PHP shows up on 69.3% of websites whose server-side language can be identified, and WordPress alone runs 39.6% of all websites. Unit 42, the research team at Palo Alto Networks, counted more than 22.6 million internet-exposed instances that are potentially vulnerable.

Nobody needs to pick your site by hand. Once a flaw like this goes public, bots start sweeping the internet for unpatched servers. Being a famous brand or not changes little.

How to check your site's PHP version

There are three ways, from fastest to most reliable.

1. Inside WordPress. Log in to the dashboard and go to Tools, then Site Health, the Info tab, the Server section. The "PHP version" line shows the number.

2. In your hosting control panel. In panels like cPanel and Plesk, look for something like "PHP Version", "PHP Settings" or "MultiPHP". That is where the version your site uses appears.

3. Through your host's support team. This is the safest way, because the number alone can mislead you. Many panels show only "8.3" without the rest. And Linux distributions and extended support vendors often ship the fix without changing the version number. So the right question is not just "which version". It is "has the fix been applied".

A message you can send today:

Hi. My website is (your address). Have you applied the fix for CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell and released on October 21, 2026, to the PHP on my plan? Which PHP version does my site use right now, with the full number?

How to read the answer:

• 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer in the same series: patched.
• 8.2, 8.3, 8.4 or 8.5 with a lower final number: needs an update, unless your host confirms in writing that it applied the fix on its own.
• 8.1, 8.0, 7.x or older: the PHP project no longer updates these versions. Read the next section carefully.

Online tools that try to read the version from your web address help little here. Many servers hide the version. And when they show it, they cannot tell you whether the fix was applied separately.

What to do today

If you are on shared hosting, the usual plan where you do not manage the server: in most cases, your host updates PHP. Your job is to ask and confirm. Send the message above and do not relax until you get a "yes, applied" in writing.

If your site runs PHP 8.1 or older: there is no official update. The PHP project says these versions no longer get fixes and points you to your vendor or to a supported version. CISA went further: anyone who cannot update right away, or still runs PHP 8.1 or earlier, should take those systems offline until they are fixed. The way out is moving the site to a supported version, such as 8.4 or 8.5. Do not stop at 8.2: it stops getting fixes on December 31, 2026. On an older WordPress site, the move can break an old theme or plugin. Back up and test first, ideally on a copy of the site.

If you run your own server, VPS or cloud instance: whoever manages it needs to update PHP to the fixed version and restart every PHP process. One catch Datadog points out: the version shown on the command line may not be the one serving your website. Check the one your site actually uses.

Ask for one extra setting. On October 23, PHP recommended turning off a rarely used feature, session.upload_progress, until the next regular release, to close an unlikely attack path. It does not replace the update. It adds to it.

A web application firewall helps, but it is not a fix. CISA says a web application firewall may offer some protection until systems are updated. Some. The fix is still updating PHP.

What not to do

• Do not rely on workarounds alone. Config tweaks are going around, like turning off session.upload_progress or changing memory_limit. PHP itself says they reduce exposure to specific attack paths but do not make an installation safe. Datadog reached the same conclusion. Only the update fixes it.
• Do not count on a security plugin. The attack happens before WordPress starts running. A plugin inside WordPress has no way to block it.
• Do not assume a WordPress update fixes it. The flaw is in PHP, on the server. Keeping WordPress, your theme and plugins current is still good practice, but it does not close this door.
• Do not wait for your next maintenance window. Exploit attempts started before a fix even existed.
• Do not paste commands from a forum into your server. Every crisis brings miracle fixes on social media and in group chats. Update through the official channels of your host or operating system.
• Do not panic or rebuild your site. In most cases this is a server update. Your website stays the same.

Next step

If you do not know where your site is hosted, who has access to the control panel or which PHP version it runs, that alone is a warning sign. Message me on WhatsApp and I will help you find out and push the right host to act. The one-page sites 27LAB delivers today are static pages with no PHP running on the server, so PHP2Shell does not reach them. To watch the 27LAB AI machine running every day, follow @bnd.g on Instagram. Or reach me on LinkedIn, Bernardo Garcia.

Sources

• PHP: security advisory, October 21, 2026 and informational advisory, October 23, 2026
• PHP technical advisories: CVE-2026-109618 and CVE-2026-109619
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Palo Alto Networks Unit 42: PHP2Shell threat brief
• Datadog Security Labs: PHP2Shell
• The Hacker News: emergency patches and the October 17 exploit attempt
• Also covered by: Rapid7, Qualys, Sansec and Wiz
• W3Techs, October 2026: PHP usage and WordPress usage