The October PHP vulnerabilities and the case for regular maintenance

When PHP’s emergency security patches arrived on 21 October, I started updating client instances. Quite a few organisations were doing the same thing that week, with some taking services offline while they dealt with it.

It’s the sort of update you want to be able to get on with. Check the fix, apply it, make sure the application still works.

How straightforward that is has a lot to do with the maintenance that’s happened beforehand. An application that’s been kept up to date gives you a much better starting point than one nobody has wanted to touch for five years.

That’s the part of this incident I think is worth talking about once the immediate patching is done.

What caused all the fuss?

PHP does much of the work behind the scenes on a website or business application. It handles things like processing a submitted form, checking a login or fetching information from a database. Laravel, Symfony, WordPress and plenty of bespoke systems are built on it.

The two October vulnerabilities were faults in PHP itself. One involved how it cleaned up after running out of memory. The other involved references to old data being carried over between requests. On an affected setup, an attacker could use those mistakes to run their own code on the server.

That’s a serious problem when the server runs your customer portal, holds personal information or supports the work your staff do every day. The PHP team published the details as CVE-2026-109618 and CVE-2026-109619, and the UK’s National Cyber Security Centre urged organisations to patch urgently.

The disruption was visible. A minister reported 32 UK government services unavailable and four partly unavailable the following day, largely because of precautionary measures. The Dutch government temporarily took services offline too.

Even the sensible decision to take a service down while fixing it has a cost. People still need to use it.

PHP is still doing a lot of work

For a language that regularly gets written off as dead, PHP is remarkably busy.

At the end of October 2026, W3Techs put it on 69.2% of websites whose server-side language it could identify. Behind those websites are businesses using it for bookings, payments, customer accounts and internal tools. Often the people relying on those systems have no reason to know they’re using PHP at all.

It also continues to receive new releases and security support for maintained versions. The practical question for a business is which version its application runs on, and whether someone is looking after it.

When a PHP update becomes an application project

Updating PHP means changing the software that runs your application. The application has to work with that version too.

On a system that’s been maintained regularly, there’s a good chance the work fits into the normal release process. You apply the update, test the important workflows and deploy it.

With an older application, you can find yourself needing to update the framework first. That may require newer packages. One of those packages might have been abandoned, or the server might need attention before it can run the newer software.

Suddenly there’s quite a bit of work between “we need this security fix” and being able to deploy it confidently.

PHP did provide exceptional patches for some older versions during this incident, and some hosting and operating-system suppliers supplied their own fixes. For an older system, checking what’s available through its supplier is part of working out the immediate response. The longer-term job is getting the application onto a version that will continue receiving support.

That doesn’t have to mean starting again. An old application may still be doing exactly what the business needs. I would rather understand what it does, protect the important parts and work through a sensible upgrade than assume it needs replacing because of its age.

Make the next update less of an event

The maintenance work that helps here is fairly ordinary. Keep PHP, the application’s packages and the server software up to date. Know when their support ends. Have a reliable way to deploy changes and check that the things people depend on still work afterwards.

For a business application, those checks need to cover real work. Can a customer still pay? Does the scheduled report arrive? Can staff complete the process they use every morning?

Doing that work regularly gives you smaller changes to deal with. Leave it for years and you end up trying to understand several generations of changes at once, sometimes with an urgent security problem setting the deadline.

That’s why I see ongoing maintenance as part of owning the application. The business keeps depending on it long after the original development project ends.

This is the work I help with through my maintenance and modernisation service. I review existing Laravel and PHP applications, work through upgrades and help keep them maintained afterwards.

If you’ve inherited a system, fallen behind on updates or reached the point where nobody feels comfortable changing it, tell me a bit about it. We can work out what needs attention first and how to make future updates easier to manage.