Introduction to the Chaos

Well, I don’t want to say I TOLD YOU SO… but…

Remember all those warnings about technical debt, Shadow IT, and forgotten applications that nobody maintains anymore ? Those systems that have been running quietly for years, often without anyone knowing exactly how they work or who is responsible for them ?

Well, they’re about to become everyone’s problem.

And this time, the culprit is PHP.

PHP has been powering a substantial part of the internet for decades. Websites, online shops, customer portals, internal business applications, and probably that forgotten intranet page somebody built back in 2007. Sometimes you know PHP is running behind the scenes. Sometimes you don’t. And sometimes the only person who knew left the company fifteen years ago.

Which brings us to Patching Wednesday. Because apparently, Patching Tuesday wasn’t enough excitement for one week.

On October 20, 2026, the PHP security team announced two critical vulnerabilities, both rated 9.2 on the CVSS version 4 scale. That’s firmly in the category where security teams start canceling meetings, administrators start checking servers, and management suddenly discovers an interest in software maintenance.

PHP2Shell: What’s Going On ?

The two vulnerabilities, now known as PHP2Shell, affect the PHP engine itself. These aren’t problems caused by a badly written website or an outdated plugin. The flaws are in PHP’s own handling of memory and errors.

The main concern is remote code execution, or RCE. Under certain conditions, an attacker could make a vulnerable server run commands or software of their choosing, potentially without needing to log in first.

Depending on the server’s setup and what the attacker can access, that could mean installing malware, stealing information, changing files, or using the server to attack other systems.

And here’s the unpleasant part. Your website might still appear to be running perfectly fine. It’s just that somebody else could now be telling the server what to do.

The Great PHP Patch Release Chaos

The PHP team originally planned to release the full security details on October 22, 2026. But things didn’t quite go according to plan.

The vulnerability numbers leaked early, along with an incorrect severity score of 10 out of 10. Then a demonstration video appeared before it was supposed to, and patched container images were released ahead of schedule.

So the PHP team moved its security release forward by a day, while software vendors and administrators scrambled to prepare.

Because coordinating an emergency security release across the internet apparently isn’t complicated enough without somebody publishing the answers before the exam starts.

Security agencies warned organizations to patch their systems as quickly as possible. Some even advised taking vulnerable websites offline if they couldn’t be secured in time.

Cloudflare also deployed emergency firewall rules, including protection for customers on its free service. A useful measure, certainly, but not a permanent solution. Firewall rules can help block attacks, but they don’t fix the underlying problem.

For that, you still need to patch PHP. And as we’ll see, that’s where things get interesting.

Finding Vulnerable Systems: The Real Adventure

Installing a security patch sounds simple enough. Download the update, install it, restart the necessary services, and get on with your day.

Except corporate IT rarely works like that.

First, somebody has to find every system running PHP. Not just the public websites, but also internal applications, reporting tools, customer portals, and those little scripts somebody wrote ten years ago to automate a business process.

Then there are the old servers nobody wants to touch. The original developer left the company years ago, the documentation is practically nonexistent, and nobody knows what might break if the software is updated.

And let’s not forget Shadow IT. Those unofficial websites, dashboards, and applications that departments have quietly put into production without involving central IT.

Some of them might still be running. Some might even be accessible from the internet. And the people responsible for patching them may have no idea they exist.

Of course, all of this assumes the company has an accurate list of its systems in the first place.

That’s usually where the first uncomfortable silence begins.

Because you can’t patch a server you don’t know you have.

When Government Websites Go Offline

The impact of PHP2Shell wasn’t limited to IT departments scrambling to install patches. Across Europe, organizations temporarily took websites offline rather than risk leaving vulnerable systems exposed.

The Netherlands, Finland, and Belgium all saw disruptions. Even the Dutch National Cyber Security Centre temporarily took its own website offline.

Here in Belgium, the situation wasn’t much better. By Thursday morning, websites belonging to the federal Finance department, the city councils of Ghent and Brussels, two hospitals in Antwerp, and even the Centre for Cybersecurity Belgium were reportedly still offline.

Yes, even the organizations responsible for cybersecurity were taking their own websites offline.

Meanwhile, Cloudflare reported that attempts to exploit the vulnerabilities across its network had climbed into the millions.

Those were attack attempts, not millions of confirmed breaches. But it certainly showed that attackers weren’t spending their Wednesday afternoon waiting for the next change advisory board meeting.

For once, security teams didn’t have to explain why a critical vulnerability deserved immediate attention. The maintenance pages were doing that for them.

AI Finds a Security Flaw. For Once, That’s Good News.

Here’s an interesting twist. Artificial intelligence actually played a role in uncovering just how serious the PHP vulnerabilities were.

Security researchers used an OpenAI model to help find a working way to exploit one of the flaws. OpenAI also independently reported the underlying problem, while other researchers contributed their own findings.

So yes, AI helped uncover a critical security problem. Which might sound rather strange coming from someone who has spent quite some time complaining about Shadow AI.

But there’s a difference between experienced security researchers using AI as a tool and somebody asking a chatbot to build a customer portal, then putting it online without involving the IT department.

One involves proper research, testing, and responsible disclosure. The other involves a corporate credit card, a cheap hosting account, and somebody announcing that they’ve just revolutionized software development.

And guess which one is more likely to end up as an IT horror story.

And Then GitLab Joined the Party

As if the PHP emergency wasn’t enough excitement for one week, GitLab had its own critical security problem. This time, a remote code execution vulnerability rated a perfect 10 out of 10.

The affected code reportedly dated back to 2014. And some administrators who had already patched GitLab earlier in the month now had another emergency update to deal with.

Because nothing says successful patch management quite like finishing one urgent update and immediately receiving an invitation to the next one.

At this rate, the change advisory board might as well move into the server room.

Technical Debt: The Bill Has Arrived

And this brings us to the real problem behind the PHP2Shell panic: technical debt.

Every organization has some. Old applications, outdated servers, unsupported software, and systems that everyone agrees should have been replaced years ago.

But as long as everything keeps working, nobody wants to spend money on replacing it.

Then a critical vulnerability comes along, and suddenly that ancient PHP application becomes a serious security problem. Except it might not work with a newer PHP version. Its libraries could be outdated, the original developer might have left years ago, and the company that supplied it may no longer exist.

Even though the PHP team provided fixes for supported versions, organizations running older software faced a much harder job. Some fixes were made available for older PHP releases, but installing them wasn’t necessarily straightforward. And temporary workarounds could break applications that relied on the affected features.

Of course, upgrading PHP wasn’t on the corporate roadmap. The Agile team hadn’t scheduled a sprint for it. But I’m sure somebody added it to the backlog.

And that’s the wonderful thing about technical debt. You can postpone paying it for years, but eventually somebody comes looking for the money.

Usually on a Wednesday afternoon.

The real cost isn’t just the emergency patch. It’s the years of delayed upgrades, missing documentation, and neglected maintenance that make a simple security update anything but simple.

PHP2Shell: Attackers Weren’t Waiting

While administrators were preparing for emergency patches, attackers were already testing the vulnerabilities.

Amazon’s threat intelligence team detected an exploitation attempt as early as October 17, several days before the security fixes became available. Other security researchers also reported attempts to exploit the flaws, with activity increasing after the vulnerabilities became public.

A successful attack could allow someone to install malware, steal information, or use a compromised server to attack other systems. And attackers don’t particularly care whether that server belongs to an official corporate application or some forgotten Shadow IT project.

If it’s vulnerable and accessible, it’s a potential target.

At the time of recording, there were no publicly confirmed cases of organizations suffering a breach specifically attributed to PHP2Shell. That doesn’t mean nobody was compromised. It simply means that exploitation attempts and confirmed breaches are two different things.

And as anyone who’s dealt with a security incident knows, the absence of a breach announcement isn’t quite the same thing as the absence of a breach.

After the Panic: The Postmortem

Once the immediate panic is over, the next challenge begins: figuring out what actually happened and what still needs fixing.

Some systems will have been patched successfully. Others may need more work because the applications are too old, the updates haven’t been tested properly, or nobody knows what might break. And somewhere, someone will probably discover a forgotten server running software that hasn’t been maintained in years.

Then come the meetings.

Management wants to know why this happened. Security points to the missing inventory. Operations points to the lack of test environments. Developers point to outdated software and dependencies. And everyone points to the technical debt that’s been sitting in budget requests for years.

There will be discussions about lessons learned, better patch management, and replacing old systems. Someone will propose a plan. Someone else will ask how much it costs.

And once the emergency is over, there’s a reasonable chance that everything will return to business as usual.

Until the next critical vulnerability.

Because fixing the immediate security problem is one thing. Fixing the years of neglect that made it so difficult is quite another.

The Real Horror Story Isn’t PHP

The real horror story here isn’t that PHP had critical security flaws.

Software has bugs. Security vulnerabilities happen, even in software maintained by experienced developers. And sometimes emergency patching is simply unavoidable.

The problem is what happens when that emergency exposes years of neglected maintenance, missing documentation, and systems nobody fully understands.

The horror story is discovering, during an emergency, just how much of your infrastructure you don’t understand, don’t maintain, and can’t safely update.

That’s the part organizations should be worried about. Not just the next critical vulnerability, but whether they’ll actually be ready to deal with it when it arrives.

Until the Next Emergency

To everyone who spent the week finding vulnerable systems, testing patches, and trying to keep production running, congratulations. You’ve earned your weekend. Assuming nothing else breaks before Friday afternoon.

And to those who’ve spent years asking for proper test environments, better documentation, and a budget to replace outdated systems ? You might finally get that meeting you’ve been waiting for.

Of course, don’t expect the budget to be approved.

Unless you’re working somewhere that has to spend its remaining budget before the end of the year. In that case, management might suddenly discover an urgent need to invest in infrastructure before December 31.

Burn, baby, burn.

If you’ve ever spent a weekend patching systems nobody knew existed, or explaining why ten years of technical debt can’t be fixed by Monday morning, we’d like to hear about it.

What’s your worst emergency patching nightmare ? Did everything go according to plan, or did you discover a few skeletons hiding in the server room ?

Share your story with us at https://ithorrorstories.eu. And if you’ve got a particularly good IT horror story, perhaps it’s time you joined us on the podcast.

Finally, if you’re feeling rather smug because your infrastructure doesn’t use PHP, congratulations.

Now go check how many of your applications are still running on Java 8.

---