PHP - a race across the world

A few weeks ago, only a relatively select group of people knew what PHP: Hypertext Pre-processor
(PHP) is. Most were software engineers and web developers. Even the BBC’s cyber columnist Joe Tidy admitted he wasn’t sure, creating a fairly awkward credibility rug-pull. Whilst I completely appreciate that a health correspondent is not the same thing as a surgeon, this was like hearing someone on Top Gear say: “Cars use petrol? The smelly stuff you get at garages? Wow!”

Regardless. On 21 October, millions more people became at least passingly familiar with this particularly important household item, Joe included. I’m sure many of them have since forgotten about it. Joe probably hasn’t. So how exactly did this unwelcome incursion occur? Read on to find out.

First things first. What is PHP?

PHP is a programming language that runs on web servers. When you visit a website, it assembles the page that your browser receives. You don’t really see it directly, but on many websites it’s doing much of the heavy lifting behind the scenes.

It’s both free of charge and “open-source” (which means anyone is free to read and copy the source code). As a result, it’s widely used across the web with popular web platforms such as WordPress, Drupal and MediaWiki all depending on it. In fact, about 70% of websites use PHP under the bonnet. Whilst that doesn’t necessarily mean “70% of the entire web”, it’s still an extraordinary concentration of functionality that depends on a single layer of technology. It’s this ubiquity that leads to a seemingly obscure-sounding software issue suddenly becoming a global operational issue.

So, what actually happened?

Two critical vulnerabilities had existed in PHP for over a decade, but at that point no one could show that they could be turned into a practical attack. On 14 August, security researchers at a company called Calif – assisted by AI – discovered how these vulnerabilities could be exploited. They shared this immediately with PHP Foundation (the group that looks after the PHP open-source code) who confirmed this the following day and worked with them on a fix.

As is often the case with security issues, the group’s plan was to disclose the vulnerabilities in a controlled way, allowing website maintainers and major providers time to prepare. However, on the evening of Tuesday 20 October, Calif accidentally published a video demonstrating how an attacker could potentially run programs or steal data remotely (all without requiring a password).

The originally planned communication timetable suddenly collapsed. Patches needed to be released on Wednesday, and organisations around the world had to quickly identify any affected systems. Governments, councils, hospitals, retailers and media organisations temporarily withdrew many services as fixes were applied, all whilst hostile scanning and hacking attempts rapidly accelerated.

The combination of PHP’s broad use and the bugs potential for catastrophic impact meant that by Wednesday morning, it was making front page news across the globe.

For me, the interesting part is not that old software contained a flaw. That’s not at all uncommon. All complicated software contains bugs. It’s that the vulnerability lay so far down in fundamental shared software, lurking beneath an enormous range of services. Despite this, AI was able to rapidly perform the combinatoric logic required to find these bugs, having gone un-noticed by humans for years, using little more than the prompt “Find bad vulnerabilities in PHP."

What does this mean for the LGPS?

Thinking about security, AI and technology governance (a preoccupation for many of us these days!), relatively few LGPS committee and board members have deep systems experience. Given the history of the pensions industry, this is entirely understandable. Looking forward though, the LGPS is ever more reliant on technology. We can no longer simply delegate technology decisions entirely to the IT department and regard the subject as dealt with. 

In its new AI Guidance, the Pensions Regulator has once again been explicit that fund managers remain accountable for the security of scheme information and assets even when other organisations handle the data or technology. Funds should understand the risks, ensure controls are operating well, and be ready to manage incidents such as this one. 

This is of course not an argument that every committee member needs to learn PHP, but it’s becoming increasingly clear that governing bodies need enough digital literacy to recognise concentration risk and challenge the technical assurance made by providers. The relevant knowledge is not necessarily as low level as how to write code or AI prompts. However, funds do need to understand how they depend on technology and AI, who manages it and what happens when it fails.

The race is not yet won

When a foundational technology fails, organisations now need to act swiftly and professionally. They can expect to be judged on how well they handle such a situation, how proactively they had prepared for disruption and whether they could respond quickly and effectively.

As we accelerate into the future, AI will very likely uncover more long-hidden weaknesses, not fewer. Perhaps counterintuitively, this is actually good news for us if the industry – those who have members best interests at heart - can find and fix these before bad actors get the chance. 

Nonetheless, it does compress the timescales between discovery, disclosure and attack. What in the past took weeks or months is now taking days or hours. In my view the PHP incident was not a one-off situation; it’s part of our “new normal”. A new daily reality where a far greater level of digital acumen is required by funds, not just to be effective today, but fit for purpose in the future.

Whilst the recent incident in isolation felt like a 100m sprint finish, the reality is better thought of as an ultra-marathon.

If you'd like to discuss anything further, we would love to hear from you so please get in touch. 

This blog is based upon our understanding of events as at the date of publication. It is a general summary of topical matters and should not be regarded as financial advice. It should not be considered a substitute for professional advice on specific circumstances and objectives. Where this blog refers to legal matters please note that Hymans Robertson LLP is not qualified to provide legal opinion and therefore you may wish to obtain independent legal advice to consider any relevant law and/or regulation. Please read our Terms of Use - Hymans Robertson.