Stay informed with the latest IT tips
Cybersecurity advice and exclusive resources from the Andisa team, straight to your inbox.
Is my website affected by the PHP security flaw (PHP2Shell)? A plain-English guide for UK businesses
By Andy Morrison, founder of Andisa IT · Published 03/11/26 · Last updated 3rd November 2026
If your website runs on WordPress, or on anything else built with PHP, treat it as affected until the company that hosts it confirms the fix is in place. On 21 October 2026 the National Cyber Security Centre (NCSC) warned UK organisations about two critical flaws in PHP, known in the industry as PHP2Shell. The fix was released the same day. It goes on PHP itself, on the server, so for most businesses it is the hosting company’s job rather than yours. By 27 October the US cyber agency CISA had confirmed attackers are using the flaws for real.
This guide tells you how to find out where you stand, what to ask your host, and what to do if the answer is not good enough. We have written it for the kind of businesses we support: owner-managed firms with a website somebody else built, and nobody in-house whose job it is to think about PHP.
The short version
1
Find out who looks after your website’s server. Usually that is your hosting company or the agency that built the site.
2
Ask them two questions: which version of PHP the site runs on, and whether the fixes for CVE-2026-109618 and CVE-2026-109619 have been applied. Ask for a version number and a date, in writing.
3
If you cannot get a clear answer within a day, read on. The rest of this guide covers how to check for yourself, what the options are if the site is on an old version, and what to do if you think someone has already got in.
Updating WordPress, your theme or your plugins will not fix this. Neither will a WordPress security plugin. More on why below.
What we know, and what we don’t (last checked 27 October 2026)
We will keep this section updated while the story moves.
What we know
- The two flaws are in PHP itself, not in WordPress or any particular website. They are tracked as CVE-2026-109618 (PHP mishandles running out of memory) and CVE-2026-109619 (leftover data from one web request can be reused by the next). Both are rated critical, 9.2 out of 10.
- Under the right conditions they let an attacker run their own commands on a web server without logging in. That is as serious as a web flaw gets.
- The PHP project released fixes on 21 October in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older versions got no official release, though many hosts and Linux vendors have patched them themselves. See the table further down.
- The NCSC alert, also 21 October, says any version of PHP is affected and sets out six steps: find every system running PHP, update, apply temporary workarounds where you cannot, consider taking systems offline, check for backdoors, and watch for updates from suppliers whose products include PHP.
- Several UK organisations took websites down as a precaution that week, including Oxford City Council, the City of Edinburgh Council and the Office for Budget Responsibility, and some BBC programme pages were unavailable. A precautionary outage is not a hack.
- Amazon’s security team saw someone probe for the flaws on 17 October, four days before anything was public.
- On 26 October a researcher at Perplexity confirmed the first successful attacks, against a test server left exposed deliberately to attract them. It was running an unpatched PHP 8.4.26. Earlier reports of working attacks had turned out to be false.
- On 27 October CISA, the US government’s cyber agency, added both flaws to its list of vulnerabilities known to be exploited and gave federal agencies until Thursday to patch.
- A third, related flaw, CVE-2026-115560, was announced by PHP on 23 October. There is no patch yet. PHP says it only affects servers with an unusual combination of settings and application code, and recommends keeping a feature called session upload progress switched off until the next scheduled release. The NCSC alert did not mention it as of 27 October.
What we don’t know
- How many real websites have been compromised. The NCSC’s chief technology officer, Ollie Whitehouse, said on 22 October there were no indications of successful breaches at that point. The evidence since then shows attackers can now do it.
- When the third flaw will get a proper fix.
- How long it will take for damage to surface. Anyone who got in before a site was patched may have left something behind to come back to later.
What PHP is, and why your website almost certainly uses it
PHP is a programming language that runs on web servers. When someone visits your site, PHP is usually the code that fetches the right content from the database and turns it into the page they see. It has been around since 1995 and sits behind WordPress, Joomla, Drupal, Magento, most online shops, a lot of booking systems and the control panels hosting companies use.
Most people never see it, which is exactly why it gets forgotten. Don Smith of Sophos told the BBC that the immediate challenge is finding every place PHP runs, because it can sit under public websites, content systems, hosting platforms and third-party products “sometimes without even being obvious to the organisation using it”.
If you are not sure whether your site uses PHP: if it is WordPress, it does. If a web agency built it and it has a login area, a contact form that saves enquiries or an online shop, assume it does until told otherwise.
How to check which version of PHP your website runs on
You do not need technical skills for this, just a login.
WordPress. Log in to the admin area. Go to Tools, then Site Health, click the Info tab and open the Server section. The PHP version is listed there.
cPanel or Plesk. If your hosting account has a control panel, look for “Select PHP Version” or “PHP Settings”. The version in use is shown at the top.
Everything else. Ask whoever hosts or built the site. A screenshot takes them thirty seconds.
Once you have a number, compare it with this table. Dates are the PHP project’s own support schedule.
| PHP version | Fixed in | Security support ends | What to do |
| 8.5 | 8.5.12 | 31 December 2029 | Update to 8.5.12 or later |
| 8.4 | 8.4.27 | 31 December 2028 | Update to 8.4.27 or later |
| 8.3 | 8.3.36 | 31 December 2027 | Update to 8.3.36 or later |
| 8.2 | 8.2.35 | 31 December 2026 | Update to 8.2.35 now, and plan to move to 8.3 or newer before the end of the year |
| 8.1 and older | No official release | Already ended (8.1 ended 31 December 2025) | Ask your host whether a backported fix is applied. Plan an upgrade either way. |
The catch. Some hosts fix PHP by patching the version they already run rather than installing a new one, so the number on your Site Health screen may not change. GoDaddy has said as much to its customers, and cPanel-based hosts work the same way. If your host tells you the site is fixed but the version number looks old, ask them to confirm the fix in writing with the date it went on. “WordPress is up to date” is not an answer to this question.
Why updating WordPress isn’t enough
Keeping WordPress and your plugins up to date is good practice. It will not fix this.
The problem is in PHP, the layer underneath WordPress. PHP reads every incoming request before WordPress, your theme or any plugin gets to run, so a security plugin cannot step in front of it, and putting the site into maintenance mode does not help either. The fix has to be applied to PHP on the server. If a hosting company or agency manages the server, that is their job. If you manage it yourself, it is yours.
The hard part for most businesses is not the update. It is knowing who is supposed to do it.
Who is responsible for your website’s security?
In a lot of businesses, nobody is, at least not by name. Marketing looks after the content. A hosting company or web agency looks after the server. The IT provider assumes one of them has it covered. Everyone is doing their job and the gap sits in the middle. We see that gap often when we run an IT audit for a new client, and it is rarely anyone’s fault.
So the first job is to find out who that person is. Then ask them these five questions:
1
Which version of PHP does our website run on?
2
Have the fixes for CVE-2026-109618 and CVE-2026-109619 been applied, and on what date?
3
Has the temporary workaround for CVE-2026-115560 been applied?
4
Do any other systems you manage for us run PHP?
5
Have you checked for signs that anyone got in before the fix went on?
A good answer is specific: a version number, a date, a yes or no. “WordPress is up to date”, “we’re monitoring the situation” or silence are not good answers. Ask again, and if you still get nothing, treat the site as unpatched.
Running PHP 8.1 or older?
The official fixes only cover PHP 8.2 and above. PHP 8.1 went out of support on 31 December 2025, and 8.0 and 7.4 long before that. Because of how serious these flaws are, the PHP security team released source-only patches for those older branches, and cPanel and the main Linux distributions have built them into their own packages, so many hosts have been able to patch old versions anyway.
Two things follow. First, “we’re on 8.1” does not automatically mean “unpatched”, but it does mean you need your host to confirm. Second, even once it is patched, a site on an unsupported version of PHP will be in the same position the next time a flaw is found, and PHP 8.2 joins the unsupported list on 31 December 2026.
Upgrading can be more than a quick job. Older sites sometimes depend on themes or plugins that stop working on newer PHP. Ask your developer for an estimate, a test copy of the site on the new version, and a plan for keeping the live site safe in the meantime.
It’s not just your website
PHP turns up in places you might not expect: the admin screens of some firewalls, routers, network storage boxes and phone systems, and in software packages you run in-house. The NCSC’s sixth step is to watch for updates from any supplier whose products include PHP, and it points to a list of affected products maintained by the Dutch national cyber security centre.
We would add one thing. If you do not know what is on your network, you cannot check it against that list. An up-to-date inventory of equipment and software is the first thing we build in any IT audit, and this week is as good a reason as any to have one.
Five things to learn from the PHP security alerts
1
You can’t fix what you don’t know you have.
The NCSC’s first instruction was to find every system running PHP. For many organisations that took longer than applying the fix. A one-page list of your website, hosting, software and equipment, with a named person against each, saves hours the next time an alert lands.
2
Every system needs a named owner.
“Our web developer probably handles that” is not an answer. If you cannot put a person’s name next to your website’s security, that is the gap to close first.
3
The gap between warning and attack is shrinking.
Amazon saw probing four days before the flaws were public, and its chief information security officer has said AI now lets attackers move within hours of details being published. Waiting for next month’s maintenance window is no longer good enough for a critical alert.
4
Decide your “take it offline” plan before you need it.
The NCSC told organisations that could not fix things quickly to consider taking systems offline. That is a hard call to make on the spot. Who is allowed to make it, how you tell customers and how you keep trading in the meantime are all easier to agree on a quiet Tuesday. If you have a disaster recovery plan, this belongs in it.
5
Stay calm and check your sources.
The first week brought rumours of working attacks that were not, a leaked advisory, and at least one security firm withdrawing its claim that the flaws had been used against a European government. The answer is not to ignore alerts. It is to have one trusted source, the NCSC, and one person who can tell you what applies to you.
Watch out for scam emails using the headline
Big security stories bring scammers out. Expect emails that look like they come from your host, your bank or a security company, saying your site is affected and asking you to log in or click a link to “apply the patch”.
Do not. If you are worried, contact your host or developer using the details you already have, not the ones in the email. Forward anything suspicious to re****@**********ov.uk, the NCSC’s reporting service. If you want your team to be better at spotting these, our guide to phishing and how to protect your business covers what to look for.
waiting on andisa
Think you have already been compromised?
If you think someone may have got in before the fix went on, this is beyond a blog post. The NCSC advises checking for backdoors an attacker may have left and, if you are not confident doing that yourself, using an NCSC-assured Cyber Incident Response provider. Do not wipe and rebuild the server before someone has looked at it. That destroys the evidence of what was taken.
Two other things are worth doing now rather than later. UK organisations can sign up to the NCSC’s free Early Warning service, which tells you when your IP addresses or domains show up in threat data. And check what your cyber insurance requires of you after an incident, before you need to claim.
If you need help in a hurry, our emergency IT support covers exactly this situation.
Frequently asked questions
No. The flaws are in PHP, the software underneath WordPress, so the fix has to be applied to PHP on the server. Updating WordPress, themes or plugins does not change the PHP version. Keep them updated anyway.
Probably not for the website itself. Hosted builders run and patch their own servers, so there is nothing for you to install. [Squarespace took its Acuity Scheduling booking tool offline on 21 October as a precaution before bringing it back: verify against Squarespace’s status page before publishing.] If your site connects to a separate booking tool, shop plugin or app, ask that provider the same questions.
No. PHP handles the request before any plugin runs. Plugins such as Wordfence can spot and log some attack attempts, which is useful evidence, but they cannot close the hole.
The NCSC says to consider it if you cannot apply the fix or a temporary workaround quickly. For most businesses the better first step is to get your host to confirm the fix is in place. If they cannot say when that will happen, a short planned outage is safer than an unplanned one.
You usually cannot tell from the outside. Ask your host or developer to check the server for files and user accounts that should not be there, and to review access logs from 17 October onwards. If there is a real chance of compromise, use an NCSC-assured incident response provider.
It can be. Some hosts patch the existing version rather than install a new one. Ask for written confirmation with the date, and if they can show you the package or build date, better still.
For now. Security support for PHP 8.2 ends on 31 December 2026, so plan the move to 8.3 or newer before then.
Years. Flaws like this stay useful to attackers for as long as unpatched servers exist, and the scanning never really stops. Patching once is the start, not the end.
Not sure where you stand?
If you would rather someone checked it all for you, that is what we do. We will find out which version of PHP your website and systems run, confirm whether the fixes are in place, check your network equipment, and tell you in plain English. Call us on 01423 290029 or book a free intro call. No hard sell.
Andy Morrison
Articles: 147Andisa IT - Leading Managed Service Provider in Yorkshire, serving Harrogate, Leeds, York, and surrounding areas.
