PHP2Shell: What to Do If You Manage Multiple WordPress Sites

PHP shipped emergency fixes for two critical flaws on October 21, 2026. If you run one site, the advice everywhere is the same: check your PHP version and patch it. If you manage twenty client sites across six different hosts, that advice is not useful. This is the version for you. How to triage the list, which clients to do first, and what to tell them before they email you.

The NSA has urged immediate patching for the flaws nicknamed PHP2Shell. Cloudflare notes that PHP runs on almost 70% of websites. Below: what the bugs are, how to check for compromise if a site ran mod_php during the exposure window, how to work a multi-site client list in an afternoon, a short client email template, host patch status for the platforms WPOPS clients actually use, and what to do if your host has not patched yet.

Running a single site on WordPress.com, or on a fully managed host? You are almost certainly already patched and there is nothing for you to do. Skip to the host table below to confirm.

What PHP2Shell is, in plain words

Both flaws come from the same weakness. When a request to a PHP server ends badly, for example when it runs out of memory at the wrong moment, PHP can leave its memory in a broken state. A carefully crafted request can then use that state to run its own code on your server, with the web server's permissions. That's enough to plant a backdoor, inject spam pages or redirects, or steal data.

The PHP security team rates both flaws 9.2 out of 10 (CVSS v4). They affect every PHP setup that serves web pages, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest on mod_php, where a demonstrated exploit runs before any WordPress code loads, so a security plugin inside WordPress can't stop it.

Amazon Threat Intelligence reported an exploitation attempt on October 17, four days before the public announcement, and more attempts followed on October 21. CISA in the US and the NCSC in the UK have both urged everyone to patch immediately.

If you were running mod_php last week, patching is not enough

Exploitation attempts began on October 17, four days before a patch existed. If your site ran mod_php on an affected PHP version during that window, patching now closes the door but does not tell you whether anyone already walked through it. Check for compromise before you call it done.

What to look for. Admin users you did not create. PHP files with recent modification dates in wp-content/uploads, which should never contain executable PHP. Scheduled tasks you do not recognise. Outbound connections from the server. Pages indexed that you never published.

Why your security plugin did not catch it. The exploit runs at the PHP layer, before WordPress loads. Wordfence, Sucuri and the rest never see the request. This is counterintuitive and most site owners assume they were covered. WordPress.com makes the same point from the other direction, advising their users not to add a security plugin because it does not help here.

What to do if you find something. A compromised site needs cleaning, not just patching, and a restore from a backup taken after October 17 may restore the backdoor along with the site. If you need hands-on help, start with malware removal or emergency support.

Is my WordPress site affected?

If your site runs PHP and hasn't been updated since October 21, assume yes. The fixed versions are:

• PHP 8.5: 8.5.12 or newer

• PHP 8.4: 8.4.27 or newer

• PHP 8.3: 8.3.36 or newer

• PHP 8.2: 8.2.35 or newer

• PHP 8.1, 8.0, 7.x: No regular fix. These versions are end of life, so move to a supported branch or ask your host about a backported patch.

How to check your PHP version in two minutes

1. Log in to your WordPress dashboard.

2. Go to Tools, then Site Health, then the Info tab.

3. Open the Server section and look at "PHP version".

4. Compare it with the table above.

How to triage twenty client sites in an afternoon

Do not work through the list alphabetically. Sort by exposure. Sites running mod_php on an affected PHP version are the only ones at real risk, and among those, anything taking payments or storing customer data goes first. Most of a typical client list will turn out to need nothing at all.

Priority order:

1. mod_php, plus ecommerce or customer data. Highest risk, highest consequence. Do these today.

2. mod_php, everything else. The exploit runs before WordPress loads, so nothing inside WordPress protects them.

3. PHP-FPM or FastCGI on an affected version. Still needs patching, lower exposure.

4. PHP 8.1 or older. No official fix exists. These need a version upgrade, which is a project rather than a patch, so start the conversation today and schedule the work.

5. Already on a patched version. Confirm and move on.

Checking in bulk

Checking one site at a time through wp-admin does not scale past about five sites.

php -v over SSH shows the CLI version, which is frequently not the version the web server runs. The web version is the one that matters here. A one line phpinfo file, deleted immediately after, is the reliable check.

If you use a management dashboard, most will show PHP version across all connected sites on one screen. Agencies running white-label care under their own brand can fold this into the same weekly ops pass you already use for updates and backups.

Write the result into a simple sheet: site, host, PHP version, handler, action needed. You will need it again when clients ask.

What to tell your clients before they ask

Clients will hear about this from the news before they hear it from you, and silence reads as either ignorance or a cover-up. Send a short note to every client today, even the ones who need nothing. Say what the issue is in one line, what you checked, what you found on their site specifically, and whether any action is needed from them.

Copy and adapt this:

Subject: Your site and this week's PHP security issue

Hi [name],

You may have seen reporting on a critical PHP vulnerability announced on 21 October. PHP is the software your website runs on, and the flaw could let an attacker run code on affected servers.

I checked your site this morning. [Your site was already on a patched version and no action is needed. / I applied the fix this morning and tested the site afterwards. Everything is working normally. / Your site runs an older version of PHP that no longer receives security fixes. I would like to schedule an upgrade, and I will follow up separately with options.]

There is nothing you need to do. If you notice anything unusual on the site, tell me and I will look straight away.

[name]

The three bracketed options cover almost every client. Sending the "nothing needed" version to unaffected clients is the one most agencies skip and the one that earns the most trust.

Who patches PHP? It depends on your hosting

• Fully managed platforms (for example WordPress.com, which says all its sites are already protected): the platform patches PHP for you. Check their announcement to confirm.

• Shared hosting (Hostinger, SiteGround, Bluehost and similar): the host updates its PHP builds, but you often choose the PHP version yourself in the control panel. If your site is pinned to an old version, it stays exposed.

• VPS or your own server: it's on you. Update the PHP packages now and restart PHP-FPM or Apache.

Status for hosts WPOPS clients use most, checked against each host's own post or status page on 22 October 2026:

For hosts not listed here, ActiveSet maintains a tracker covering 35 providers.

Not sure which one you are? Ask your host today: "Have you patched PHP for CVE-2026-109618 and CVE-2026-109619 on my server, and which PHP version is my site on?"

If your host has not patched yet

If you are waiting on a host and cannot apply the fix yourself, the single most effective step is moving off mod_php. The exploit path runs through the module before WordPress loads, so switching the handler to PHP-FPM or FastCGI removes the most exposed configuration even while the version stays the same.

A web application firewall can block some known attack patterns while you wait, if your provider has published a signature, but the PHP team is clear that updating is the only complete fix. Restrict access to the site while it is exposed if you can. Raise a ticket rather than waiting, and ask the exact question above.

What to do today

1. Take a full backup of your files and database before changing anything.

2. If you're on a supported branch but behind, ask your host to apply the latest patch, or switch it yourself in your hosting control panel.

3. If you're on PHP 8.1 or older, plan the move to PHP 8.3 or 8.4 now. Test on a staging copy first if you can, because old plugins and themes sometimes break on newer PHP.

4. After the update, test the pages that matter most: contact forms, checkout, login and any booking tools.

5. If the site ran mod_php on an affected version between 17 and 21 October, run the compromise checks in the section above before you call it done.

Patching closes the door without removing anything that already got in. Ongoing WordPress maintenance is what keeps PHP, core and plugins current so the next critical release is a routine ticket, not a scramble.

Why this keeps happening

Most WordPress owners think about plugin and core updates. Few think about the server software underneath. PHP updates are usually handled by the host, but "usually" isn't "always", and old PHP versions often stay in place for years because nobody checks.

That's exactly the kind of quiet gap that turns into a hacked site. A care plan that includes staged updates and security monitoring is how you stop treating every PHP advisory as a fire drill.

Frequently Asked Questions

What is PHP2Shell in one sentence?

Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that let an attacker run code on a web server without logging in. Both carry a CVSS score of 9.2. PHP released fixes on 21 October 2026.

Is my WordPress site affected?

If your site runs PHP and has not been updated since 21 October, assume yes until you have checked. The risk is highest on mod_php, where the exploit runs before WordPress loads. Check the PHP version your web server uses, not the command line version, as the two often differ.

I am on managed hosting. Do I need to do anything?

Probably not. Most managed platforms patched at infrastructure level within a day, and WordPress.com has confirmed it did so ahead of the release. Check your host's status page or the table above to be certain. Managed does not always mean managed PHP, so confirm rather than assume.

I patched. Am I safe now?

You are protected going forward. You are not automatically clear of what came before. Exploitation attempts started on 17 October, four days before the patch existed, so a site that ran an affected version on mod_php during that window should be checked for compromise before it is considered done.

Will my security plugin protect me?

No, and this surprises people. The exploit runs at the PHP layer before WordPress loads, so Wordfence, Sucuri and similar plugins never see the request. They remain useful for other things. They do nothing for this.

What if I am on PHP 8.1 or older?

There is no official fix, because those versions are end of life. Your options are upgrading to a supported branch, which needs testing on staging because older plugins may break, or asking your host whether they backport security patches. Some do. Start that conversation today.

Need a hand?

If you're not sure what your sites run, or the update breaks something, we can help. WPOPS looks after WordPress sites every day: PHP and core updates, plugin compatibility checks, backups and security monitoring. Malware removal is included on every plan, with a guaranteed 1-hour response time.

Contact us or email support@wpops.net, and we'll check your site's PHP version and tell you exactly what it needs. You can also compare our plans.

Sources

• PHP Foundation: Today's PHP security release, October 21, 2026

• CISA: Critical vulnerabilities in PHP require immediate patching, October 21, 2026

• Tenable: PHP2Shell FAQ

• BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws

• WordPress.com: Your WordPress.com site is protected against PHP2Shell vulnerabilities, October 21, 2026

• NSA Advisory: Critical patches recommended for PHP vulnerabilities, October 21, 2026

• Cloudflare: PHP powers almost 70% of websites (php2shell WAF note), October 2026

By Manny - Founder, WPOPS