Old PHP version on your website? No update is coming for it

PHP2Shell is the name for two flaws in PHP, the software on your hosting server that turns a WordPress site into the pages your visitors see. With them, a stranger can run their own code on that server without a password: read the enquiries and bookings it stores, or plant a fake "browser update" that infects your visitors. A week after the fix was released, about 1.9 million websites across the EU, Switzerland and Liechtenstein still showed a vulnerable PHP version, according to a study by the Vienna security firm risikomonitor.com and EY Austria. For 80.9% of them, the PHP project has no update to send, because their PHP version stopped receiving fixes years ago. If your site was built a few years ago and nobody has looked at its server since, here is how to find out which version you run and what moving it involves.

TL;DR: Most websites still exposed to PHP2Shell run a PHP version that gets no more fixes, so no update will arrive. PHP 7.4, 8.0 and 8.1 need moving to a supported version, tested on a copy first. Aim for PHP 8.4 or 8.5: PHP 8.2, the oldest patched version, loses security support on 31 December 2026.

Is my website's PHP version still supported?

A PHP version is supported for four years: two years of normal fixes, then two years of critical security fixes only, according to php.net. After that, the version is end of life, and new flaws found in PHP are fixed only in the newer versions. Here is where each version stands on 31 October 2026:

• PHP 7.4: end of life since 28 November 2022.
• PHP 8.0: end of life since 26 November 2023.
• PHP 8.1: end of life since 31 December 2025.
• PHP 8.2: security fixes until 31 December 2026, two months from now.
• PHP 8.3: security fixes until 31 December 2027.
• PHP 8.4: security fixes until 31 December 2028.
• PHP 8.5: security fixes until 31 December 2029.

The PHP2Shell fixes shipped on 21 October as 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Nothing shipped for 7.4, 8.0 or 8.1. On 26 October CISA, the US government's cyber security agency, added both flaws to its catalogue of vulnerabilities that attackers are already exploiting.

Why are 1.9 million European websites still exposed?

The study by risikomonitor.com and EY Austria checked 34.9 million reachable websites. On the day the flaws became public, 3.9 million of them (11.2%) showed a vulnerable PHP version. Within days that fell to 5.6%, mostly because large hosting companies that manage PHP for their customers updated everyone at once: 15 providers account for 60% of the vulnerable sites, and where a host runs PHP centrally, its customers were protected without doing anything.

After that first wave, progress slowed: of the affected sites the researchers checked again, only 18.1% had patched by 28 October. The version numbers explain why. PHP 7.4.33 is the most common vulnerable version in Europe, on 433,064 websites, and on average the still-vulnerable servers have waited 4.7 years for an update. About 328,000 sites, on even older versions, have gone more than seven years without a security fix.

Where the study could assign an industry, hospitality, retail, transport and restaurants make up almost half. In Austria, hotels and guesthouses came first, then medical practices and car repair shops: small businesses whose website was built by someone else and that have no IT person of their own.

Portugal had the highest share of vulnerable websites in the study, 14.4%, against a European average of 5.6%. Germany had the most in absolute terms, 426,854, and the slowest patch rate, 5.8%.

Why can't my host just update PHP 7.4?

Updating means installing a newer release of the version you already run, and for PHP 7.4, 8.0 and 8.1 the PHP project published none. It shared only raw code fixes for those versions, which someone has to build into PHP by hand. Its release notice is blunt: "There are no complete mitigations, updating is the only safe choice."

A few hosts do build that fix into their old PHP and keep the old version number, and others have said they won't: the tracker at php2shellcheck lists which server systems got a fix, which got it only on a paid plan, and which got none. So a host that says your PHP 7.4 server "is patched" can be right. Ask them who made the patch, which flaws it covers and until when, in writing.

Even with that fix built in, an old version keeps everything else that was never fixed. The study counts an average of 72 known PHP vulnerabilities open on each vulnerable server, 22 of them critical. Manuel Löw-Beer, who runs risikomonitor.com, put it plainly: "Anyone still running PHP 7 or older does not need an update but a migration to a current version. That should happen now, not at the next incident."

Your host can install an update for you. A migration needs someone to check every plugin, theme and form against the new version on a copy of your site first, and on a site nobody looks after, nobody is given that job. That is how a server stays on PHP 7.4 for four years.

How do I check which PHP version my site runs?

On a WordPress site, the PHP version is in the dashboard: open Tools, then Site Health, then Info, and expand the Server section. Your hosting control panel usually shows it too, under a heading like PHP settings or PHP version. The study's authors also offer a free check at php.risikomonitor.com.

The number alone doesn't settle it. Some servers hide their version, and a host that built the fix into old PHP still shows the old number, so the study (which could only read the version servers show the public) may count some of those as vulnerable. If your host manages PHP for you on shared hosting, you may already be on a fixed version.

To know for sure, send whoever runs your hosting this question: "Which PHP version does our site run, does it receive security fixes, and until what date?" You want a version and a date back. "It's fine" answers neither.

If you can't find who runs your hosting at all, look for the invoices or card charges for your domain and hosting. Until you know that name, nobody can move your site.

What does moving to a supported PHP version involve?

For a small business site, nearly all of the work happens on a copy, before anyone touches the live site:

1. Back up the whole site, files and database, and confirm the backup restores.
2. Make a copy of the site on the same kind of server and switch the copy to the new PHP version.
3. Update WordPress, the theme and every plugin on the copy. Plugins state the oldest PHP they support, and WordPress won't install an update that needs a newer PHP than your server runs, so a site stuck on 7.4 is often stuck on old plugins too.
4. Test what earns you money on the copy. For a guesthouse that means the booking widget and its availability calendar, the contact form (send a real enquiry and check it arrives), each language version and the photo gallery. Replace any plugin that breaks and has no update.
5. Switch the live site at a quiet time, with a way back, and watch the error logs and your enquiries for a few days.

Pick the target version with its end date in mind. WordPress recommends PHP 8.3 or newer, and 8.3 is supported until 31 December 2027. PHP 8.4 or 8.5 buys one or two more years before you do this again.

The mistake to avoid

Moving to PHP 8.2 because it is the smallest jump puts you back on an unsupported version on 31 December, two months from now. Waiting for your host to decide is the other trap: hosts retire old versions on their own timetable, and a site switched overnight without a test on a copy can break with nobody watching.

We're SharpHaw, a Lisbon studio that builds websites and keeps them running. On sites we host, keeping PHP on a supported version is part of the upkeep in our Conversion-First Websites service, on every plan. Read the plans and fees, or tell us about your site.