When a critical vulnerability hits, most IT leaders believe the race is about patching faster than the attacker. On October 21, 2026, there was no race to run: the patch was still hours away, the authorities said "take it all offline" and the phones were ringing. So what actually kept our customers safe?
The day at a glance
| Time | What happened |
|---|---|
| Tue 20 Oct | First rumors about PHP. The SOC keeps watch. |
| Wed 21 Oct, 11:00 | Confirmed: two critical vulnerabilities. The SOC is briefed and actively monitoring the situation. |
| 13:45 | Lars Nobelen (CTI specialist) activates the CSIRT, our incident response team. |
| 14:00 | The Dutch National Cyber Security Centre advises: take PHP systems offline. Customers start calling. |
| 15:00 | Jelle Konings (SOC Security Optimization Specialist) and AI check every PHP-based product we manage against the new flaw. |
| 15:15 | Our own Filer service is offline, for every customer. |
| 15:45 | PHP releases the patch. |
| 16:00 | Most customers know where they stand. Their vendors haven't said a word yet. |
| 17:15 | 132 exploits on GitHub. About 80% don't work. |
| 18:00 | Palo Alto Networks: PAN-OS is affected too. Our customers are not exposed. |
| 18:15 | Every exposed customer has heard from us. Aiden, our AI assistant, answers the rest. |
Wednesday, October 21
"Do we take everything offline?"
It is Wednesday afternoon. Two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell, have gone public. Both score above 9 out of 10. No password needed. Whoever gets in, gets everything.
PHP runs a huge part of the internet: websites, customer portals, appliances, the management pages of network equipment. The Dutch National Cyber Security Centre (NCSC) advises taking PHP systems offline.
Our customers call. Every CIO asks the same thing: "Do we take everything offline?"
Illustrative: how the questions came in through our AUXO™ portal that afternoon.
For a CIO, that is not a security question. Every system you pull is a business process that stops. Pull too little and you risk a breach. Pull too much and you have shut yourself down.
Flashback
The answer was set years ago
Here is what we already knew: where PHP runs in the environments we manage. And every one of those systems sits inside a Protect Surface: a tightly bounded zone around something critical, where the firewall at its edge only lets through what that system needs.
Not because we patched fast. Because of choices made years earlier. Two of them mattered most this time.
One
Years ago, an engineer configured Filer, the file-sharing service in our AUXO™ portal, to refuse any request far larger than normal. PHP2Shell needs exactly that: an oversized request.
Two
On every firewall we manage, the management interface can only be reached from ON2IT and from one network the customer designates for it. Not from the internet. Not from the rest of the customer's network.
That is Zero Trust: don't allow what you don't need, even before anyone can tell you why it matters. The attack had nowhere to land.
But knowing where PHP runs is not the same as proving which systems this specific flaw can reach. On Wednesday afternoon, nobody could prove that yet. That is where AI came in.
The hour that answered the 14:00 call
One hour instead of one week
Jelle Konings, SOC Security Optimization Specialist, gets the hardest job: for every PHP-based product we manage, is it vulnerable to this flaw? Which versions? And who has to act: the customer, the vendor or us?
During Log4Shell in 2021, answering that took us weeks.
This time Jelle opens an AI assistant that knows our world: every product ON2IT manages, how it is built and what we do with it. He gives it its orders, product by product. Which versions are affected? What do the vendor and the past years tell us? Is it a cloud service the vendor must patch, or can we act ourselves?
"Normally that takes days to figure out," says Jelle. "Now we had a first worklist within minutes."
Then the checking. Engineers verify every answer, and Jelle tests specific attack scenarios in our lab, on the same equipment we manage for customers.
Better offline than sorry
Meanwhile we look at ourselves. Filer runs on PHP. Is it vulnerable? We don't know yet.
So it goes offline. For every customer. The last instance at 15:15.
Was that necessary? "We don't know. Simple as that," says Lars. "Nobody showed proof of a successful attack. But this is about the worst vulnerability you can have. When trusted parties go offline and attack reports keep coming in, we go offline too."
Later it turns out the size limit had protected Filer all along. But "probably safe" is not good enough when a customer's data is on the line.
Customers know before their vendors do
One hour after Jelle started, the picture is clear for our customers with Palo Alto Networks and Fortinet equipment. Often before those vendors themselves have published a word.
That is the moment the 14:00 phone call gets its answer. Not "wait for the vendor advisory". Not "take it all offline to be safe". A product-by-product answer: this is exposed, this is not, this is what we do, this is what you do.
"One hour, one and a half at most, and we had the bulk," says Jelle. "Without AI: days. Maybe a week."
Jelle's estimate of the time to map the bulk of affected products. Indicative scale, based on a working week.
Lars Nobelen, CTI specialist and CSIRT lead that day, is a little more careful: "Ten to fifteen hours of an engineer's work. With everything else going on in an incident, three days before you have the full picture." And not just faster. "You can make it far more specific than we ever could by hand."
The NCSC shared its own list of likely vulnerable products at 15:41. Many of the products we manage weren't on it. We didn't wait for someone else's list. We had our own answer.
132 exploits, mostly fake
An hour and a half after the patch, GitHub holds 132 proofs of concept. Each one claims: this is how you exploit PHP2Shell.
Lars Nobelen, CTI specialist and CSIRT lead
"We have never seen that at this scale. Two reasons: PHP is huge. And AI."
- Don't work, or target a different vulnerability (~80%)
- Worth checking (~20%)
A real exploit on GitHub is a starting gun. "Within minutes you see attacks everywhere. People search for it and just try it." So which ones are real? Lars lets AI do the sorting. About 80% don't work, or target a completely different vulnerability. At least some were generated entirely by AI.
The next day the NCSC stopped reviewing proofs of concept altogether. Too many.
Lars Nobelen, CTI specialist and CSIRT lead
"If attackers use AI, defenders certainly have to."
PAN-OS is affected
Palo Alto Networks confirms: PAN-OS, the operating system of its firewalls, is vulnerable through the management interface. A fix is coming. No date yet.
For our customers, that is a non-event. Choice number two, made years ago. The management interface is reachable only from ON2IT and the network the customer designates for it.
Everyone has heard from us
Every customer who might be exposed has been called. Filer is patched and coming back online. Our public advisory is out.
Customers with a quick question don't have to wait in line. Aiden, the AI assistant in our AUXO™ portal, already knows about PHP2Shell.
"During an incident, our engineers stop working the regular queue," says Lars. "Aiden could close cases on its own, because the question was simply: are we vulnerable?" Customers opened 40 to 50 cases about PHP2Shell. Lars estimates Aiden helped with about half. Every one of those is an engineer who stays on the incident.
Then the call: not one customer under ON2IT management is directly vulnerable. We see no wave of attacks, and no sign that anyone is compromised. Their own PHP applications are still theirs to patch. We move from full speed to standing watch, ready to act.
A door no attacker can reach is a door no attacker can open.
What AI did
People ran the incident: when to escalate, what to take offline, when to stand down. What AI did was give us time back. A week of research became an hour. 132 exploits became a handful worth checking. A queue of "are we vulnerable?" became answers, while our engineers stayed on the incident.
The bill for overdue maintenance
PHP2Shell won't be the last. Much of the internet runs on code that has gone without maintenance for years. And with AI on the attacker's side, the cracks in it are found and turned into exploits faster than ever. From next year, expect an incident like this every year.
We would rather clean up than wait for the next one. Together with our customers, we are clearing out the overdue maintenance: old components, functions nobody uses, access nobody needs. Everything that stays gets a Protect Surface around it, so the next flaw has nowhere to land.
In short
You can't always win the patch race. Clean up the overdue maintenance, put a Protect Surface around what stays, and you don't have to.
Talk to us
Read our PHP2Shell advisory to see what we told customers on the day. Or take thirty minutes with us to see which of your critical systems sit inside a Protect Surface today, and which are waiting for cleanup.
Talk to usFrequently asked questions
What is PHP2Shell?
PHP2Shell is the nickname for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619 (CVSS 4.0: 9.2). They allow unauthenticated remote code execution. PHP released fixed versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on October 21, 2026.
What kept ON2IT customers safe before the patch existed?
Zero Trust choices made years earlier. Every PHP system we manage sits inside a Protect Surface, Filer refused the oversized requests PHP2Shell needs, and the management interface of every firewall we manage can only be reached from ON2IT and a network the customer designates for it.
How did AI help during the PHP2Shell incident?
AI gave the team time back. Mapping which managed products were exposed took about an hour instead of days, AI helped sort 132 public proofs of concept into a handful worth checking, and Aiden, the assistant in the AUXO portal, answered routine customer questions. People made every decision.
Sources
- Interviews with Lars Nobelen (CTI specialist and CSIRT lead) and Jelle Konings (SOC Security Optimization Specialist), ON2IT, October 2026. The figures on proofs of concept and on Aiden come from the ON2IT CSIRT.
- PHP, Security advisory: critical remote code execution vulnerabilities, update now (October 21, 2026)
- NCSC-NL, Operational information regarding the php2shell vulnerabilities
- CERT-EU, Security Advisory 2026-018
- ON2IT, Critical PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (October 21, 2026, updated October 22)
Karin Muller leads marketing at ON2IT, where she is building an AI-first marketing team with security designed in rather than bolted on. She turns thought leadership into something sales can use, with Threat Talks and Hack the Boat as flagships.