If your site runs on PHP, a good host patched PHP2Shell before most people had even heard the name. The two critical remote-code-execution bugs disclosed in October 2026 were fixed under embargo, which means responsible hosts rolled out the update across their fleet in the quiet days before public disclosure. Your job now is not to patch anything yourself — it's to confirm the work was done and that your own site is running a safe version.
You can check all of this in about ten minutes without touching a single line of code. Below is a checklist any site owner can follow: read your PHP version, confirm the patch, and understand why you might have seen a short burst of 503 errors during the rollout.
If you host with TPC and you're wondering whether you need to do anything: no. The fix went out before disclosure. This post exists so you can verify that for yourself — a healthy instinct, and one worth having with every host you use.
What PHP2Shell actually is, in plain terms
PHP2Shell is the nickname for two critical remote-code-execution flaws in PHP itself, disclosed in October 2026, that let an attacker run their own commands on a vulnerable server. That's the worst class of bug there is — not a data leak, not a defacement, but the ability to run code on the machine your site lives on.
Because these were found in PHP core, they affect everything built on PHP: WordPress, WooCommerce, Laravel apps, Drupal, custom sites — all of it. The flaw doesn't care which CMS you run. It lives a layer underneath, in the language. That's why the fix is a PHP version bump, not a plugin update.
The PHP project shipped patched releases across the supported branches and coordinated disclosure with hosting providers under embargo. The practical upshot for you: whether you were exposed depends almost entirely on how fast your host moved, and whether your site is pinned to a PHP version that actually received the fix.
How to check your PHP version without code
Open your hosting control panel and look at the PHP version setting for your site — that single number tells you most of what you need to know. In cPanel it's under Select PHP Version or MultiPHP Manager. In most other panels it sits under the domain or website settings as a simple dropdown.
You want to be on a supported, patched branch. As a rule of thumb after PHP2Shell:
- PHP 8.3 / 8.2 / 8.1 — supported branches that received the security release. Make sure your minor version is at or above the patched build your host announced.
- PHP 8.0 and older — end of life. These branches may not get a backported fix at all. If you're here, upgrading is the fix, and it's overdue regardless of PHP2Shell.
If you'd rather not log into a panel, a WordPress site shows its PHP version under Tools → Site Health → Info → Server. That reads the live version the site is actually using, which is the number that matters — not what's installed somewhere on the box, but what your site runs.
How to confirm your host applied the patch
Match the patched PHP build number your host announced against the version your site reports — if yours is equal or higher, you're covered. The version number alone doesn't always reveal the patch, because some hosts backport security fixes without changing the public minor version, so the cleanest confirmation is a direct answer from the host.
Here's the order I'd work through:
- Find the announcement. Check your host's status page, blog, or email for an October 2026 security notice mentioning PHP2Shell or the CVE numbers. A host that patched will usually say so plainly.
- Compare build numbers. If the notice names a patched PHP build, compare it to what your Site Health panel reports.
- Ask directly if it's unclear. A one-line question — "Did you apply the PHP2Shell security release, and on which PHP branches?" — should get a straight answer. If it doesn't, that tells you something too.
This is exactly the kind of question where talking to a human helps. With TPC you can ask on chat at any hour and get an immediate answer from the AI, with a real engineer following up during business hours if you need specifics about your account. "Are we patched?" should never leave you guessing for days.
Why you may have seen 503 errors — and what Google said
A short burst of 503 "Service Unavailable" responses during a security patch is normal and, handled correctly, harmless to your search rankings. When a host restarts PHP-FPM or swaps the PHP binary across a server, requests in flight can briefly fail. That's the trade for getting patched quickly.
Google's guidance on this is consistent and worth internalising: a 503 status code tells crawlers "come back later" rather than "this page is gone." That's the response you want during planned maintenance. Googlebot will back off and retry, and brief 503s over a short window don't cause pages to drop from the index. The thing that does hurt you is a maintenance window that returns a 200 with an error page, or a 404, or 503s that drag on for days.
So if you glanced at your logs and saw a scatter of 503s on the patch date, that's the system working as intended. What to actually check:
- The 503s were short-lived — minutes to an hour, not days.
- Your site now returns 200 on its key pages. Test the homepage and a couple of product or post URLs.
- Search Console → Pages shows no spike in "Server error (5xx)" that persists after the patch window.
If everything's green now, there's nothing to fix. If you're still seeing 5xx days later, that's not PHP2Shell — that's a separate problem worth raising with your host.
Your ten-minute verification checklist
Run through this list once and you'll know exactly where you stand. None of it requires editing files or running commands.
| Step | Where to look | What good looks like |
|---|---|---|
| Read your PHP version | Control panel or WP Site Health | 8.1+ on a supported branch |
| Find the patch notice | Host status page / email | Oct 2026 PHP2Shell notice present |
| Confirm the build | Compare notice vs your version | Yours ≥ patched build |
| Check for lingering 5xx | Search Console → Pages | No ongoing 5xx spike |
| Spot-test live pages | Visit homepage + 2 URLs | All return 200 |
| Review your plugins/apps | WP dashboard / app updates | Everything current |
One extra thing worth doing while you're in there: update your plugins, themes and app dependencies. PHP2Shell is a core bug, but attackers lean hardest on sites that are behind everywhere at once. A patched PHP on a site running six-month-old plugins is still a soft target.
If this whole exercise made you realise you're on an end-of-life PHP version or a host that went quiet when you asked a direct security question, that's a signal. Migrating is less painful than most people expect — TPC runs on EU servers, is GDPR-friendly, handles the migration for you, and gives you 30 days to back out if it isn't right. You shouldn't have to chase your host to find out whether your site is safe.
Verify once, fix anything that's off, and get back to your actual work.
FAQ
Do I need to patch PHP myself after PHP2Shell?
No — on managed shared hosting, patching PHP is your host's job, not yours. Your task is to confirm they did it and that your site is pinned to a patched version. If you run your own VPS with root access, you're responsible for applying the PHP security release yourself.
How do I know which PHP version is safe?
Stay on a supported branch — PHP 8.1, 8.2 or 8.3 — at or above the patched build your host announced for PHP2Shell. Anything on PHP 8.0 or older is end of life and may never receive the fix, so upgrading is the only real remedy there.
Will the 503 errors during patching hurt my Google rankings?
No, short-lived 503 errors during maintenance do not harm rankings. Google treats a 503 as a temporary 'retry later' signal and crawlers back off without dropping your pages. The risk only appears if 5xx errors persist for days or if maintenance returns a 200 or 404 instead.
How can I check my PHP version without using a control panel?
In WordPress, go to Tools → Site Health → Info → Server, which reports the exact PHP version your site is running. This reads the live version in use, which is the number that actually matters for whether you're covered.
What if my host won't confirm whether they patched?
A host that can't or won't give you a straight yes to 'Did you apply the PHP2Shell security release?' is a warning sign worth acting on. Responsible providers publish a notice and answer directly; vague or delayed responses on a critical RCE fix are reason to consider moving.
