PHP2Shell and the bank's forgotten side door

On Tuesday, 20 October 2026, two critical flaws in PHP leaked online before they were supposed to. By Wednesday afternoon the PHP team had shipped emergency patches, and by then attackers were already knocking.

PHP is not a niche tool. It runs somewhere around 70% of the world's websites, from your neighbour's WordPress blog to customer portals at regional banks. The pair of bugs, now called PHP2Shell, let an attacker run their own code on a server with a single crafted web request. No login. No click from anyone.

Some organisations didn't wait for the patch. In the Netherlands, several bodies, including the national cyber security centre, simply took their websites offline as a precaution. Think about that for a second: switching off your own front door was the safest option available.

I spent 25 years in enterprise IT, much of it as a solution architect designing systems that were not allowed to fail. Weeks like this are not surprising. What is new is the speed.

PHP2Shell is two bugs in PHP's own engine, tracked as CVE-2026-109618 and CVE-2026-109619 and both rated 9.2 out of 10. They live in memory handling that almost every web request touches, and the oldest affected code goes back to PHP 5.4.

In plain language:

• The first bug happens when PHP runs out of memory halfway through setting up a request. The cleanup that follows treats half-built data as if it were valid.
• The second bug leaves leftovers from one request lying around after their memory has been freed. The next request handled by the same worker can stumble onto them.

Both can be steered into running an attacker's code. They can also be used to read the server's memory, which may hold passwords, API keys and other secrets.

The nasty part is where this happens. The attack lands while PHP is still parsing the incoming request, before the application's own code has even started. So it does not matter how carefully your developers wrote the login page or validated the forms. A hardened custom system is as exposed as a default WordPress install. Laravel, Symfony and WordPress security checks simply aren't awake yet.

The fix is to update: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. The PHP team is blunt that configuration tweaks only narrow specific attack paths and do not make a server safe. And here is the catch for anyone running old systems: PHP 8.1 and older get no official updates anymore. One exposure study counted about 2.24 million internet-facing PHP hosts and found roughly 59% on versions where no upstream fix is coming.

Very few banks run their core ledger on PHP. So why should a CIO in banking lose sleep over this?

Because a bank is never just its core system. Around the vault sits a long tail of web-facing things that nobody draws on the architecture slide:

• marketing sites, campaign pages and loan calculators
• customer portals and onboarding forms at smaller banks and credit unions
• WordPress and other CMS installs run by an agency
• partner fintechs, payment plug-ins and e-commerce integrations
• vendor tools, ticketing systems and internal admin panels someone set up in 2017 and forgot

Each of these can be the side door. And PHP2Shell's ability to read memory makes it worse: a forgotten server that holds an API key to something more important is not a small problem.

This is also where attackers already concentrate. In Akamai's 2026 financial services report, banking took 60% of all web attacks and 83% of attacks against APIs in 2025. 96% of financial services leaders in their survey reported at least one API security incident in the past year, the highest of any industry.

In my experience, the breach rarely comes through the system everyone is watching. It comes through the one nobody owns.

Here is the part that changes the game. A vulnerability used to give defenders weeks, sometimes months. WannaCry hit roughly two months after Microsoft had released the patch. That was the old rhythm: disclose, patch on the next maintenance window, move on.

That rhythm is gone. Check Point estimates the average time from a vulnerability being disclosed to confirmed exploitation fell from 2.3 years in 2018 to about 10 hours in 2026. Microsoft's latest defence report puts the median time to real-world weaponisation at well under a day. With PHP2Shell, one security firm expected mass exploitation within 15 minutes of the patch going public.

Who moves that fast? Not a person reading a bulletin over coffee. Automated scanners watch disclosure feeds around the clock. AI tools can compare the patched code to the old code, work out what was fixed and rebuild the attack from the difference. Agentic AI can then write and test a working exploit with very little human help.

Put that next to PHP2Shell and you see the real risk. It is not one clever hacker. It is automated probes hitting every forgotten PHP server a bank and its partners own, within hours of the patch going public. It only takes one of them to land.

The story has a second side that I find more interesting than the bug itself.

PHP2Shell was not found by attackers. It was found by the security firms Calif and Wiz together with OpenAI, using AI-assisted code auditing. The underlying weakness had actually been flagged in a 2024 audit, but back then nobody could prove it was exploitable. Experts had believed for years that it couldn't be used in practice. The AI-assisted audit showed that it could.

The defensive side also moved fast. Cloudflare had protections in place nine hours before public disclosure. Linux distributions received the patches in advance. As of the patch release, the reported activity was a wave of exploitation attempts, not confirmed break-ins.

So the same technology sits on both sides of the table. AI finds decades-old flaws humans had written off. AI also turns a published fix into a working attack within hours. The tool is neutral. What decides the outcome is who uses it first and who is organised enough to act on what it finds.

It's tempting to read PHP2Shell as a technical story: a memory bug, a patch, done. I think that misses the point. The bug is the symptom. The root cause sits in how organisations think about their own systems.

Three patterns I saw again and again in my enterprise years, and that weeks like this expose:

1. Nobody knows the full inventory. You can't patch what you don't know you run. If a bank can't list every PHP server it and its vendors expose to the internet within an hour, that is the real vulnerability.
2. "Old but working" is treated as safe. That PHP 7 server behind the loan calculator works fine, so nobody touches it. Now it's on a version that gets no official fix. Technical debt isn't a backlog item. It's open exposure with interest.
3. The patch calendar is from another era. Monthly maintenance windows were designed for a world where attacks took weeks. When exploitation starts in hours, the decision chain is the bottleneck, not the technology.

What I would ask any bank leadership team this week:

• Do we have a live, owned list of every internet-facing system, including our vendors' and partners'?
• Who can decide to take a public site offline within an hour, without a committee?
• Which systems are on software versions that no longer receive security updates, and what is the plan and date for each?
• Are our own AI tools pointed at our code before someone else's are?

None of these questions is about PHP. That's the point. PHP2Shell is just the latest code that cracked open a pattern that was already there.

PHP2Shell will be patched. The headlines will move on. But the lesson outlasts the bug: the gap between "a flaw exists" and "a machine is exploiting it" has shrunk from years to hours, and banks sit at the front of the queue.

The winners won't be the organisations with the most security tools. They'll be the ones who know exactly what they run, can make a hard call fast, and stop treating old systems as safe just because they still work. That's not a technology problem. It's a leadership pattern. And patterns, once you see them, can be broken.

Note: this post reflects the situation as of 23 October 2026. Details of PHP2Shell were still developing when it was written.

Henri Isola

The Code Breaker · Holistic & Business Coach

Twenty-five years as a Solution Architect and Senior Technical Expert in enterprise data centers and cloud migrations — IBM, HP, Sanoma, CGI. Now reading human systems instead. Next in the series: Rogue Agents at the Teller Window.