Should I take my site offline?
If you can't update PHP, and can't apply the temporary fixes either, national cyber security agencies advise taking the site offline, or cutting it off from the public internet, until it's fixed.
What the advisories say
Government agencies in the US, UK and EU set out the same order of steps:
- Update PHP, starting with sites and servers reachable from the internet.
- If you can't update straight away, apply the PHP project's temporary measures, or ask your host to. A firewall service in front may give some protection meanwhile.
- If you can't do either, or it would take too long, take the site offline or isolate it from the public internet until it's fixed. That includes any site on PHP 8.1 or older, unless its host or vendor has added the fix, because those versions have no official update.
- Check for signs of compromise before you update or bring the site back, because attackers may already have got in.
- CISA (US) advises taking PHP-based systems offline until patched if you can't update immediately, or if you run PHP 8.1 or earlier.
- The NSA (US) recommends taking the system offline until it can be fully mitigated, if an immediate update isn't feasible.
- The UK NCSC says that if the temporary measures can't be applied, or would take too long, you should consider taking the system offline until it's fully mitigated, and check it for signs of compromise first.
- The EU joint statement from the European Commission, ENISA, CERT-EU and Europol advises considering isolating exposed applications from public networks until fixes are applied.
- Ireland's NCSC advises patching internet-facing systems first, and isolating end-of-life PHP if mitigations can't be applied.
In practice: if your host can give you a firm, short timeline for the update, the temporary measures and a firewall service may tide you over. If not, and especially if the site takes payments, has logins or holds personal data, taking it offline for a day or two is the safer choice.
Why maintenance mode isn't enough
WordPress maintenance-mode and “coming soon” plugins show visitors a holding page, but every request still goes through PHP first. A PHP2Shell attack can be triggered before WordPress or any plugin runs, so the server is just as exposed. To actually protect it, requests must be stopped before they reach PHP.
How to take it offline properly
If your site is on Cloudflare
Block traffic at Cloudflare, so requests never reach your server. In your domain's dashboard, go to Security, then Security rules, and create a custom rule:
- Match:
(not ip.src in {your.ip.address}), so you can still get in. - Action: Block.
This only works if your server accepts traffic from Cloudflare alone. If attackers can find your server's real IP address, they can go around Cloudflare. Ask your host or developer if you're not sure.
On shared hosting (Apache or LiteSpeed)
Your host can suspend the site for you, which is the simplest option. To do it yourself, put a plain HTML page called maintenance.html in the site's main folder, then add these lines to the very top of the .htaccess file there. Keep a copy of the original file to put back.
ErrorDocument 503 /maintenance.html
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ - [R=503,L]Every request then gets your holding page from the web server, without PHP running. The 503 status tells search engines the site is down for a short time, so it won't lose its place in search results. Check by visiting a page that normally runs PHP, such as /wp-login.php. You should see the holding page.
On your own server
Point the site at a static holding page in your web server configuration, returning a 503, and stop the PHP-FPM services for that site. With mod_php, disable PHP for the site or stop Apache. Restart PHP once it's patched, as described in the server guide.
While it's offline
- Say what's happening. Put a short message and a phone number or email address on the holding page, so customers can still reach you.
- Get the fix in. Use the email in the hosting guide to push your host for a date, or follow the server guide.
- Check before you switch back on. Confirm the PHP version is fixed, then run through the compromise checks, because the site may have been attacked before you took it down.