The PHP security flaw: why keeping your software up to date matters

Published

In late October 2026, websites around the world went offline as organisations rushed to fix two critical security flaws in PHP, the programming language behind an estimated 70% of websites.

A fix arrived within a day. But it was only released for versions of PHP that were still supported. Businesses running older versions had no official fix at all.

That’s the real lesson from PHP2Shell, as the flaws became known. Keeping your software up to date isn’t box-ticking. It decides whether a security scare costs you an afternoon or turns into a crisis. This guide explains what happened, why your software’s version matters so much, and what to ask whoever looks after your system.

What happened with the PHP security flaw?

On 20 October 2026, the PHP project announced two critical flaws in PHP itself. Details leaked online before the planned release, and the fix followed the next day.

The flaws were serious because of what they allowed. An attacker didn’t need a password or an account. In the worst case, they could run their own code on the server, which means taking control of the website and potentially the data behind it.

The UK’s National Cyber Security Centre (NCSC) urged organisations to update straight away, or consider taking sites offline until they could. Within a week, the US cyber security agency CISA had added both flaws to its list of vulnerabilities known to be exploited by attackers.

If your business software is built in PHP, which includes every WordPress site and a great many bespoke business systems, it was potentially affected.

Why could some businesses fix it within hours and others couldn’t?

It came down to which version of PHP they were running.

Each version of PHP is supported for four years: two years of regular updates, then two years of security fixes only. After that it reaches “end of life” and gets no more fixes, however serious the problem.

The fix released on 21 October covered PHP 8.2, 8.3, 8.4 and 8.5, the versions still supported. PHP 8.1 had reached end of life on 31 December 2025, so there was no official fix for it, or for anything older.

That split businesses into two groups:

  • On a supported version: apply the update, check everything still works, and you’re done. For most, a same-day job.
  • On an end-of-life version: there was no update to apply. The options were temporary workarounds, paying a specialist for an unofficial fix, taking the system offline, or a rushed upgrade.

A rushed upgrade is the worst way to do one. Moving between versions can mean changes to your code, and those changes need testing. Doing it in a hurry, while your system is exposed, is when mistakes happen.

The frustrating part is that software on an end-of-life version keeps working perfectly. Nothing warns you it’s no longer protected. Many businesses only find out when something like this happens.

PHP 8.2 reaches end of life on 31 December 2026

If your system runs on PHP 8.2, now is the time to act. Its security support ends on 31 December 2026, less than two months away.

Had these flaws been found in January 2027, every business on 8.2 would have been in the same position as those on 8.1 were in October: exposed, with no official fix.

Planned in advance, the upgrade is usually manageable. Ask your developer which version you’re on and, if it’s 8.2 or older, when the upgrade is booked in. Moving to a newer version buys you more time, too: PHP 8.5 is supported until the end of 2029.

What’s the difference between a patch and an upgrade?

A patch is a small update within the same version, for example from PHP 8.4.26 to 8.4.27. It fixes problems without changing how anything works, so it’s usually quick and low risk. The PHP2Shell fix was a patch.

An upgrade moves you to a new version, for example from 8.2 to 8.4. It brings a fresh support period, but some older ways of doing things stop working. Your code may need changes, and the system needs proper testing.

You need both. Patches keep you safe day to day. Upgrades keep you on a version that still gets patches.

Why small, regular steps cost less

The cost of upgrading grows the longer you leave it. Moving up one version is usually a modest, predictable job. Jumping several at once means dealing with every change in between, all in one go.

PHP is also only one layer. Think of your system like a building: your bespoke code is the part you see, but it stands on foundations you don’t. These include the framework it’s built with, third-party code libraries, the server’s operating system and the database. Each has its own support timeline, and they tend to fall behind together. Leave things long enough and a simple upgrade becomes a small rebuild.

Why is this likely to happen more often?

These flaws were found with the help of AI. They affected versions of PHP going back to 5.4, released in 2012, so they’d gone unnoticed for well over a decade.

On the whole, that’s good news: weaknesses are being found and fixed faster than ever. But attackers have the same tools. Security firms reported attempts to exploit these flaws within days of the details leaking, some before the fix was even out.

The practical upshot is that the gap between a flaw becoming public and someone trying to use it is shrinking. Being able to apply a fix the same day matters more than it used to. That’s only possible if you’re on a supported version and someone is ready to act.

Questions to ask your developer

You don’t need to understand the answers in technical detail. You’re looking for clear, confident replies and a plan with dates.

  1. Which version of PHP is our system running, and is it still supported? If they need to go away and check, that’s fine. If nobody knows, that’s a problem in itself.
  2. Was our system affected by the October PHP flaws, and when was the fix applied? You want a date, not “we think so”.
  3. What else does our system rely on, and is all of it supported? This covers the framework, code libraries, server and database.
  4. When does our current version reach end of life, and when is the upgrade planned?
  5. How would you hear about the next critical flaw, and how quickly could you act?
  6. Who is responsible for applying updates? Your developer, your hosting provider or your own team? If the answer is “not sure”, it’s probably nobody.

How to keep your software up to date without the drama

Staying current isn’t complicated. It just needs to be routine rather than something you get round to.

  • Patch as a matter of course. Security updates should be applied regularly, and critical ones as soon as they’re released.
  • Plan an upgrade every year. A new version of PHP comes out each November. Moving up regularly keeps you well within support and keeps each upgrade small.
  • Know your end-of-life dates. Keep a short list of what your system runs on and when support for each part ends. Put those dates in the diary, with time to spare.
  • Make updates quick to test and release. If applying a fix means days of manual checking, you’ll always be slow when it counts. Automated tests and a reliable release process make same-day fixes realistic.
  • Budget for it as a running cost. Treat it like insurance or hosting, not an optional extra. A planned upgrade almost always costs less than an emergency one, and you get to choose when it happens.
  • Agree who’s responsible, in writing. Updates fall through the gaps when everyone assumes someone else is doing them.

How we handled it at Yammayap

When the PHP flaws were announced, we put temporary protections in place on our clients’ systems that morning. Once the fix was released, we patched every client production system we look after the same day. Most test systems were done that day too, and a couple were taken offline as a precaution and updated the next day.

Moving that quickly comes down to the routine work done beforehand. Keeping systems patched and up to date is part of Depend, our aftercare service.

Not sure which version your system is running, or whether it’s still supported? Get in touch and we’ll help you find out.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name given to two critical security flaws in PHP, disclosed in October 2026. They could let an attacker take control of a server without logging in. They were fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Versions 8.1 and older received no official fix.

How do I know if my website or system uses PHP?

Ask your developer or hosting provider; they’ll know straight away. Every WordPress site runs on PHP, and so do many bespoke business systems.

What does end of life mean for software?

It means a version no longer receives any fixes, including for security problems. The software keeps working, but any new weakness found in it stays open for good.

Is my software safe if it’s still working fine?

Not necessarily. Working fine and being protected are different things. Software on an unsupported version can run perfectly for years while being exposed to known weaknesses.

How often should business software be updated?

Security patches should be applied regularly, and critical ones as soon as possible, ideally the same day. Plan a larger upgrade once a year to stay on a supported version.

What should I do if my system is on an unsupported version of PHP?

Plan the upgrade now rather than waiting for the next scare. In the meantime, ask your developer what temporary protections are in place and how long the upgrade will take.