Als er een kritieke kwetsbaarheid opduikt, denken de meeste IT-beslissers dat het om een race gaat: sneller patchen dan de aanvaller. Op 21 oktober 2026 viel er weinig te racen: de patch liet nog uren op zich wachten, de autoriteiten zeiden "haal alles offline" en de telefoon stond roodgloeiend. Wat hield onze klanten dan echt veilig?
De dag in één oogopslag
| Tijd | Wat er gebeurde |
|---|---|
| Di 20 okt | Eerste geruchten over PHP. Het SOC houdt de situatie nauwlettend in de gaten. |
| Wo 21 okt, 11:00 | Bevestigd: twee kritieke kwetsbaarheden. Het SOC wordt ingelicht en volgt de situatie actief. |
| 13:45 | Lars Nobelen (CTI-specialist) activeert het CSIRT, ons incidentresponseteam. |
| 14:00 | Het Nationaal Cyber Security Centrum adviseert: haal PHP-systemen offline. Klanten beginnen te bellen. |
| 15:00 | Jelle Konings (SOC Security Optimization Specialist) toetst met behulp van AI elk PHP-product dat we beheren aan het nieuwe lek. |
| 15:15 | Onze eigen Filer-dienst wordt offline gehaald, voor elke klant. |
| 15:45 | PHP komt met de verwachte patch. |
| 16:00 | De meeste klanten weten waar ze staan. Hun leveranciers hebben nog niets gezegd. |
| 17:15 | 132 exploits op GitHub. Zo'n 80% werkt niet. |
| 18:00 | Palo Alto Networks: ook PAN-OS is geraakt. Onze klanten lopen geen risico. |
| 18:15 | Elke klant die risico liep, heeft van ons gehoord. Aiden, onze AI-assistent, beantwoordt de rest. |
Woensdag 21 oktober
"Halen we alles offline?"
Het is woensdagmiddag. Twee kritieke kwetsbaarheden in PHP, CVE-2026-109618 en CVE-2026-109619, met de bijnaam PHP2Shell, zijn openbaar geworden. Beide scoren boven de 9 op een schaal van 10. Geen wachtwoord nodig. Wie binnenkomt, krijgt alles.
Een groot deel van het internet draait op PHP: websites, klantportalen, appliances, de beheerpagina's van netwerkapparatuur. Het Nationaal Cyber Security Centrum (NCSC) adviseert PHP-systemen offline te halen.
Onze klanten bellen. Elke CIO stelt dezelfde vraag: "Halen we alles offline?"
Illustratief: zo kwamen de vragen die middag binnen via ons AUXO™-portaal.
Voor een CIO is dat geen securityvraag. Elk systeem dat je offline haalt, is een bedrijfsproces dat stilvalt. Haal je te weinig offline, dan riskeer je een inbraak. Haal je te veel offline, dan leg je jezelf plat.
Terugblik
Het antwoord lag er al jaren
We wisten al waar PHP draait in de omgevingen die we beheren. Elk van die systemen staat in een eigen Protect Surface: een strak afgebakende zone rond iets kritieks. De firewall aan de rand laat alleen door wat dat systeem echt nodig heeft.
Niet doordat we snel patchten. Wel door keuzes die we jaren eerder maakten. Twee daarvan maakten dit keer het verschil.
Keuze één
Jaren geleden stelde een engineer Filer, de bestandsdeeldienst in ons AUXO™-portaal, zo in dat die elk verzoek weigert dat veel groter is dan normaal. PHP2Shell heeft precies dat nodig: een te groot verzoek.
Keuze twee
Op elke firewall die we beheren is de management interface alleen bereikbaar vanuit ON2IT en vanuit een netwerk dat de klant daarvoor aanwijst. Niet vanaf internet. Niet vanuit de rest van het netwerk van de klant.
Dat is Zero Trust: alleen toestaan wat echt nodig is, ook als je nog niet weet waartegen het je beschermt. De aanval kon nergens toeslaan.
Maar weten waar PHP draait, is iets anders dan aantonen welke systemen dit specifieke lek kan bereiken. Op woensdagmiddag kon niemand dat nog aantonen. Daar kwam AI in beeld.
Het uur dat de vraag van 14:00 beantwoordde
Een uur in plaats van een week
Jelle Konings, SOC Security Optimization Specialist, krijgt de lastigste klus: voor elk PHP-product dat we beheren uitzoeken of het kwetsbaar is voor dit lek. Welke versies? En wie moet in actie komen: de klant, de leverancier of wij?
Tijdens Log4Shell in 2021 kostte het ons weken om dat te beantwoorden.
Dit keer opent Jelle een AI-assistent die onze wereld kent: elk product dat ON2IT beheert, hoe het is opgebouwd en wat we ermee doen. Hij geeft de assistent zijn opdrachten, product voor product. Welke versies zijn geraakt? Wat zegt de leverancier, en wat leren de afgelopen jaren ons? Is het een clouddienst die de leverancier moet patchen, of kunnen we zelf iets doen?
"Normaal kost het dagen om dat uit te zoeken", zegt Jelle. "Nu hadden we binnen een paar minuten een eerste werklijst."
Daarna het controlewerk. Engineers verifiëren elk antwoord, en Jelle test specifieke aanvalsscenario's in ons lab, op dezelfde apparatuur die we voor klanten beheren.
Liever offline dan achteraf spijt
Ondertussen kijken we naar onszelf. Filer draait op PHP. Is die dienst kwetsbaar? Dat weten we nog niet.
Dus gaat Filer offline. Voor elke klant. De laatste instantie om 15:15.
Was dat nodig? "Dat weten we niet. Zo simpel is het", zegt Lars. "Niemand heeft bewijs laten zien van een geslaagde aanval. Maar dit is zo'n beetje de ergste kwetsbaarheid die je kunt hebben. Als betrouwbare partijen offline gaan en er blijven meldingen van aanvallen binnenkomen, dan gaan wij ook offline."
Later blijkt dat de groottelimiet Filer al die tijd heeft beschermd. Maar "waarschijnlijk veilig" is niet goed genoeg als de data van een klant op het spel staat.
Klanten weten het eerder dan hun leveranciers
Een uur nadat Jelle begon, is het beeld duidelijk voor onze klanten met apparatuur van Palo Alto Networks en Fortinet. Vaak nog voordat die leveranciers er zelf iets over hebben gepubliceerd.
Op dat moment krijgt het telefoontje van 14:00 zijn antwoord. Niet "wacht op het advies van de leverancier". Niet "haal voor de zekerheid alles offline". Een antwoord per product: dit loopt risico, dit niet, dit doen wij, dit doe jij.
"Een uur, hooguit anderhalf, en we hadden het grootste deel", zegt Jelle. "Zonder AI: dagen. Misschien een week."
Jelles inschatting van de tijd om het grootste deel van de geraakte producten in kaart te brengen. Schaal indicatief, op basis van een werkweek.
Lars Nobelen, CTI-specialist en die dag CSIRT-lead, is iets voorzichtiger: "Tien tot vijftien uur werk van een engineer. Met alles wat er verder bij een incident speelt, ben je drie dagen verder voordat je het volledige beeld hebt." En het gaat niet alleen sneller. "Je kunt het veel specifieker maken dan we ooit met de hand konden."
Het NCSC deelde om 15:41 een eigen lijst met waarschijnlijk kwetsbare producten. Veel van de producten die wij beheren, stonden er niet op. We wachtten niet op de lijst van een ander. We hadden ons eigen antwoord.
132 exploits, de meeste gelukkig nep
Anderhalf uur na de patch staan er op GitHub 132 proofs of concept. Elk daarvan claimt: zo misbruik je PHP2Shell.
Lars Nobelen, CTI-specialist en CSIRT-lead
"Dat hebben we op deze schaal nog nooit gezien. Twee redenen: PHP is enorm. En AI."
- Werkt niet, of richt zich op een andere kwetsbaarheid (~80%)
- Het controleren waard (~20%)
Een echte exploit op GitHub is een startschot. "Binnen een paar minuten zie je overal aanvallen. Mensen zoeken erop en proberen het gewoon." Dus welke zijn echt? Lars laat AI het sorteerwerk doen. Zo'n 80% werkt niet, of richt zich op een heel andere kwetsbaarheid. Een deel is zelfs volledig door AI gegenereerd.
De dag erna stopte het NCSC helemaal met het beoordelen van proofs of concept. Het waren er te veel.
Lars Nobelen, CTI-specialist en CSIRT-lead
"Als aanvallers AI gebruiken, dan moeten verdedigers dat zeker ook doen."
Ook PAN-OS is geraakt
Palo Alto Networks bevestigt: PAN-OS, het besturingssysteem van de eigen firewalls, is kwetsbaar via de management interface. Er komt een fix, maar nog zonder datum.
Voor onze klanten verandert dat niets. Keuze twee, jaren geleden gemaakt. De management interface is alleen bereikbaar vanuit ON2IT en het netwerk dat de klant daarvoor aanwijst.
Iedereen heeft van ons gehoord
Elke klant die mogelijk risico liep, is gebeld. Filer is gepatcht en komt weer online. Ons publieke advies is gepubliceerd.
Klanten met een snelle vraag hoeven niet in de rij te staan. Aiden, de AI-assistent in ons AUXO™-portaal, weet al van PHP2Shell.
"Tijdens een incident werken onze engineers de gewone wachtrij niet meer af", zegt Lars. "Aiden kon zelf cases sluiten, want de vraag was simpelweg: zijn wij kwetsbaar?" Klanten openden 40 tot 50 cases over PHP2Shell. Lars schat dat Aiden bij ongeveer de helft heeft geholpen. Elke case die Aiden afhandelt, betekent een engineer die bij het incident kan blijven.
Dan de conclusie: geen enkele klant onder beheer van ON2IT is direct kwetsbaar. We zien geen golf van aanvallen, en geen teken dat iemand is gecompromitteerd. Hun eigen PHP-applicaties moeten klanten nog wel zelf patchen. We schakelen terug van volle snelheid naar paraatheid: klaar om in te grijpen.
Een deur die geen aanvaller kan bereiken, is een deur die geen aanvaller kan openen.
Wat AI deed
Mensen leidden het incident: wanneer opschalen, wat offline halen, wanneer afschalen. Wat AI deed, was ons tijd teruggeven. Een week uitzoekwerk werd een uur. 132 exploits werden er een handvol die het controleren waard waren. Een wachtrij vol "zijn wij kwetsbaar?" werd een reeks antwoorden, terwijl onze engineers bij het incident bleven.
De rekening voor achterstallig onderhoud
PHP2Shell zal niet de laatste zijn. Een groot deel van het internet draait op code die al jaren geen onderhoud heeft gehad. En met AI aan de kant van de aanvaller worden de scheuren daarin sneller dan ooit gevonden en omgezet in exploits. Reken er vanaf volgend jaar op dat je jaarlijks met een incident als dit te maken krijgt.
We ruimen liever op dan dat we op de volgende wachten. Samen met onze klanten werken we het achterstallige onderhoud weg: oude componenten, functies die niemand gebruikt, toegang die niemand nodig heeft. Alles wat blijft, krijgt een Protect Surface eromheen, zodat het volgende lek nergens kan toeslaan.
Kort gezegd
De patchrace win je niet altijd. Ruim het achterstallige onderhoud op, zet een Protect Surface rond wat blijft, en dan hoeft dat ook niet.
Neem contact op
Lees in ons PHP2Shell-advies wat we klanten die dag vertelden. Of trek dertig minuten met ons uit om te bekijken welke van je kritieke systemen vandaag al binnen een Protect Surface vallen, en welke nog op een opruimbeurt wachten.
Neem contact opVeelgestelde vragen
Wat is PHP2Shell?
PHP2Shell is de bijnaam van twee kritieke kwetsbaarheden in PHP zelf, CVE-2026-109618 en CVE-2026-109619 (CVSS 4.0: 9,2). Ze maken remote code execution mogelijk zonder in te loggen. PHP bracht op 21 oktober 2026 de gepatchte versies 8.2.35, 8.3.36, 8.4.27 en 8.5.12 uit.
Wat hield klanten van ON2IT veilig voordat de patch er was?
Zero Trust-keuzes van jaren geleden. Elk PHP-systeem dat we beheren, zit binnen een Protect Surface. Filer weigerde de te grote verzoeken die PHP2Shell nodig heeft. En de management interface van elke firewall die we beheren, is alleen bereikbaar vanuit ON2IT en een netwerk dat de klant daarvoor aanwijst.
Hoe hielp AI tijdens het PHP2Shell-incident?
AI gaf het team tijd terug. Het in kaart brengen van de beheerde producten die risico liepen, kostte ongeveer een uur in plaats van dagen. AI hielp 132 openbare proofs of concept terug te brengen tot een handvol die het controleren waard waren, en Aiden, de assistent in het AUXO-portaal, beantwoordde routinevragen van klanten. Alle beslissingen werden door mensen genomen.
Bronnen
- Interviews met Lars Nobelen (CTI-specialist en CSIRT-lead) en Jelle Konings (SOC Security Optimization Specialist), ON2IT, oktober 2026. De cijfers over proofs of concept en Aiden komen van het ON2IT CSIRT.
- PHP, Security advisory: critical remote code execution vulnerabilities, update now (21 oktober 2026, Engelstalig)
- NCSC, Operationele informatie over de php2shell-kwetsbaarheden (Engelstalig)
- CERT-EU, Security Advisory 2026-018 (Engelstalig)
- ON2IT, Kritieke PHP-kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 (21 oktober 2026, bijgewerkt 22 oktober)
Karin Muller leidt de marketing van ON2IT, waar ze een AI-first marketingteam bouwt waarin security vanaf het begin is ingebouwd. Ze maakt van thought leadership iets waar sales mee verder kan, met Threat Talks en Hack the Boat als vlaggenschepen.