If your business website runs on WordPress or any other PHP-based system, the php2shell exploit is something you need to deal with this week, not next month. According to Search Engine Roundtable, web hosts and site owners around the world are rushing to patch two critical security flaws in PHP, the programming language behind a huge number of websites. Some organizations are even taking their sites offline until the fix is in place, and Google’s John Mueller has weighed in on how to do that without damaging your search rankings.
This post explains, in plain English, what PHP2Shell is, how to figure out whether your site is affected, how to confirm your host has actually patched it, and how to take a site offline safely if you decide to. If you already keep up with WordPress maintenance and security updates, much of this will feel familiar. If you have never thought about what version of PHP your site runs, start here.
What the PHP2Shell Exploit Means for Your Business Website
PHP is the software that runs on your web server and builds your pages every time someone visits. WordPress is written in PHP. So are many other content management systems, contact form scripts, booking tools, and custom-built business sites. Your visitors never see PHP directly, but it is doing the work behind the scenes.
According to the Search Engine Roundtable report, PHP2Shell covers two critical vulnerabilities that can allow unauthenticated remote code execution. That phrase sounds technical, so here is what it means:
- Remote code execution means an attacker can run their own commands on your web server from anywhere on the internet.
- Unauthenticated means they do not need a username, a password, or any access to your site to do it.
The report also mentions memory disclosure, which is when a server leaks information it is holding in memory that should stay private. Put together, the source says these flaws could let attackers run malicious code, crash servers, or steal sensitive data without a login or any action from a user. For a small business, that could mean a defaced homepage, spam pages injected into your site, customer form submissions exposed, or your site being used to attack others.
The report states that all PHP versions from 5.4 through 8.5.11 are vulnerable. The PHP project has released fixed versions:
- PHP 8.2.35
- PHP 8.3.36
- PHP 8.4.27
- PHP 8.5.12
The source also notes that researchers found these flaws using AI models, which prompted the emergency patches. The practical takeaway is simple: the fixes are now out, and everyone is racing to patch before attackers and automated bots start hunting for unpatched sites. Reuters, as quoted in the report, said several government, school and hospital websites in Europe were taken offline as organizations rushed to protect themselves.
Is Your Site Running PHP? A Quick Way to Tell
Before you worry, figure out whether this applies to you. Here is a quick way to sort it out.
You almost certainly run PHP if:
- Your site is built on WordPress (including WooCommerce stores)
- Your site uses another self-hosted system like Joomla or Drupal
- A developer built a custom site for you on a traditional web hosting account
- You log into a hosting control panel to manage your site’s files, email, or databases
You probably do not manage PHP yourself if:
- Your site is on a fully hosted platform like Shopify, Squarespace, or Duda
On fully hosted platforms, you do not control the server software at all. The platform is responsible for its own infrastructure. That does not mean you should ignore the news, but your job is limited to watching for any announcements from the platform. You cannot patch something you do not have access to.
One group people often forget: old and side sites. Many Long Island businesses have a forgotten landing page from a past campaign, an old version of the site on a subdomain, a staging copy a developer left behind, or a separate microsite for an event. If any of those live on PHP, they need the same attention as your main site. An unpatched forgotten site on the same hosting account can be a way in.
How to Confirm Your Host Has Patched PHP2Shell
The report says most sites can be patched without any downtime. On many hosting plans, your host handles PHP updates for you. But "my host probably took care of it" is not the same as knowing. Here is how to check.
Check your PHP version inside WordPress
If you run WordPress, log into your dashboard and go to Tools, then Site Health, then the Info tab. Open the section called Server. You will see a line showing your PHP version. Compare it against the patched versions listed above. If your version number is lower than the patched release in its series (for example, an 8.3 version below 8.3.36), or if it is an older series entirely, you are not on a fixed release.
Check your hosting control panel
Most hosting control panels have a section for selecting or viewing the PHP version, often labeled something like "PHP version" or "PHP manager." The exact wording depends on your host. This is also where you may be able to switch to a newer version yourself, though you should be careful (more on that below).
Ask your host directly, in writing
This is the most reliable step. Send your host a short support message like this:
- Has the server hosting my site been patched for the PHP2Shell vulnerabilities?
- Which PHP version is my site running right now?
- If I am on an older PHP version, what is your plan and timeline for fixing it?
Getting the answer in writing matters. Some hosts apply security fixes in ways where the version number you see does not tell the whole story, so a clear confirmation from the host is better than guessing. If your host cannot give you a straight answer, that tells you something about the host. Our post on shared vs. managed hosting walks through why the level of hands-on support you get from a host matters in moments like this.
A warning about upgrading PHP on an old site
If your site is running a very old PHP version (anything in the 5.x or 7.x range, for example), jumping straight to a current version can break things. Older themes, plugins, or custom code may not work on newer PHP. That is not a reason to stay on a vulnerable version. It is a reason to take a backup first, test on a staging copy if you can, and have someone who knows WordPress on standby. This is exactly the kind of situation where a site that has been neglected for years suddenly becomes urgent.
Patch Live or Go Offline: Making the Call
According to the report, most sites can be patched without taking anything down. For a typical small business on a decent host, the best case is that the host updates PHP, you confirm it, and your customers never notice.
But the report also notes that many sites are going offline until patches are in place, just to be extra careful. You might consider that route if:
- Your host has not patched yet and cannot tell you when they will
- Your site handles sensitive customer information through forms, logins, or payments
- Your site runs an old PHP version and upgrading will take real work to avoid breaking it
- You suspect your site may already have been tampered with
Taking a site offline is a business decision. For a law firm, medical practice, or any business collecting personal information through its site, a few hours offline may be a small price for peace of mind. For a restaurant whose site is mostly a menu and a phone number, the risk calculation may look different. Either way, if you do take the site down, how you do it matters a lot for Google.
How to Take a Site Offline Without Hurting Google Rankings
This is where John Mueller’s advice comes in. According to the report, he posted this on Bluesky:
"If you’re taking PHP sites down to schedule time to deal with "unplanned updates", use HTTP 503 instead of letting responses time out / 404 / 500. You can do this outside of PHP / point DNS elsewhere / CDN."
That is a lot packed into two sentences. Here is what each part means for you.
Why a 503 code protects your rankings
Every time a browser or Google’s crawler requests a page, your server sends back a status code, a short number that says what happened. You never see most of them, but Google pays close attention.
- 503 (Service Unavailable) tells Google: "We are temporarily down. Come back later." Google understands this as a short pause and generally holds off on dropping your pages.
- 404 (Not Found) tells Google the page does not exist. If Google sees this across your site, it may start removing pages from search results.
- 500 (Internal Server Error) tells Google something is broken on your end. It does not clearly signal that the outage is planned or temporary.
- Timeouts happen when the server does not respond at all. To Google, that looks like an unreliable site.
In other words, if you simply switch your site off or let it break, Google may read that as "this site is gone or broken." A 503 tells Google "this is temporary," which is what you want. Google also has official documentation on how to temporarily pause or disable a website if you want to read more.
Why it should happen outside of PHP
This is the part that is easy to miss. Many WordPress owners would reach for a maintenance-mode plugin to put up a "we’ll be right back" page. The problem is that a WordPress plugin runs inside WordPress, which runs on PHP. If the reason you are going offline is that PHP itself is vulnerable, a plugin-based maintenance page still has the vulnerable software answering every request.
That is why Mueller points to options that do not rely on PHP at all:
- A CDN (content delivery network). A CDN is a service that sits in front of your website and delivers it to visitors. Many CDNs let you show a maintenance page with a 503 code at their level, so requests never reach your PHP server.
- Pointing DNS elsewhere. DNS is the system that connects your domain name to your server. You can temporarily point your domain to a different, simple server that just returns a 503 maintenance page.
- Server-level settings. Your host or developer may be able to return a 503 at the web server level, before PHP is ever involved.
If none of those sound like something you can do yourself, that is normal. This is a quick job for your host or web developer, but it is worth asking for it specifically so you do not end up with a plugin-based page or, worse, a site that just shows an error.
Keep the downtime short
The report links to earlier Search Engine Roundtable coverage on this topic, including Google’s position that a 503 is meant for hours, not weeks, and that sites down for too long can see their rankings suffer or drop out of Google’s index. That same earlier coverage notes Google’s suggestion to put up a static version of the site if it will be offline for longer than a day.
For a small business, a static version can be as simple as a single page with your name, phone number, address, hours, and a short note that the full site will be back soon. It keeps customers able to reach you while the real work happens behind the scenes. The report also points out that Google gave similar advice in 2021 during the Log4j security vulnerability, so this is a consistent, long-standing approach rather than a one-off tip.
Keeping Customers in the Loop While Your Site Is Down
Google is only part of the picture. Real customers will try to reach you while your site is offline. A few simple steps keep that from costing you business:
- Make sure your Google Business Profile is accurate. Your phone number, hours, and address show up in Google Search and Maps even when your website is down. If you want help keeping it current, that is part of our Google Business Profile management work.
- Put your phone number on the maintenance page. A 503 page does not have to be blank. A short, friendly message with a way to contact you is ideal.
- Let your team know. Whoever answers the phone should know the site is temporarily down so they are not surprised when a customer mentions it.
- Pause ads that point to your site. If you are running paid ads that send people to your website, pause them while it is offline so you are not paying for clicks that land on a maintenance page.
After the Patch: A Short Cleanup Checklist
Once your host confirms the fix and your site is back online, take a few extra minutes to make sure nothing slipped through while the vulnerability was open:
- Confirm the PHP version again. Check Site Health in WordPress or your hosting panel to make sure you are on a patched release.
- Test the site like a customer would. Load your homepage, key service pages, contact forms, and any checkout or booking pages. Submit a test form and make sure it arrives.
- Confirm the 503 is gone. If you used a CDN or DNS change, make sure it has been reversed and your real pages are being served normally.
- Update WordPress, themes, and plugins. While you are in there, bring everything else current. Outdated plugins are their own security risk.
- Change important passwords. If there is any chance your site was exposed, update passwords for WordPress admin accounts, hosting, and databases.
- Check Google Search Console. Look at the Security issues report and the Pages report for anything unusual, like pages you did not create or a sudden drop in indexed pages.
- Make sure you have a recent backup. If you do not have a working backup system, set one up now. The next emergency is a lot less stressful when you can roll back.
If you want a broader look at how security and rankings connect, our post on why HTTPS and site security affect your rankings is a good next read.
Your Next Step This Week
You do not need to become a server expert to handle this. You need three answers: Does my site run on PHP? Has my host confirmed in writing that it is patched? And if I need to go offline, do I have a plan to return a 503 from outside PHP and keep the downtime short? Spend 15 minutes today checking your PHP version and sending that support message to your host. That alone puts you ahead of a lot of businesses.
If you are not sure who manages your site’s server, or your host is not giving you clear answers, it may be time for hosting that comes with real support. If you would like a second set of eyes on your site, reach out to MJW Media and we will help you figure out where you stand.
Frequently Asked Questions
What is the PHP2Shell exploit in simple terms?
PHP2Shell is the name for two critical security flaws in PHP, the programming language that powers WordPress and many other websites. According to Search Engine Roundtable, the flaws can let an attacker run their own code on a web server without logging in. That could lead to a hacked site, a crashed server, or stolen data.
Does PHP2Shell affect my Shopify, Squarespace, or Duda website?
On fully hosted platforms like Shopify, Squarespace, and Duda, you do not manage the server software, so there is nothing for you to patch yourself. The platform is responsible for its own infrastructure. Keep an eye out for any announcements from the platform, and check whether you have any other sites, like an old WordPress landing page, that do run on PHP.
How do I check which PHP version my WordPress site uses?
Log into your WordPress dashboard and go to Tools, then Site Health, then the Info tab, and open the Server section. Your PHP version is listed there. The patched releases named in the report are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. To be certain, also ask your host to confirm in writing that your server is patched.
Will taking my website offline hurt my Google rankings?
It can if you do it the wrong way. Google’s John Mueller advises returning an HTTP 503 status code, which tells Google the outage is temporary, instead of letting the site time out or show 404 or 500 errors. Keep the downtime short, ideally hours rather than weeks, and consider a simple static page if you will be down longer than a day.
Can I just use a WordPress maintenance mode plugin while I wait for the patch?
That is not ideal for this situation. A maintenance plugin runs inside WordPress, which runs on PHP, so the vulnerable software is still handling requests. Mueller suggests setting up the 503 outside of PHP, such as through a CDN, by pointing DNS to another server, or with your host’s help at the server level.
