Updated 23 October 2026, two days after the PHP security releases.
Only four PHP branches have an official fix for PHP2Shell: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on 21 October 2026. PHP 8.1, 8.0 and 7.4 are end of life and get no official fix. If your website runs on one of them, ask your host for written confirmation of a backported patch, or move to a fixed version. Updating WordPress or its plugins does not close the flaw.
On 21 October the PHP team released emergency fixes for two critical flaws known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Our first article explained what the flaws are and why a Wix website is not exposed. This one answers the question that comes next for owners of PHP websites: is the version my site runs on actually fixed, and what do I do if it is not?
Which PHP versions have a fix?
An official fix exists for four PHP branches only. Anything older has no official patch from the PHP team.
| PHP version | Official fix | What it means for you |
|---|---|---|
| 8.5 | 8.5.12 | Update to 8.5.12 or later |
| 8.4 | 8.4.27 | Update to 8.4.27 or later |
| 8.3 | 8.3.36 | Update to 8.3.36 or later |
| 8.2 | 8.2.35 | Update to 8.2.35 or later. This branch only gets security fixes until 31 December 2026 |
| 8.1, 8.0 and 7.4 | None | End of life. Only minimal source patches exist, meant for people who build PHP themselves |
| 7.3 and older | None | No fix from PHP at all |
If you are on 8.2, the fix helps today, but plan your next upgrade now.
How many websites run a version without a fix?
Counts differ by source, so read these figures as a direction, not a verdict. A scan of internet-facing PHP hosts, reported by CyberAngel, found about 2.24 million hosts. Of the roughly 1.5 million that reveal their version, about 59% run a branch with no official fix. Around 740,000 hosts hide their version, so the real number could be higher. These are hosts, not websites, and some Linux distributions backport fixes into older packages, so not every one of them is exposed.
For WordPress, WordPress.org statistics as reported by The Repository suggest that about 35% of sites run a PHP version that is no longer supported, and about 16% run PHP 7.4.
Why updating WordPress does not fix this
The flaws sit in PHP, the engine underneath your site. They are not in WordPress, your theme or a plugin. Updating WordPress core, themes or plugins changes nothing about that. The fix has to happen at server level: a supported PHP version, or a patch from your host.
Some hosts run older PHP packages that carry backported security fixes. That is why the version number alone does not always tell you whether you are exposed. Only your host can confirm it, and you should ask for the answer in writing.
What the NCSC told UK organisations
The UK National Cyber Security Centre advised organisations to update to a fixed version immediately. If that was not possible, it pointed to the temporary fixes published by the PHP developers. If neither could be done quickly, it said to consider taking the affected systems offline. CERT-EU gave similar guidance.
The effects were visible. The websites of Edinburgh and Oxford councils and the Metropolitan Police were unavailable, and Bristol, Lambeth and Barnet councils showed error messages. As of Wednesday afternoon no successful break-ins had been confirmed, but Cloudflare reported early attacks and security specialists expected attempts to rise once the flaws were public.
How to check which PHP version your website uses
- Ask your host. Send one message: which PHP version does my site run, and has it been patched for CVE-2026-109618 and CVE-2026-109619? Ask for the answer in writing.
- Look in your hosting panel. Most panels show the PHP version for each site.
- Use WordPress Site Health. Open Tools, then Site Health, then Info, then Server.
- Compare it with the table above. 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later is fixed. 8.1, 8.0 and 7.4 are not, unless your host confirms a backported fix.
After you patch: what to check
A patched server can still have been hit before the update. Take a fresh backup before you change anything. After patching, look for these signs:
- Web shells or PHP files you did not upload
- New administrator users you did not create
- Unusual outgoing connections from the server
- Sudden traffic spikes or pages you do not recognise
If anything looks wrong, call your host straight away. UK reporting on the incident also advises businesses to get the server checked for signs of a break-in and to tell their insurer early if something looks wrong.
Your options if you cannot patch
There is no single right answer. This is how the options compare:
| Option | Works best when | Watch out for |
|---|---|---|
| Update PHP yourself or through your host | Your host offers 8.2.35 or later and your plugins support it | Test forms, checkout and login. Old plugins can break on a newer PHP |
| Ask your host for a backported fix | You are stuck on 8.1 or older and cannot upgrade quickly | Get written confirmation of the patched package |
| Firewall (WAF) only | You need a short bridge while you update | It reduces exposure. It does not fix PHP |
| Move to Wix with WE-Optimizz | Business, service or booking website, or a small shop, and nobody wants to run servers | Needs a redirect plan to keep your rankings |
| Starter website from 385-design | Your site is simple, you want a low monthly cost and a site that does not run PHP | 36-month term, and extras cost extra |
One disclosure: we are a Wix partner, so we have a view. Patching is still the better call in many cases, for example for a complex custom application or a team with a host that patches within hours.
Move to Wix with WE-Optimizz
Wix does not support PHP code on sites and runs the servers itself, so there is no PHP runtime for you to patch. WE-Optimizz is a Wix Legends Partner with Wix Design, Wix Development and Wix Accessibility certifications. We have delivered more than 900 websites for clients in over 35 countries.
In a move, the platform matters less than keeping the rankings you built. We inventory your pages, map old URLs to new ones with 301 redirects and carry over titles, headings and structured data. See how our website migration and SEO migration work, or read more about building on Wix Studio.
A low-cost rebuild with 385-design
If your site is simple and you mainly want to stop worrying about servers, 385-design is our starter package. These websites are built on Base44 and do not run PHP, so this flaw does not reach them through PHP. It costs €1 a day (about €30.42 a month, excluding VAT) with no setup fee. It includes up to four custom-designed pages, hosting and maintenance, basic technical SEO and a design that works on mobile and desktop. A webshop, booking system, extra languages, more pages and monthly support are optional extras.
Read the terms before you decide. The term is 36 months from delivery. You can cancel at the end of any month, but the remaining months are then invoiced at once. Tell us which pages bring you traffic and we will plan how to keep them findable.
Key takeaways
- PHP2Shell has an official fix for four branches only: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
- PHP 8.1, 8.0 and 7.4 are end of life and get no official fix. Ask your host about a backported patch.
- Updating WordPress or plugins does not fix PHP. The server has to change.
- Ask your host for the PHP version and the patch status in writing.
- After patching, check for web shells, unknown PHP files, new admin users and unusual outgoing connections.
- If you cannot patch, you can move to a site that does not run PHP: Wix, or a simple Base44 starter site from 385-design. Read the terms of any option first.
Book a free discovery call. We will tell you what your site runs on, what a fix would take and whether a move makes sense for your business. No pressure, no jargon.
Sources
- Insurance Business UK: UK councils and Met Police among sites pulled offline after NCSC alert
- CyberAngel: 2.24M internet-facing PHP hosts, 59% on versions with no fix coming
Written on 23 October 2026. Details about affected versions and exploitation can change. Check php.net for the latest guidance.
Frequently asked questions
Official fixes exist in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. You need one of these versions or later, or a backported patch that your host confirms.