Why Your Hosting Provider Just Sent You an Emergency PHP Warning

If your hosting provider emailed you this week about emergency maintenance, you're not alone. Not a routine update notice. One of those "we found something serious and here's what we're doing about it" emails.

That's what happened to us. Two emails landed in the same week, from two different hosts, both pointing at a PHP vulnerability serious enough to justify unscheduled downtime. I read into it further. Here's what it actually is, why it matters if you run WordPress, and what we did about it for our own clients.

What Is Actually Going On With PHP Right Now?

In October 2026, security researchers disclosed two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "php2shell." Both are rated 9.2 out of 10 on the CVSS scale, which is about as severe as it gets, and both allow remote code execution without needing a username or password.

That last part is what made hosts react so fast. An attacker doesn't need to log in, guess a password, or trick anyone into clicking something. A single request to a vulnerable server can be enough.

The bugs sit in PHP's core, not in WordPress, Laravel, or any specific app. Researchers confirmed every PHP version going back to 5.4 is affected. PHP's own team shipped fixes in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. If a server isn't running one of those versions (or later), it's exposed.

To make things worse, exploit details leaked publicly before the coordinated patch rollout was complete, which is why this moved from "quietly patch when convenient" to "emergency maintenance window" for a lot of hosting providers almost overnight. Government security agencies, including Canada's Centre for Cyber Security, issued alerts treating it as actively exploited.

Why Does A PHP Bug Become A WordPress Problem?

WordPress runs on PHP. Every plugin, every theme, every page your visitors load gets built by a PHP interpreter sitting on your server. That's true whether your site is a simple brochure page or a five plugin booking system. So when the flaw lives inside PHP itself, it doesn't matter how well built your WordPress site is. The weak point is underneath it.

This is also why updating WordPress or your plugins doesn't fix it. Those updates can't reach down into the PHP interpreter. The patch has to happen at the server level, which usually means your hosting provider, not you, has to act, unless you manage your own server.

And a lot of WordPress sites are more exposed than their owners realize. Industry data puts roughly a third of all WordPress sites on a PHP version that's already end of life, meaning it won't get an official security fix at all. PHP 7.4 alone still powers a meaningful chunk of the web.

This is also the one place where our clients already running on Next.js instead of WordPress genuinely had nothing to worry about this time. Next.js doesn't run a PHP interpreter on the server the way WordPress does, so this particular vulnerability simply doesn't apply to those sites. That's not a blanket "Next.js is safer" claim. Every stack has its own risks. But for this specific scare, it was a real, concrete difference.

How Do I Know If My Site Is Affected?

Start by finding out exactly which PHP version your site is actually running. Not what your developer set it to two years ago, what it's running right now, while serving a real request. Most hosting control panels show this under something like "PHP version" or "Server settings." If you can't find it, ask your host directly. It's a fair question and any host should be able to answer it in minutes.

You're in reasonably safe shape on 8.5.12, 8.4.27, 8.3.36, 8.2.35, or newer. If you're on anything older, especially 8.1, 8.0, 7.4, or earlier, treat your site as exposed unless your host or hosting stack has specifically confirmed a backported fix.

It's also worth a quick look for anything unusual, especially if you're not sure how long your site has been sitting on an old PHP version. New admin accounts you don't recognize, theme or plugin files with recent edit dates you didn't make, odd outbound traffic from your server, or your site becoming unexpectedly slow are all worth investigating. Before you change anything, take a full backup, including the database, so you have something to roll back to.

What We Did For Our Maintenance Clients

The moment those emails came in, we didn't wait to see if it would blow over. We went through every WordPress site we maintain, a mix of tourism businesses, wellness retreats, real estate listings, and booking systems, and checked the PHP version each one was actually running, not just what it was set to when the site first launched.

A couple of sites were already current. A few needed an update pushed through the host immediately. Either way, every client under our maintenance plans was taken care of before the week was out, and before most site owners who manage things themselves even knew there was something to worry about.

It's worth saying plainly: a couple of projects we'd already moved off WordPress and onto Next.js didn't factor into this at all. Nothing to patch, nothing to check, because the vulnerability lives in a part of the stack those sites don't have. That's not why we migrated them in the first place, but it's a real benefit that showed up this week.

What Should You Do If Your Host Hasn't Said Anything?

Silence from your host isn't the same as being safe. Smaller hosts, older shared hosting plans, and self-managed servers are exactly the setups most likely to still be sitting on an outdated PHP version, and the least likely to proactively reach out about it.

If that's you, don't wait for an email. Log into your hosting panel and check your PHP version directly, or contact support and ask point blank whether they've patched the servers your site runs on. If you're on an end of life PHP branch like 7.4, ask specifically whether your host has applied a vendor backported fix, since those branches don't get an official patch from PHP itself.

If you can't get a straight answer, or you can't patch right away, reduce your exposure in the meantime: restrict admin access where you can, keep backups current, and keep an eye on your site's activity logs. None of that replaces an actual patch, but it buys you time while you sort out a proper fix.

Common Questions About This PHP Vulnerability

Do I need to do anything if WordPress and all my plugins are already up to date?

Yes. This vulnerability lives inside PHP itself, underneath WordPress, so keeping your CMS and plugins current doesn't touch it. The fix has to happen at the server level.

How do I actually check what PHP version my site is running?

Your hosting control panel usually has a "PHP version" or "server settings" page. If you can't find it, ask your host's support team directly and ask them to confirm the version serving live requests, not just what's listed in a config file.

What if I'm on shared hosting and don't control the server myself?

That's most WordPress site owners. Contact your host and ask whether they've patched against CVE-2026-109618 and CVE-2026-109619. Most hosting providers manage PHP versions centrally, so this is usually their responsibility, but it's worth confirming rather than assuming.

I checked and I'm on PHP 7.4. What now?

That branch is end of life, meaning PHP won't release an official fix for it. Ask your host whether they've applied a backported patch from their Linux distribution. If not, moving to a supported PHP version should be a priority, not a someday task.

Could my site already be compromised without me knowing?

It's possible. Exploit details leaked before patches were widely applied, so there's a real window where this was actively used. Watch for admin accounts you didn't create, file changes you didn't make, and unusual outbound traffic.

Is this only a WordPress problem?

No. Any website or application running PHP is exposed, including Drupal and Joomla sites and custom PHP applications. WordPress gets the most attention because it runs such a large share of the web.

Does moving to Next.js protect me from everything like this going forward?

It removes this specific category of risk, since Next.js doesn't rely on a PHP interpreter the way WordPress does. It's not a guarantee against every future issue. Every stack has tradeoffs, but for this particular vulnerability, it's a genuine difference.

What's the one thing I should do today?

Confirm your site's actual PHP version and whether your host has patched it. That single check tells you whether you need to act.

Next Steps

If you take one thing from this, make it the PHP version check. It takes a few minutes and tells you immediately whether you need to act.

1. Confirm the exact PHP version your site runs on right now, not what it was set to originally.
2. If it's below 8.2.35, 8.3.36, 8.4.27, or 8.5.12, contact your host and ask directly about CVE-2026-109618 and CVE-2026-109619.
3. Take a full backup before anything else changes.
4. Check your site's activity for anything unusual since at least June 2026.
5. If you want a broader look at where your site stands technically, not just this one issue, our free Website Audit tool is a reasonable starting point.

This is also exactly the kind of thing our maintenance plans exist for, catching this before it becomes a problem rather than after. If you'd rather not keep chasing PHP versions and host emails yourself, or you've been thinking about whether a static, modern framework like Next.js makes more sense for your site long term, we're happy to talk through either option. No pressure either way. You can book time with us if that's useful.