I receive an email from the client. Just a few lines: at 4 pm a very serious PHP vulnerability will be disclosed, and we need to be ready to act. There is no patch to apply yet. Just a deadline on the clock.
The vulnerability is called PHP2Shell and it affects PHP, the language powering a huge part of the web: websites, management systems, portals—applications that generate revenue and drive day-to-day operations. A flaw at that level does not concern one company in particular, but every business built on top of it.
Flawless code is not enough
It is often said that an application’s security depends on the person who writes it. From what I have seen, that is only a half-truth. Every single line of code can be meticulously written and still remain exposed, because the flaw lies in the foundations: in the language or the system running it.
PHP2Shell is actually a pair of flaws that allow remote code execution on a server. The patched versions of the language were released on 21 October. For systems managers, it is the trickiest scenario imaginable: a problem bigger than your own company, arriving from the outside with a deadline dictated by others.
The early hours: understand before acting
While waiting for 4 pm, I did the only sensible thing: understand the anomaly, assess the impact, and identify any applications potentially affected. No blind fixes.
The most critical moment was the wait itself: following security team updates, tracking when fixes would become available, and establishing which of the two scenarios we were facing.
Two worlds, the same hour
In the first world, systems are up to date or running on managed services. Here, no emergency intervention was needed. In the managed environments we use, the necessary fixes were rolled out by the provider without any direct intervention on our part. My job was simply to confirm that the updates were live and that the applications continued to run smoothly.
In the second world are the applications not yet migrated, still lingering on outdated versions. The client had been moving its systems towards more modern solutions, but the migration was not complete. What had been left behind needed to be audited and secured quickly—and for those systems, time became the enemy.
This is where the contrast becomes clear. The exact same event triggered a quick verification on one side and an emergency intervention on the other. The urgency brought a pre-existing need into sharp focus: modernising legacy infrastructure and retiring software that should have been phased out long ago.
Technical debt is not just a modernization talking point: it is a cost that can turn urgent and unpredictable without warning, arriving with a deadline set by someone else.
The people holding up the foundations
There is one thing I learnt from seeing this up close. Fixes for a flaw of this scale come from people who have to pinpoint complex issues, evaluate their severity, and engineer dependable patches against relentless deadlines. It is behind-the-scenes work, yet a vital share of the entire digital ecosystem’s security relies upon it.
And artificial intelligence?
AI is often framed purely as a cybersecurity risk. In this incident, it showed its other face: AI tools were actively used by security researchers to help uncover the flaws before responsibly disclosing them. This does not mean AI is inherently safe, or that it inevitably favours defenders over attackers. It simply means the toolset is shifting on both sides, and that the decisive factor remains an organisation’s ability to validate findings and act in time.
What this means for systems managers
The real takeaway is not technical; it is organisational.
Reliable systems are not those free of vulnerabilities—because such systems do not exist. They are the ones where, when a flaw hits, three things are already crystal clear: what is running, where it is hosted, and who owns it.
Managed services do not eliminate the need for oversight; they make it far more contained and manageable. Maintaining an accurate inventory of applications—including those assumed to have been decommissioned—is what separates a quiet morning from a full-blown crisis.
For us, this vulnerability reinforced the value of an architecture that offloads baseline maintenance to managed services.
If an email like that landed in your inbox tomorrow at 4 pm, how long would it take you to know which of your systems are already covered and which are not?
