What the PHP Security Crisis Reveals About Cyber Preparedness

Over the last few days, a serious security vulnerability in a technology most people have never heard of has caused disruption across the internet.

Government websites have been taken offline, security teams have been working around the clock, and organisations around the world have been urgently reviewing their exposure.

The technology is PHP, a programming language used by a huge proportion of the world's websites. Two critical vulnerabilities, collectively known as PHP2Shell, were disclosed last week. They could allow attackers to take control of vulnerable servers without needing a username or password.

The flaws were discovered with the help of artificial intelligence, and some of the underlying weaknesses had existed for well over a decade.

For business leaders, I think there are some important lessons here that go well beyond PHP.

It's not whether you have a vulnerability. It's how prepared you are when one is discovered.

I've spent much of my career building and advising technology businesses, and one thing I've learned is that even well managed organisations cannot eliminate every risk.

The internet runs on an enormous collection of software, services and infrastructure developed by thousands of different organisations. We all depend on technology we don't directly control.

A vulnerability can exist for years without anyone knowing about it. Yesterday, a system could reasonably be considered secure. Today, the discovery of a previously unknown weakness might require urgent action.

That doesn't necessarily mean anyone has been negligent.

What matters is how quickly an organisation can establish its exposure, understand the potential impact and respond.

The first few hours are often the most important, particularly when details of a vulnerability become public before a fix is available.

The decisions aren't always purely technical

At Report URI, we use PHP ourselves.

When the initial details emerged, our technical team began investigating the vulnerabilities and putting temporary protections in place before the security patches were available.

One of those decisions was to temporarily block certain types of requests reaching our infrastructure.

That meant some functionality had to be switched off.

It was a deliberate trade off. We also made arrangements to ensure incoming customer reports would be retained and processed once normal operations resumed.

When the official security updates became available on 21 October, the team tested and deployed them across our infrastructure. Every server was patched that evening, normal functionality was restored and our investigations found no evidence of exploitation.

Scott has documented the technical response in detail in his article, Responding to php2shell.

What interests me as a business leader isn't the configuration changes themselves.

It's the decision making behind them.

Someone needs to decide whether to restrict a service, potentially inconvenience customers or accept a temporary operational impact to reduce a security risk.

Those decisions involve commercial judgement as well as technical expertise.

In a serious incident, waiting for complete certainty may not be an option. Equally, taking drastic action without understanding the consequences can create problems of its own.

Good preparation means understanding those trade offs before you're under pressure to make them.

Five questions I'd encourage every leadership team to ask

You don't need to understand PHP, memory corruption or the technical details of last week's vulnerabilities.

But I do think every CEO and board should be able to get clear answers to five questions.

1. Do we know which of our systems could be affected?

That includes customer facing websites, internal applications and technology supplied by third parties.

If your team has to begin compiling an inventory after a critical vulnerability is announced, valuable time has already been lost.

2. Who has the authority to act immediately?

If a serious vulnerability emerges outside normal working hours, can the people responsible make the necessary changes?

Do they have the authority to disable a feature, restrict access or temporarily take a service offline?

Or must they wait for approval from someone who may not be available?

3. How would we protect the business if a patch wasn't available?

The response might involve temporary security controls, reducing exposed functionality or taking an affected service offline.

There may be no completely safe workaround. The important thing is understanding the available options, their limitations and the potential impact on customers.

4. How do we know whether we've actually been compromised?

Installing a security patch fixes a vulnerability. It doesn't establish whether someone exploited it beforehand.

What monitoring, logs and other evidence would the technical team use to investigate? How confident could they be in the answer?

5. Could we explain our response to customers?

If a customer asks what happened, whether their data was at risk and what action you took, could you provide a clear and credible explanation?

Good communication depends on knowing the facts, recognising what remains uncertain and being willing to explain the decisions made.

These are questions of governance, accountability and operational readiness. They shouldn't only be considered when a security incident is already underway.

AI is changing the pace

There's another aspect of this incident that deserves attention.

The PHP vulnerabilities weren't necessarily new. Some of the weaknesses had been present in the software for many years.

What changed was the ability to discover and demonstrate how they could be exploited.

Researchers used advanced AI tools to help uncover complex vulnerabilities that had previously escaped detection.

That is a positive development for security research. Discovering and fixing weaknesses before criminals exploit them is exactly what we should want.

But there's another side to it.

As the tools available to researchers become more capable, the technical difficulty of discovering or exploiting certain vulnerabilities may become less of a barrier.

It would be a mistake to assume that a complex vulnerability is unlikely to be exploited simply because doing so has historically required exceptional expertise.

I think this has a significant implication for businesses.

The time available between learning about a threat and needing to respond to it may continue to shrink.

Organisations that depend on lengthy approval processes, incomplete technology inventories or manual responses will find that increasingly difficult.

Preparedness is something you demonstrate

One thing I particularly appreciated about our team's response was the transparency.

Scott published what we knew, what we didn't know, the actions we had taken and why. As new information became available, he updated the article, including the limitations of the early mitigations and confirmation that patching was complete.

That approach matters.

Customers shouldn't have to assume that a technology provider is taking security seriously. They should be able to see evidence of it.

Nor should a company have to claim that it is immune from vulnerabilities. That's neither realistic nor particularly credible.

I'd have far more confidence in a business that understands its dependencies, can explain its decisions and can demonstrate a considered response when something goes wrong.

The PHP crisis will eventually disappear from the headlines. The patches are available, and organisations will continue updating their systems and investigating any potential exposure.

But there will be another critical vulnerability, in another widely used technology, and it may arrive with even less warning.

The question I'd leave business leaders with is a simple one.

If your organisation discovered tomorrow that a critical part of its infrastructure was vulnerable, how confident are you in what would happen during the first few hours?

It's worth finding out before you need to.