70% of the internet open to hackers. How to keep your business website maintained

On Wednesday 21 October, governments in Belgium, the Netherlands, Finland, France and Germany switched off some of their own websites, and Edinburgh, Bristol and Oxford councils did the same. They were protecting themselves from PHP2Shell, two flaws in PHP, the software that runs WordPress and most of the web: W3Techs finds PHP on about 7 in 10 sites where it can detect the server language. A crafted request, with no password, can let a stranger run their own code on the server behind a website. If your business site went offline this week, your host emailed you about emergency maintenance, or you have been reading the news and wondering about your own site, this guide is for you: what to do today, how to tell whether anyone got in, and how to keep your website maintained so the next warning finds someone already on it.

TL;DR: PHP2Shell lets an attacker run code on an unpatched PHP server with a crafted request and no login. Updating WordPress does not fix it: whoever runs your server must install PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 and restart it. Then check for intruders, and give one engineer the standing job of keeping the whole site updated.

What is PHP2Shell, in plain words?

PHP2Shell is the nickname for two flaws in PHP itself, each rated 9.2 out of 10 (critical) on CVSS, the industry's standard severity score, that let someone with no account run their own code on a web server. PHP is the software on your hosting server that turns a WordPress or WooCommerce site into the pages visitors see. The flaws were reported to PHP in August by OpenAI and the security firms Calif and Wiz, and the affected code goes back to PHP 5.4, released in 2012, so almost every PHP version still running carries it.

What an attacker does next depends on what your site holds. Malwarebytes lists stealing the site's data, changing what visitors see and leaving a back door to return through later. Wiz also showed that attackers can read passwords and access keys straight out of the server's memory. For a clinic or a law firm, that puts the enquiries your contact form has stored within reach, along with the keys your site uses to send email in your name or to connect to your booking tool. The US National Security Agency warned that the flaw could "provide a direct path to the server's file system or database".

My website went down or my host emailed me. What do I do now?

Start by finding out who runs PHP for your site, because that person installs the fix and you can't. If a freelancer set the site up years ago, look for who you pay for hosting: the invoice or card charge, or the renewal emails for your domain and hosting. On shared or managed hosting, the hosting company runs PHP. On a server of your own (a "VPS" at a cloud provider), you or your developer do, and no host is coming to do it for you. If you can't find any of it, that is the first thing to fix this week.

A site that went offline this week has not necessarily been hacked. Malwarebytes points out that downtime alone doesn't mean a breach: many hosts and owners took sites down on purpose while they patched, which is what the NSA and the UK's National Cyber Security Centre advised for anyone who couldn't update quickly.

Then send whoever runs PHP one message: "Has our server been updated to a PHP version that fixes CVE-2026-109618 and CVE-2026-109619, and has PHP been restarted? Please confirm in writing." Those two codes are the official reference numbers for PHP2Shell. Ask for "installed". A reply that says "scheduled" or "protected" can mean temporary settings (switching off the PHP features the known attacks use), and CERT-EU, the EU institutions' cyber security team, is blunt that those "do not make an installation safe".

You can also look yourself. In WordPress, open Tools, then Site Health, then Info, and expand Server. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. A lower number on the same line usually means the fix is missing, but some hosts show only "8.4" and some servers patch PHP without changing the number at all, so the host's written answer settles it.

While you wait, keep customers able to reach you: your phone number and email on your Google Business Profile and social profiles. If the site has to stay down, ask your host for a maintenance page set up on the server itself. A WordPress maintenance-mode plugin isn't enough, because PHP still reads every request before any plugin runs.

Why your host may not have fixed it yet

The PHP2Shell fix was published on 21 October, but on a small-business site it has to pass through several hands, and it can stall at each one. Even PHP's own team struggled: the PHP Foundation, which funds PHP's security work, says it saw the first signs of the underlying memory problem in a 2024 audit, found no way to exploit it then, and stalled because every fix it designed risked "breaking compatibility, hurting performance". For your site, these are the places it can stall, and what to ask about each:

1. The copy of PHP your host uses. Most hosts don't download PHP directly. They wait for the company behind their server software to build a patched copy, and some of those builds were still rolling out hours after the release. Ask: "Is the patched build installed on our server?"
2. The host's schedule. Each host updates its servers in its own order, often with temporary settings first. Ask: "Is ours done, or only protected?"
3. The restart. PHP keeps running the old code until it is restarted, even with the new version already installed. Ask: "Has PHP been restarted since the update?"
4. Old versions. PHP 8.1 and older got no official fix, only source code for people who build PHP themselves, and PHP 7.3 and older got nothing. Some hosts built patched copies of 7.4 to 8.1 for their customers and some didn't. Ask: "Which version are we on, and what will it take to move to 8.3 or newer?"
5. Firewalls. Cloudflare, a service many websites sit behind, and other providers added rules that block the known attacks, but only for traffic that passes through them. Ask: "Is the update installed as well as the firewall rule?"

Was my website hacked through PHP2Shell?

It might have been if it was online on an unpatched PHP from the morning of 21 October. Coalition, a cyber insurer that runs decoy servers across the internet, logged the first exploit-related requests at 09:00 Lisbon time, more than five hours before PHP released its fix, because details had leaked the day before. A patch closes the hole and does nothing about whatever came through it first. The UK's National Cyber Security Centre tells organisations to look for "backdoors installed by an attacker".

The attack happens below WordPress, so the site's own logs may show very little. Ask your host or developer to check for the signs Coalition and Wiz have published, and to do the clean-up that follows:

• administrator accounts you didn't create, in WordPress under Users;
• new or changed files in the website's folders, and new scheduled tasks or user accounts on the server;
• file uploads followed by memory errors or a run of server errors in the logs;
• PHP crashing or restarting with no clear reason;
• once the fix is in, new admin passwords and new access keys for every service the site connects to, such as email sending, booking and payments.

Why keeping your website updated matters after PHP2Shell

Between 13:00 and 14:00 Lisbon time on 21 October, the hour before the fix was published, Coalition saw requests for pages that reveal a server's exact PHP version jump to 3,839, against about 100 in a normal hour. Attackers were sorting servers by version to pick their targets while most owners hadn't yet heard of PHP2Shell.

Sites that nobody looks after stay exposed long after the news moves on. Professor Alan Woodward of the University of Surrey told the Guardian to expect "a long tail of websites who may not be maintained as well", and with them "weeks and months of ongoing attacks". A site that was built, handed over and never touched since sits in that tail.

Old versions also stop getting fixes on a date you can look up. PHP 8.2 has the PHP2Shell fix, but PHP stops security fixes for 8.2 after 31 December 2026, about ten weeks away. If an old theme or plugin only runs on an old PHP, the security update becomes a rebuild, and a quiet month is a better time to find that out than the next emergency.

Security warnings for PHP are also arriving faster. The PHP security team has published 15 security advisories since 1 July, and the PHP Foundation warns that tools now "find bugs faster than ever, for defenders and attackers alike".

What does website maintenance actually cover?

Website maintenance is the standing job of keeping every layer of the site current and being able to prove it, and PHP2Shell touched almost every part of that job in a single week. This is what it covers, with what each part meant this time:

• The server software. Installing a fix like PHP 8.3.36 within hours of a critical warning, restarting it and confirming the version in writing.
• WordPress, the theme and plugins. Updating them on a test copy of the site first, then checking every form and checkout, because an old plugin is often what blocks the move to a newer PHP.
• Support dates. Knowing that PHP 8.2 loses security fixes after 31 December and planning the move months ahead.
• Backups. Keeping a recent copy of the site and its data, and restoring one now and then, so you could recover if the compromise check finds something.
• Checks after an incident. Looking for new admin accounts and changed files, and changing passwords and access keys once the fix is in.
• A written record. What the site runs on, where it is hosted and who holds each login, so nobody spends an emergency searching old emails.

Questions to ask whoever looks after your website

• On 21 October, when was the PHP2Shell fix installed on our server, and can you show me?
• Which PHP version does our site run today, and when does its support end?
• Who restarts the server after an update, and who checks the site still works?
• When did you last restore one of our backups?
• If you were unavailable next week, who would act on the next warning?

Why a senior engineer should own your website's maintenance

A warning like PHP2Shell is a technical document, and acting on it is mostly judgement: which layer of the site it hits, whether a host's "protected" means fixed, whether the upgrade will break the booking form, whether the site should go offline tonight. An engineer who built the site and is paid to keep it already knows what it runs on, so the decisions can be made the same day. A small business doesn't need that person full time, only one person with the job and their name on it.

SharpHaw is a Lisbon agency that builds websites for European businesses and keeps them running, and the person who builds your website is the one who maintains it. Gabriel Espinheira, our founder, spent 12+ years as a software engineer inside large product companies in Europe and Brazil, and he leads the engineering on every site we build and maintain. sharphaw.com and the sites we build as Conversion-First Websites run on Next.js, a different web framework, hosted on Vercel, so PHP2Shell had no PHP to reach. That stack has its own incidents: in December 2025 a flaw called React2Shell, scored 10.0, hit Next.js, and the hosting company's firewall rules helped but upgrading was the only complete fix. Whatever a site runs on, someone has to install the fix.

On sharphaw.com there is no admin login on the public site to attack, browsers are told to connect only over a secure connection, and no analytics, ad tracking or session recording loads until a visitor accepts cookies.

If your WordPress site works and you have a developer who answers the questions above, keep them. If nobody answered this week, Foundation, our plan for the website alone, is a rebuild: a new site that Gabriel builds and then keeps updated, with the upkeep included in the monthly fee on every plan. One person is the trade. You get the senior engineer directly, and you carry the risk of a single supplier.

Frequently asked questions

Will a security plugin protect my site from PHP2Shell?

No. PHP reads each request before WordPress or any plugin runs, and on some common server setups a single request can trigger the attack before your site's own code starts. The plugin never sees it. Only an updated PHP, installed and restarted by whoever runs your server, closes the hole.

Should I take my website offline until PHP is patched?

The UK's National Cyber Security Centre says to consider it if you can't update or apply the temporary settings quickly. A maintenance-mode plugin is not enough, because PHP still handles every request. Ask your host to take the site down on the server and show a temporary maintenance page that tells Google the site will be back.

Does a website that doesn't use PHP still need maintenance?

Yes. A site built on another stack avoids PHP2Shell but has its own flaws to patch: React2Shell hit Next.js in December 2025, and the only complete fix was upgrading. Every website needs someone who installs fixes, checks the site afterwards and knows when its versions stop getting security support.

Who should own your website before the next warning

If PHP2Shell caught your business out this week, look at who owned your website on 21 October. A site with an owner still had to wait for its host's patch, but someone asked the right questions that day, applied the temporary settings or took it offline, and checked for intruders afterwards. A site without one waited, unwatched. Before PHP's next emergency release, put one named engineer in charge: someone who knows what your site runs on, installs the fix the day it ships and can show you it is done. If you would rather have the engineer who builds your site keep it updated, see how Foundation works.