Did PHP2Shell scare you into turning your site offline? Hire a CTO

Published on: 23-10-2026

When the PHP2Shell vulnerabilities went public this week, websites went dark across Europe - most of them with no sign of an actual attack. The vulnerability wasn't the reason. The reason was that nobody in the building knew the systems well enough, or had the authority, to make a calm call. That's a job, and it has a title: CTO.

Something was finally on fire

Aging software rarely fails. Nothing is on fire, so nothing gets decided. Then, one morning, something is.

A satirical video that made the rounds this week captures it well. Security calls at 6:12 a.m.: patch every PHP server, now. How many are there? According to the inventory, twelve. According to reality, nobody knows.

For a lot of organizations, that wasn't satire. In the UK, 32 government services went offline and four more were partially down. Government sites in Germany, France, Belgium, Finland and the Netherlands followed. Yet a UK minister told the House of Lords the government was not aware of any confirmed compromise of central government systems. The outages were precautionary.

October 21 was when the general public heard about it. The industry knew earlier. Chainguard's CEO told The Register that rumors started on Monday, October 19, and security firm watchTowr published an FAQ on October 20 - a day before the fix - telling teams to inventory every server running PHP and prepare a rapid update process. That's two days of warning. With a CTO in place, two days is enough to know exactly where you stand by release morning.

So was it security, or was it fear?

What PHP2Shell meant for your business

PHP2Shell is two critical bugs in PHP itself that, when you make bad decisions regarding server security, let an attacker run code on your machine without logging in. They affect a decade of PHP versions. This looked serious.

But how serious it was for you depended on how your servers were set up. Apache with mod_php was the worst case; PHP-FPM was much less exposed. Fixed versions shipped on October 21, with Linux distributions ready on day one.

There's an irony here. mod_php is the old way of running PHP. As far back as 2014, sysadmins were writing that its days were long gone, and by 2020 Fedora had dropped it entirely, noting that running PHP inside the web server's own process increases security risk. A business still running it in 2026 likely has a stack nobody has seriously reviewed in years - exactly the kind of thing a CTO would have flagged long before PHP2Shell.

The catch: anything older than PHP 8.2 got no official patch at all. If your business runs on a legacy platform, there was nothing to install - only something to isolate.

• Know your exposure before the advisory lands. A CTO who knows the stack reads it and sorts every server into patch now, patch today, or isolate - in minutes, not days.

Real or attempted?

The disclosure got messy two days early. Vulnerability IDs leaked with an inflated severity score, a proof-of-concept video was posted by mistake, and one vendor shipped the fix ahead of the agreed release time. Headlines followed: attacks already underway, millions of attempts.

The people reporting on the fix saw something different. At release, heise reported there was no known evidence of attacks in the wild. Christopher Kunz wrote that there was "literally NO proof" of a working exploit in the wild.

Both can be true at once, because an attempt is not a success. Broken payloads hitting your server tell you what attackers are trying, not what works.

Developer Elias Taylor tested the claims directly. Thousands of "proof of concept" exploits appeared on GitHub within hours, and the popular ones he checked didn't work against a standard PHP install - most only succeeded because the test server had first been given a separate, serious vulnerability. Many were AI-generated, with the tool claiming success while quietly weakening the target. Compare that with Log4Shell or Heartbleed, where real attacks were spreading almost as soon as the news broke. The advice was still clear: patch anyway.

• Filter the noise before the business reacts. A CTO knows which sources are close to the facts, reads the advisory instead of the trending post, and has any claimed exploit tested against a safe copy of your stack - asking "real or attempted?" before anyone reaches for the off switch.

Going offline isn't the failure. Staying offline is

The UK's NCSC advised organisations to consider taking an affected system offline until it could be fully mitigated, and the NSA recommended the same where an immediate update wasn't feasible. That's a legitimate tool. The warning sign is having to go dark because you can't patch quickly - or staying dark while the fix is sitting there.

In the video, the patch takes four hours. Finding out where PHP actually runs takes eleven: a box under someone's desk, a forgotten 2016 employee directory, a server owned by an engineer who left in 2019. Patching was the easy part. Knowing what to patch was the hard part.

The UK government had a week's notice and a response team in place before disclosure. Dozens of services still went down. A week is enough time to build an inventory - if one didn't already exist.

Then there's who decides. In the video, finance asks to wait until the weekend, marketing refuses to take a live campaign down, and the CEO wonders why passwords exist at all. Without technical authority in the room, decisions go to whoever is loudest or most afraid. You get reckless delay or panicked shutdown, and both cost money.

• Give one person the inventory, the owners, and the authority. A CTO turns "unplug everything" into "patch these, isolate those, keep the rest running."

What a CTO does in the first 24 hours

None of this takes heroics. It takes preparation and judgment - which is what you're paying a CTO for.

• Answer "where do we run PHP?" with a query, not a hunt. Keep a live inventory of every server and runtime version, each with a named owner who still works there.
• Read the advisory, not the headlines. Map it to your actual stack in the first hour: mod_php first, PHP-FPM next, unpatchable versions flagged.
• Patch what you can, isolate what you can't. Update internet-facing systems as packages land. Take only the unpatchable systems offline - not the whole business.
• Escalate on evidence, not volume. Failing probes and viral GitHub exploits are expected, and most don't work. Signs of a real compromise trigger the incident plan.
• Give the business one message. What's affected, what's being done, what will be briefly offline, and for how long.

Where to start

PHP2Shell won't be the last event like this, and the next one will move faster - AI is making exploit attempts faster and cheaper. The question isn't whether it comes. It's whether anyone in your business will know what to do on a Tuesday afternoon, instead of switching everything off.

That person doesn't have to be a full-time hire. A part-time or fractional CTO is enough to oversee the organization: own the inventory, set the patching process, and make the call when something like PHP2Shell lands. What matters is that someone holds the role - and the authority that comes with it.

If PHP2Shell showed you servers nobody could patch, that's the bigger problem. Legacy platforms on unsupported PHP versions don't get fixes at all - we've written about why long-term security is impossible for legacy apps. Our Legacy System Health & Migration Audit maps what you're running, what's exposed, and what it would take to fix it - so the next 6:12 a.m. call is a routine one.

If your answer to PHP2Shell was to go offline and wait, the vulnerability wasn't your biggest problem. Hire a CTO.

Sources: The PHP Foundation, watchTowr PHP2Shell FAQ, The Register on the disclosure, Hansard: Cyber Security: PHP Vulnerability, House of Lords, 22 October 2026, NCSC: Critical security issue affecting PHP, NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities, The Register on UK government outages, eBuilder Security on European government outages, heise on the PHP2Shell flaws, Christopher Kunz on chaos.social, Elias Taylor on the missing exploit, Mattias Geniar on the PHP server stack, Fedora: Drop mod_php.