PHP2Shell exposed a bigger problem than PHP

23 October 2026

This week, our engineering team did what technology teams across the world were doing. We reviewed the products we support, applied the emergency PHP updates where required, tested the affected platforms and kept our clients informed.

For well maintained applications running supported versions, it was urgent but manageable. For businesses still running older, ‘harder to change’ software, the situation was more complicated.

That gap is the real story of PHP2Shell.

What happened

PHP2Shell is the name given to two critical security flaws in PHP, the technology behind a large share of websites, customer portals and business applications. These flaws could allow an attacker to run malicious commands on a vulnerable server, without needing a password or anyone clicking a malicious link. If successfully exploited, an attacker could potentially access sensitive data, disrupt services or compromise other connected systems.

On 21st October, emergency fixes were released for PHP 8.2 to 8.5 and the UK's National Cyber Security Centre urged companies to update immediately, or to consider taking affected systems offline if they couldn't be adequately protected.

But for businesses running older versions of PHP, the situation is more complicated. PHP 8.1 and earlier no longer receive regular security updates from the PHP project. While limited patches are available for some older versions, moving to a fully supported version is the better long term solution. And for applications built around ageing technology, that isn't always straightforward.

So for some businesses, this isn't simply a case of installing a security patch. It's about whether the software they depend on can be safely and easily updated in the first place. This is where a security problem becomes a business problem.

AI changed the economics of finding flaws

The flaws weren't new. Some had been in PHP for more than a decade. Signs of one of the underlying problems had been identified back in 2024, but researchers hadn't established a practical way to exploit it.

This year, researchers from Calif, OpenAI and Wiz demonstrated how serious those weaknesses could be, with frontier AI models playing a significant role in identifying vulnerabilities and developing working exploits.

What previously required extraordinary effort became much more achievable.

Here, AI was in the hands of people trying to find and fix the problem. But those capabilities won't be limited to security researchers. The time between a flaw being discovered and a working exploit becoming available could get considerably shorter.

"Nobody will bother with our old application" was always a weak argument. Now it's an even harder one to defend.

In a world where vulnerabilities can be found faster, the ability to fix them becomes even more important.

The application nobody wants to change

The challenge is that not every business can respond to a security threat as quickly as it needs to. For some, applying an update is relatively straightforward. For others, even a small change to a critical application can carry significant risk.

Often, that's because the software has become so difficult to maintain that making changes is something the business actively avoids.

It's a familiar situation. An application was built years ago, it still does its job, and the business can't run without it.

The original developer has left, or the supplier has moved on. Documentation is thin. Upgrading a framework might break an integration, and nobody is sure what else.

So the upgrade gets postponed, year after year.

That isn't necessarily neglect. Changing something that works is hard to justify when the cost is certain and the benefit is invisible.

But each postponement adds to the bill. Dependencies age, knowledge leaves and small changes get harder. Then a critical vulnerability like PHP2Shell arrives, and changes avoided for years have to happen this week.

The problem isn't simply whether software is old or new. Even supported technology can contain serious vulnerabilities.

What matters is how quickly those vulnerabilities can be addressed and how confidently a business can make the changes required.

Patched isn't the same as prepared

Applying the emergency security updates addresses the immediate vulnerabilities, but it doesn't necessarily resolve the longer term risks.

PHP 8.2, for example, received a security update this week, but reaches the end of official support on 31st December 2026. Businesses running it will need to plan another upgrade to remain on supported technology.

And while applying a patch fixes the known vulnerability, it doesn't tell you whether a system was compromised before the update was installed.

The bigger question isn't simply whether your software has been patched this week. It's whether your business is prepared to respond just as quickly when the next vulnerability is discovered.

The economics of modernisation are changing too

The same advances in AI that are making vulnerabilities easier to discover are also changing what's possible when it comes to modernising ageing software.

One of the biggest barriers to modernisation has always been the unknown. Years of undocumented changes, hidden dependencies and lost technical knowledge can make it difficult to understand exactly how an application works, what risks might be lurking beneath the surface or what could break if something changes.

That uncertainty makes modernisation feel expensive, complicated and risky. And it's one of the reasons businesses continue to put it off.

But the way we approach modernisation is changing.

At GCD, we're combining agentic engineering, our Acorn Development Platform (ADP) of reusable application components and experienced engineering teams to make the process faster and more predictable.

AI helps us analyse existing code, uncover dependencies, understand business logic and accelerate development and testing. Acorn provides established functionality and patterns that don't need to be built from scratch. And our engineers bring the experience and judgement to make the right technical decisions, manage complexity and validate the results.

It's the combination that makes the difference.

For suitably scoped applications, modernisation projects that could once have taken months or even years can now potentially be delivered in weeks.

For businesses that have put off modernisation because of the cost, complexity and fear of the unknown, that changes the conversation.

Modernise first. Evolve faster.

But modernising faster isn't just about how the software is built. It's also about what you choose to change.

Traditional modernisation projects often try to do everything at once: replace ageing technology, redesign business processes and introduce new functionality. That adds scope, complexity and risk to an already challenging project.

We believe there's a better approach.

Rather than reinventing an application that's already doing its job, we focus first on preserving what works and replacing the technology that's holding it back.

Where a rebuild is the right choice, we establish what the existing application needs to do, recreate that agreed functionality on modern, supported foundations and validate that it works as expected.

Once those foundations are in place, businesses have software that's easier to maintain, update and secure, reducing the risk of being caught out by the next critical vulnerability.

And with the constraints of ageing technology removed, they can focus on what comes next: new features, better integrations, automation and opportunities to innovate.

Modernise first. Evolve faster.

Because you shouldn't have to reinvent how your business works to modernise the software it depends on.

Three questions for this week

Whether your business was directly affected by PHP2Shell or not, this week's events have raised some important questions about how well businesses understand and maintain the software they rely on.

Here are three worth asking:

1. Do we know what we're running?

Which applications depend on PHP, which versions are they using, and are those versions supported?

2. What's the plan beyond the patch?

If anything is on PHP 8.2 or older, how will we upgrade or replace it before its support arrangements become a problem?

3. Could we change a business critical application safely tomorrow?

Do we have the people, knowledge and testing processes to do it with confidence?

If the honest answer to that third question is "no", that's where the conversation starts.

Talk to us

If PHP2Shell has raised concerns about an ageing application your business relies on, it might be time to reconsider replacing it.

At GCD, we're changing what's possible with legacy modernisation. By combining agentic engineering, our Acorn library and experienced teams, we can rebuild suitable applications on modern, supported foundations in weeks rather than months or years, preserving the functionality your business depends on.

If you've been putting off modernisation because of the time, cost or risk involved, let's talk about what's possible.

Andrew Gough

Managing Director