PHP Vulnerability Explained & What to Ask Your Host

At the end of the last episode, I gave you a heads-up about some news on a PHP vulnerability. Well, it landed. If you run a WordPress website, this one is definitely for you.

Welcome to No Stress Web Success. I’m Lisa Bowers, founder of Five Penny Web Studio, and this is our Web Understood series, where we turn confusing website news into plain English you can actually use.

Today’s topic is a security flaw in the PHP language. If you’ve never heard of PHP, that’s completely fine. Every WordPress website uses it, and this week the people who maintain it released an emergency fix.

I want to set the tone right away: This is not a panic episode. It’s a “let’s understand what happened and make sure the right person is handling it” episode.

Here’s what we’ll cover:

• What happened
• The difference between the PHP your site uses and the PHP on the hosting server
• How your type of hosting changes who protects you
• What patching really means
• Five questions to ask your host or developer (and the answers you should hope for)

What Is PHP?

It’s the programming language running your WordPress website on the web server. Think of it as the engine in the basement. WordPress is the storefront your visitors see, but PHP builds each page when someone visits.

On Tuesday, October 20th, the PHP team announced that a security update was coming the next day, fixing two critical problems. Critical is the top category, and both scored a 9.2 out of 10. The details leaked on social media before the official release, and the fix went out on Wednesday, October 21st.

What do these flaws allow? In plain terms, a malicious actor on the internet could send a specifically crafted request to a vulnerable server and potentially get it to run their own commands—no password, no login. The tech world calls that remote code execution, and it’s one of the threats you don’t want to see next to the word “critical.”

Now, here’s some honest nuance: That doesn’t mean every site has been hacked. It means the door is unlocked, and people are checking doors. Security researchers reported attack attempts around the time of the release, which is why the advice is “update immediately.”

And here’s the key point: The flaw is in PHP itself—not WordPress, not a plugin, not your theme. So you can’t fix this by updating your plugins or adding a security plugin. The repair has to happen on the server. (There are a lot of other websites and applications that run PHP, but WordPress is our focus for today.)

The fixed versions are:

• 8.5.12
• 8.4.27
• 8.3.36
• 8.2.35

Anything older within those families is affected. And if your site runs a PHP version older than 8.2, the PHP team no longer maintains it—so any fix has to come from your host or their software vendor. That’s an urgent conversation to have.

You may see the nickname “PHP2Shell” in headlines. It’s the same thing.

Two Kinds of PHP: Your Site’s and Your Server’s

Here’s where a lot of confusion starts. When someone says “update PHP,” they can mean two different things.

Staying with our engine analogy:
The first PHP is what your website is using—the engine plugged into your site right now. Your hosting control panel probably has a setting like “PHP 8.3” with a dropdown to change it. You can also see it inside WordPress: go to Tools → Site Health → Info tab → open the Server section. This is the one most site owners can see.

The second is the PHP installed on the server itself. A hosting server is a computer, and it can have several copies of PHP sitting on the shelf—different versions for different customers and tools, one installed by the operating system, one used in the background for jobs. You almost never see these.

Your control panel just chooses which engine is plugged in, but this week’s flaw is in all of them. So if someone updates the engine plugged into your site but leaves an old one on the shelf that something else is using, the problem isn’t fully solved. That’s why the question isn’t “Did you update my PHP version?” It’s “Has the whole server been patched?”

A sneaky wrinkle: The version number can be misleading. Many servers get PHP through the operating system, and those often receive the security repair without the version number changing. So an older number might actually be protected. The reverse happens too—the fix is installed, but PHP was never restarted, so the old code is still running. Treat the number as the start of a conversation: “I see version such-and-such. Has the October 21st security release been applied?”

On shared and managed hosting, the host handles the server side, and you mostly choose your version. On a private server, it may be you or your developer, unless you pay for a managed plan.

Hosting Types: Who Protects You?

Where your site lives changes who’s responsible for the fix, how fast it happens, and how much damage a problem can do. I’ll use a building analogy.

Shared hosting is an open-plan office. Lots of websites live on one server, sharing resources and usually the same PHP setup. It’s affordable, and the host handles the server for you. When they patch, they patch once for everyone. The catch is you’re on their timeline, and a problem with one neighbor can become everyone’s problem.

Isolated hosting is an apartment building. Same building, but every customer gets a locked apartment with its own walls. You hear words like “containers” or that each account is “jailed.” Hosts like Pressable and SiteGround’s cloud plans work this way. The host still manages PHP for you, but if one site has a problem, the walls keep it from spreading.

Here’s the important part: Walls limit the spread. They don’t fix the broken lock. This flaw is in PHP itself, so every apartment still needs the fix. To their credit, both of those hosts moved fast. Pressable said it had all of its sites already protected on every PHP version. SiteGround said it protected its servers before the release and has applied the fix. Those are their own statements—so confirm for your site—but a specific public notice is a good sign.

A private server is your own house. Nobody else has their sites on it. More control, and often better performance. Providers like Cloudways and xCloud help you run your own cloud server, but a house comes with house duties. Depending on your plan, server updates might be handled for you, or it might be up to you or your developer to click the button. In the latest reports I saw, Cloudways had put interim protections in place while a phased rollout of the official patches was coming. Those status pages change by the hour, so check yours.

To recap:

• Shared → the host patches for everyone, and you wait
• Isolated → the host patches, and walls limit the damage
• Private → you, your developer, or a managed service patches

No hosting type makes this flaw disappear. It just decides who has the screwdriver.

What Patching Actually Means

You’ve heard the word “patch” a hundred times. Let’s make sure it means something.

A patch is a small, targeted repair. Think of a car recall: the manufacturer doesn’t build you a new car—they fix the one part. For PHP, it shows up as a small version change. Say your server runs 8.3.35; the patched version is 8.3.36. Same family, same features, flaw repaired. Because it’s such a small step, patching is usually low-risk for your website.

That’s different from an upgrade, like moving from 8.2 to 8.5. Upgrades are bigger. They may be the right move if you’re on a version that no longer gets fixes, but an older plugin or theme can break. So be sure to test on a copy of your site and back up first.

Patching takes three steps:

1. The fixed version is installed.
2. PHP is restarted. (That step gets skipped more than you think, because the old code can keep running until the restart.)
3. Someone checks that your site still loads, your forms still send, and your donation page still works.

You’ll also hear about stopgaps. Firewall rules from your host or a service like Cloudflare are temporary settings—basically a deadbolt while you wait for the locksmith. They’re good, but the PHP team itself says updating is the only fix.

And the last point: A patch closes the door. It doesn’t check whether someone already walked through. So after patching, it’s fair to ask for a quick check for unfamiliar administrator accounts or files nobody remembers adding. Most sites will come back clean.

And a reassurance: No WordPress update is needed for this. WordPress.org has said so. The fix happens at the level below.

Five Questions to Ask Your Host or Developer

These are the five questions you can take straight to your inbox. Send them to your host or your web developer. If your developer only handles the website, a good one will tell you which questions are theirs and which belong to the host.

Question 1: On my plan, who is responsible for patching PHP—you, me, or the developer?
You hope to hear one clear sentence, like “We handle it on all managed plans,” or “On your private server, that’s yours, and here’s where to do it.” Be concerned if it’s vague, or if everyone points to someone else.

Question 2: Has the October 21st PHP security release been applied to my site’s server, and when?
You hope to hear a yes with a date, or a link to a status notice. If it’s not yet, you want a date and what’s protecting you in the meantime. Be concerned by “We are monitoring the situation” with nothing behind it.

Question 3: What PHP version am I on? Is the whole server covered, and is that version still supported?
You hope to hear a specific version, or something like “The number looks older because our systems apply fixes without changing it, and here’s how we confirm.” You also want to hear that unused old copies of PHP are updated or removed, and that you’re on 8.2 or newer. Be concerned if they can’t tell you the version, only mention your control-panel setting, or that you’re on 8.1 or older with no plan to move.

Question 4: If the full fix isn’t in place yet, what protection is active right now, and when will the real fix land?
You hope to hear something like “Firewall rules block the known attack, and the patch rolls out by Friday.” You want an honest commitment that it’s temporary, with a timeframe. Be concerned if the stopgap is treated as the finish line, or if there’s no timeline.

Question 5: After patching, will anyone check my site for signs of anything that happened before the fix, and what happens if you find something?
You hope to hear yes—a scan, a look at user accounts and recently changed files, and a plan. Even “We haven’t seen signs on our server, and here’s what we check” is a solid answer. Be concerned if “It’s patched” is the whole answer.

Bonus tip: If an answer comes back as a wall of jargon, you’re allowed to say, “Can you put that in plain terms?” Good providers are glad to.

Three Things to Remember

1. This flaw is in PHP, not WordPress. Updating plugins is a good habit, but it isn’t the fix.
2. Your type of hosting decides who does the patching—so know which one you have and who holds the screwdriver.
3. “Patched” means installed, restarted, and checked.

Your 15-Minute To-Do List for This Week

• Find out who handles PHP on your hosting plan.
• Look up your PHP version (Tools → Site Health → Info → Server).
• Send the five questions we discussed to your host or developer (they’ll be in the show notes so you can copy and paste).
• Make sure you have a recent backup of your site.

And please—don’t panic. For most people, the host is already on it, and the answer will be a reassuring “Yes, it’s handled.” Your job isn’t to fix the server. It’s to make sure someone competent is, and to know how to ask.

I’ll keep an eye on the story. If anything changes, you’ll hear it here. I know there’s rumors right now of a new vulnerability that was just found as of today (Friday). We’re still waiting to hear details about that. From what I gather, it only applies under very certain circumstances, so it’s a lot less of a threat. But we really don’t know at this time because it’s still new, and we may be hearing more over the next few days. So just don’t stress about it—keep in touch with your web developer and your host, and make sure your backups, more than anything, are staying current.

As always, thank you for spending time with me today. If this helped, share it with a friend who runs a website, or an executive director who’s been wondering what all this PHP talk is about. Send me your questions at fivepennyweb.com. And I’d love if you could leave me a review on our podcast, wherever you listen.

Again, I’m Lisa. This is No Stress Web Success, and I will see you next week.