PHP2Shell, and the 98% of Clients Who Didn't Ask

On Tuesday the PHP security team did something I don't see often: it gave a day's warning. A security release was coming on Wednesday, it said, fixing two critical vulnerabilities, and all PHP users should "prepare now". It also reserved the right to ship early if details leaked or anyone started exploiting them first.

On Wednesday the fixes landed (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35), along with an advisory whose headline ended in two words: "update now". Singapore's Cyber Security Agency put out its own alert the same day (it's been updated since), calling the pair PHP2Shell. It reports "widespread exploitation attempts" and "the development of multiple proof-of-concept (PoC) exploits".

The CSA's line on who's affected is the one that matters:

"These vulnerabilities affect all versions of PHP."

All of them. And PHP isn't some niche tool. W3Techs puts it behind 69.3% of the websites whose server-side language it can identify. WordPress runs on it. So do a great many online shops, booking systems, membership portals and client dashboards, including more than a few that their owners have never thought of as "PHP".

Why this one is worse than the usual patch notice

Most security updates fix something an attacker needs a foothold to use: a login, a vulnerable plugin, an admin who clicks the wrong link. These two don't. Both are rated 9.2 out of 10, and both allow what the PHP team calls "unauthenticated remote code execution". A stranger on the internet sends a crafted request to the server and gets to run their own code on it. No password needed.

For one common server setup (Apache with mod_php), the PHP team says it has a demonstrated exploit where the attack fires "before any application code runs". That means the site's strong passwords, its security plugin and its two-factor login don't get a say. The door being forced is underneath all of them.

The temporary workarounds tell their own story. The advisory suggests things like setting memory_limit=-1 in a way applications can't override, switching off session.upload_progress.enabled and restarting every worker, and enforcing request limits at the proxy. And it says up front that these "do not make an installation safe". There's no setting a site owner can toggle in an admin panel. Somebody has to get onto the server and update it.

Two percent

Our clients, between them, use more AI tools than I can count. AI writes their first drafts, answers their website chats, summarises their meetings, tidies their ad copy and sorts their inboxes. Several of them are further along with AI than companies three times their size. I'm proud of that, and some of it is our doing.

When PHP2Shell broke, 2% of them got in touch to ask whether we knew about it and whether we'd acted on it.

Two percent.

(We had. We were up waiting for the release, which landed at 10pm Singapore time, and patched as soon as it was out. But that's not the point of this post.)

I'd like to believe the other 98% trust that they're in good hands. Some of them have told me as much over the years, and I don't take it lightly. (I suspect most of their staff couldn't tell you what my company is called. They just know to "contact Derek's team".) But I've been on the vendor's side of the table long enough to know how trust works. It's a feeling, and it holds up only while the vendor stays competent and is still the one responsible for the thing at risk. In a lot of companies that last condition is the shaky one. The website is with us, the booking system is with a developer someone's cousin recommended in 2021, the HR portal came with a payroll package, and the old campaign microsite is still up on a server nobody remembers paying for. The CSA's own advice is to check for PHP on every web server "including where it may be used by third-party applications or components, even if their primary websites do not use PHP". That's exactly where the forgotten ones live.

A client who asks the question is a client with at least a rough map of what they own. Most of the 2% aren't technical at all. At some point, each of them decided this was their problem too.

AI made the house bigger

I'm not about to argue against AI. It's the best thing to happen to small teams in my working life. A five-person company can now turn out the content and reporting that used to need fifteen people. That's real growth, and I'd be a hypocrite to tell anyone to slow down.

But think about what that growth looks like from the outside. More pages, more forms collecting customer details, more integrations passing data between systems, more automated accounts with access to more things. Every one of those is a room added to the house. AI made the house bigger and nicer, very quickly, and in most of the companies I see, the locks are the same ones that came with the original flat.

Most Singaporeans I know will spend months and a sizeable chunk of savings getting a renovation right. The carpentry, the feature wall, the lot. I've never heard of anyone moving in and skipping the lock on the main door because the interior designer seemed trustworthy. Yet that's roughly how a lot of organisations treat the servers and software holding their customer records. The building gets a budget. The securing of it gets a hope.

Notice too that none of those AI tools raised their hand this week. Somewhere this week, a chatbot will have answered customer questions all day while the server underneath it waited for a patch. The tools do what they're pointed at, and in the companies I deal with, nobody had pointed one at this.

Put it next to accounting and HR

So here's my position, and I know it'll sound self-serving coming from someone who sells web services: cybersecurity belongs in the annual budget as its own line, next to accounting and HR, and it shouldn't be the first thing cut when the year gets tight.

I've never met a company owner who asks whether they can afford to do the accounts this year. The books get done because skipping them means fines and a very bad week at tax time. HR gets done because ignoring it ends in a tribunal. Neither is exciting and neither is optional. Security has the same shape. It's boring when it's working, enormously expensive when it isn't, and the technical cleanup is usually the cheap part of the bill. The expensive parts are the customer notification letters, the downtime, the regulator's questions and the clients who quietly don't come back.

The strongest objection I hear is that a small company can't afford a security team. True, and it doesn't need one. What it needs is a named person inside who owns the question, a list of every system it runs and who maintains each one, and a contract with each of those vendors that says what happens on a day like Wednesday. That's a few hours of work and a modest budget line. No department required. The accounting comparison holds here too: most small firms don't employ a CFO, but almost every owner I deal with can tell you who does their books.

And if the vendor is us, I'd genuinely prefer to be asked. A client asking "have you patched PHP2Shell?" is the client doing their part of the job. I don't read it as doubt, and it keeps us honest.

The 98% are probably fine this time. The question worth asking in budget season is whether they'd know.