php vulnerability php2shell

What needs to be done about the PHP vulnerability?

This week two serious flaws were discovered in PHP, the server software that powers around 70% of websites. This post explains what the PHP vulnerability means for an organisation’s website, and what needs to be done.

In most cases, patches need to be applied at the server level by a hosting provider. Once this is done, in most cases the website itself does not need an update. We run several websites and have confirmed this to be the case today.

Two critical flaws in PHP

Researchers found the two flaws with the help of AI tools after they had sat in the code for more than a decade. PHP’s own security advisory rates both at 9.2 out of 10 in terms of severity. PHP announced a critical fix was coming and deliberately withheld the details so hosting providers could patch before attackers worked out how to exploit the flaws.

However, the details leaked a day early anyway, and Cloudflare’s CEO reported thousands of attempts to exploit them in the 10 hours before the announcement and millions soon after. The BBC and the Guardian both explain the situation fairly well in plain terms.

Before the details came out, the potential for damage was great. The flaws let an attacker take over a server without logging in, and nobody outside the PHP team yet knew what the fix would involve. Government agencies and universities in several countries took their websites offline as a precaution, and the Australian Signals Directorate was initially taken offline as a precaution before later issuing a security advisory.

PHP.net released the patches at 1.00am Thursday, Melbourne time, and the details came out with it. It now looks like the fix is a server patch applied by whoever runs the server. This means websites run by a managed hosting company have little or nothing to do. Attempts to exploit the flaws number in the millions, but the UK’s National Cyber Security Centre has reported no successful hacks so far.

Website software and server software are separate layers

Digital and networking infrastructure has several layers. Website software, like WordPress or Joomla, is the layer that people see and interact with, a bit like the shelves and signage in a shop. PHP is the wiring behind the walls, and these flaws were in the wiring. PHP isn’t just used by WordPress: it also powers e-commerce platforms such as Magento and PrestaShop, online learning systems such as Moodle, wikis, forums, customer databases, marketing tools and webmail. The last time we discussed a security advisory issued by the Australian Signals Directorate back in July 2026, it was about a WordPress plugin – in the ‘shelves and signage’ layer. This time it’s still security but in a different layer with potentially greater impact.

Keeping a website’s software up to date is good practice at any time, but this time updating WordPress or Joomla or any system that runs on PHP, cannot directly fix flaws that occurs within PHP itself.

Older websites sit on older server software

An old website runs on an older version of PHP. When we first heard about this, the fixes hadn’t been released and the details were understandably withheld, so we couldn’t ascertain how far back it went and which PHP versions would have patches released, and whether anything would be required at the website level as well.

We got in touch with one client who still runs a Joomla 3 website, a version that stopped receiving updates several years ago. To keep this site running, we’ve had to lock the older PHP version while we work with them towards a new site. The advice we provided was pre-emptive – that if the issue could be resolved without having to update to a newer PHP version, or the website software, then the site may be OK. If, however, the recommended solution was to upgrade to a newer version of PHP, and the website software didn’t support that, our options would be limited.

As it turned out, older PHP versions had patches released, the hosting provider was on the ball, and the website continues to operate without interruption. Our client got lucky. When a situation like this arises, it requires every organisation in the chain, from the people who develop PHP to the hosting company, to come to the party. The more pieces that require work, the greater the effort all around and the greater the chance something will not work at the end. The UK’s National Cyber Security Centre has said the patch will not work for some organisations running older systems, and those will have to be replaced.

How our hosting provider responded

We’ve been using and recommending VentraIP* for almost two decades, and most of the website solutions we’ve delivered in that time are still hosted there. Once a fix exists, every hosting company in the world has to install it on all of its servers, and even though the PHP patches were released at 1.00am, VentraIP technicians were on the job. By Thursday evening the patches were applied across their shared hosting and managed servers, and temporary restrictions were removed. Their status notice advised customers no action was required. Responding this way is one of the main reasons we continue to recommend them.

The response depends on who runs the server

  • A hosting company manages the server. Ask the hosting company if PHP security fixes been applied to the server that runs the website? This also applies to a website built by a developer who has since moved on. Good hosting providers have a status page that will provide updates for situations like this.
  • A site builder such as Squarespace or Wix. Nothing is required this time. SaaS solutions provide the hosting infrastructure and look after it for you, so there is nothing the website owner needs to do. We’ve migrated dozens of clients to Squarespace in the last few years.
  • The organisation runs its own web server. Apply the fix, or take the server offline until it can be applied, as security agencies advised.
  • An older system the fix won’t cover. Plan to replace it.

Security researchers expect attempts to exploit these flaws to continue for weeks, so a server that hasn’t been patched will remain exposed. The concern is greatest for organisations without dedicated technical support, such as schools, local councils and charities. Messages about this issue are also likely to come from people trading on the news, so any email asking for a password should be checked with the hosting company first.

Read more about ownership and management of digital systems in our recent blog post – Does your organisation have a single point of failure?

* Please note, using this link provides a referral bonus to ENVEE Digital

newsletter signup

Practical technology advice

Sign up to our quarterly newsletter for articles on technology, digital strategy, websites and AI adoption.

We don’t spam! Read our privacy policy for more info.