Your host has patched PHP2Shell only if it can tell you, in writing, which PHP build each of your sites runs and when the fix went in. The version number in your dashboard is a clue, but many hosts backport security fixes without changing that number. Send support five specific questions and ask for a dated answer for each site.
What if your IT person is on vacation when a PHP flaw is disclosed?
You handle it the same way they would: find out what PHP your sites run, ask the host in writing whether the fix is in, and keep a record of the answer. None of that requires a terminal or a developer. It takes about 20 minutes of your time plus however long support takes to reply.
Here's the situation we heard about most often in the days after the PHP2Shell disclosure (CVE-2026-109618). A company with a dozen employees runs three WordPress sites: the main marketing site, a booking site, and a small WooCommerce store for merchandise. One person handles "IT" part-time, and that person is on a beach for ten days. The owner reads a headline about a critical PHP flaw that lets attackers run code on a server, and has no idea whether it applies.
It almost certainly applies. According to W3Techs, PHP runs about three quarters of all websites whose server-side language is known (2025), and every WordPress site is one of them. What the headline can't tell you is whether your particular host has already closed the hole on the particular servers your three sites live on. That's the question this post answers.
What does "patched for PHP2Shell" mean for a WordPress site?
It means the PHP engine running underneath your WordPress install has been replaced or rebuilt with the fix, and the running PHP processes have been restarted so the fixed code is what serves your pages. Updating WordPress core or your plugins does nothing for this flaw. PHP lives on the server, and on most hosting plans only the host can touch it.
That's the part non-engineers find odd. You can click "Update" on every plugin in your dashboard and still be exposed, because the vulnerable code sits one layer below WordPress. If you're on shared hosting, a managed WordPress plan, or a reseller account, the host owns that layer. If you rent a bare cloud server or VPS and installed WordPress yourself, you own it, and nobody is coming to patch it for you. Our comparison of cloud hosting vs WordPress hosting covers that split in more detail.
How to check your PHP version without an IT person
Log in to WordPress, go to Tools, then Site Health, then the Info tab, and expand the Server section. The PHP version line shows what your site is running right now. Write it down for each site, because sites on the same host can run different versions.
You can also find the version in your hosting control panel. In cPanel it's under "Select PHP Version" or "MultiPHP Manager." On managed hosts it's usually on the site's overview or settings page.
Now the catch. The PHP project releases fixes as new point versions, so in theory you'd compare your number against the fixed releases in the PHP security advisory and be done. In practice, many hosts run PHP builds from their operating system vendor or from CloudLinux, and those builds get the fix backported into the existing version number. A server running a fully patched backported build can show the same version string it showed last week. So your check tells you one useful thing: which branch you're on.
The branch matters more than most owners realize. The PHP project's supported versions page shows security support for PHP 8.1 ended on December 31, 2025. If Site Health says 8.1, 8.0 or 7.4, there is no official upstream fix for PHP2Shell on your branch at all. The only way that site gets patched is if your host maintains its own extended-support builds, or moves you to a supported branch. That makes it the first thing to ask about.
What should you ask your host's support team?
Ask for answers per site, in writing, with dates. Vague replies like "we keep our servers up to date" don't tell you anything. Open a ticket instead of a live chat if you can, so you have a record to forward to your IT person when they're back. Copy the message below, swap in your domains, and send it.
Subject: PHP2Shell (CVE-2026-109618) patch status for my sites
Hello, please confirm the following for each of these sites: example.com, booking-example.com, shop-example.com.
- What PHP version is each site running right now?
- Has the fix for CVE-2026-109618 been applied to the servers hosting these sites? If yes, on what date and time?
- Was the fix an upgrade to a fixed upstream PHP release, or a backported patch? If backported, what build or package identifier confirms it?
- Have the PHP processes serving my sites been restarted since the fix, so the patched code is what's running?
- If any site is on PHP 8.1 or older, will you patch that branch, or do I need to move to a newer version? What's the deadline?
- If the fix is not yet applied, when will it be, and is any firewall rule blocking known exploit attempts in the meantime?
Thank you.
Question 4 trips up more hosts than you'd expect. When a server's PHP package is updated, the processes already running keep using the old code until they're restarted. A host that updated the package but skipped the restart can truthfully say "we installed the patch" while the vulnerable code is still answering requests. Asking directly gets you a direct answer.
Why did SiteGround, WP Engine and GoDaddy patch at different speeds?
Patch speed depends on how a host builds PHP, how many servers it has to touch, and whether your plan sits on a separate fleet. Customer reports after disclosure said SiteGround patched within about an hour, WP Engine customers were still waiting on a confirmed date, and GoDaddy fixed Managed WordPress servers before regular shared hosting.
We haven't verified each host's internal timeline, and your account may not match what others reported. The reasons behind the differences are predictable, though, and they apply to whatever host you use:
- Who builds the PHP. Hosts that compile their own PHP can ship a fix as soon as the patch is public. Hosts that wait for their operating system vendor's package wait for that vendor first.
- How many servers are involved. A shared hosting brand may run thousands of servers with hundreds of accounts each. Rolling a PHP change across that fleet usually happens in stages, and your server might be in the last stage.
- Which plan tier you're on. Managed WordPress plans often run on a separate, more standardized platform with its own team. That's the likely reason GoDaddy customers saw Managed WordPress patched first: fewer variations to test, and a team whose job is that platform.
- Testing and change windows. Some hosts test a PHP change against customer sites before rollout, which is sensible, but it adds hours or days.
There's also the reseller problem. If your "host" is a web designer or a small brand reselling someone else's servers, they're waiting on their upstream provider too. Ask them who that provider is. If they can't answer, add that to the list of things you've learned about your hosting this week. We wrote about the broader version of this in our post on how managed hosts handle zero-day WordPress threats.
Speed matters because attackers move fast. According to Mandiant, the average time between a vulnerability's disclosure and its exploitation fell to five days in 2023 (2024). And according to Verizon's 2024 Data Breach Investigations Report, exploitation of vulnerabilities as the starting point of a breach rose 180% over the previous year (2024). A host that patches in an hour and a host that patches in eight days are offering two different levels of risk, even if the plan pages look similar.
How to read your host's reply
A good reply names your sites, gives a date, and explains the method. A weak reply restates the company's security philosophy. Use this table to decide what to do next.
| What support says | What it likely means | Your next step |
|---|---|---|
| "Patched on [date], backported build [identifier], PHP restarted" | Done, and they can prove it | Save the ticket, forward to your IT person |
| "Patched on [date]" with no detail on restart | Probably done | Reply and ask question 4 again |
| "Our servers are always kept up to date" | They don't know, or won't say | Ask for a date per site; escalate if refused |
| "Rolling out over the next several days" | You're exposed until then | Ask about firewall rules, take an offsite backup |
| "Your site is on PHP 8.1, please upgrade" | No fix coming for your branch | Test the upgrade on staging or ask them to do it |
| "You manage PHP on this server" | You're on a VPS or unmanaged plan | Your IT person or a developer patches it now |
That last row surprises people who thought they bought hosting and discover they bought a server. If that's you, the guide to what managed WordPress hosting covers lays out which jobs move to the host on a managed plan.
What to do while you wait for the host to patch
Take a full backup of each site and store it somewhere other than your host, then watch for signs of trouble. You can't patch PHP yourself on a shared or managed plan, so the useful moves are the ones that limit damage if something goes wrong before the fix lands.
Most hosting control panels have a backup or download option. If yours only keeps backups on the same servers, that copy won't help you if the account is compromised or the host has a bigger problem. Our post on what happens when a web host shuts down explains how to keep backups that are yours.
Then keep an eye out for new admin users in WordPress, pages you didn't publish, or redirects to unfamiliar domains. If a site suddenly stops loading, resist the urge to assume the worst. Work through DNS, SSL and suspension checks before assuming a hack, because a lot of outages during a security scare turn out to be unrelated.
If you run sites for clients, this is also a good moment to add a "server patches confirmed" line to whatever you send them each month. A monthly WordPress report for clients that already includes this kind of entry answers the question before the client emails you about a headline.
Shared hosting or managed hosting: who confirms the PHP patch?
On shared hosting, the host patches PHP on its own schedule and you usually have to ask. On a managed WordPress plan, patching PHP is part of what you pay for, and the host should be able to confirm it per site. On an unmanaged server, the job is yours. The price gap reflects who carries that work.
| Setup | Who patches PHP | Typical patch confirmation | Example monthly cost, 3 sites |
|---|---|---|---|
| Shared hosting | Host, staged across fleet | On request, often vague | $30-$60 |
| Managed WordPress | Host, dedicated platform team | Per site, on request or proactive | $267 at $89/mo per site |
| Reseller account | Upstream provider, then reseller | Secondhand | Varies |
| VPS or cloud server | You or your developer | You confirm it to yourself | $15-$60 plus your time |
The math for our three-site company is easy to run. Shared hosting might save around $200-$230 a month compared with a managed plan. Against that, put the owner's time during this one incident: say three to four hours of reading advisories, chatting with support, and chasing a dated answer, at a loaded cost of $75 an hour. That's $225-$300 for a single week, and the PHP project ships security releases several times a year. None of that counts what a successful exploit would cost, which we broke down in our post on the cost of a WordPress security breach.
How TopSyde handles PHP security patches
On our managed WordPress hosting, applying PHP security fixes is our job, and confirming them to you is part of that job. You don't need to know what a backport is. If you want to know which PHP version a site runs and when it was last patched, ask support and you'll get an answer in under 2 hours during business hours. If a site is down, a site-down ticket is answered within 15 minutes, 24/7, as written on our SLA page.
Our stack page lists what runs under your sites, so your IT person can check it against advisories when they're back. Plans start at $89/mo per site, and every plan comes with a 30-day money-back guarantee. If this week's scramble made you want a host that handles the PHP layer and tells you when it's done, see pricing and start there.
Frequently Asked Questions
Can I tell if PHP2Shell is patched just by checking my PHP version?
Not reliably. Many hosts backport security fixes into the existing PHP version, so a patched server can show the same version number as before. Your version tells you which branch you're on; your host has to confirm whether the fix is applied.
Does updating WordPress or my plugins fix PHP2Shell?
No. PHP2Shell is a flaw in PHP itself, which runs on the server underneath WordPress. On shared, managed, and reseller hosting, only the host can patch it.
My site runs PHP 8.1. Am I still covered?
The PHP project ended security support for 8.1 on December 31, 2025, so there's no official fix for that branch. Some hosts maintain their own patched builds of older branches, so ask yours directly. If they don't, plan an upgrade to a supported version and test it on staging first.
How long should a host take to patch a critical PHP flaw?
Reports after PHP2Shell ranged from about an hour at SiteGround to several days for other hosts and plan tiers. According to Mandiant, the average time from disclosure to exploitation was five days in 2023, so a host taking longer than that leaves you exposed past the average. Ask your host for a committed date in writing.
What if my host won't give me a straight answer?
Ask again for a date per site and a description of the method, and escalate to a supervisor if the reply stays generic. Meanwhile, take an offsite backup of every site. A host that can't say whether a critical fix is in place is telling you something about how the next incident will go.
Topics
DevOps & Security Lead
12+ years DevOps, Linux & cloud infrastructure certified
Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.
