AI vond verborgen kwetsbaarheden in PHP. Is jouw SOC er klaar voor?

Beheert je organisatie websites? Dan is de kans groot dat er ergens PHP onder zit. Op 21 oktober 2026 bracht het PHP-project noodpatches uit voor twee kritieke kwetsbaarheden, inmiddels bekend als PHP2Shell. Binnen enkele uren haalden overheden, ziekenhuizen en bekende bedrijven hun websites offline, terwijl hun teams de updates installeerden. Ook in Nederland was de impact direct zichtbaar. Het NCSC en de Tweede Kamer haalden hun website uit voorzorg offline. Het platform voor officiële berichten van ruim honderd gemeenten, provincies en waterschappen werd uitgeschakeld. En delen van het netwerk van universiteiten, hogescholen en onderzoeksinstellingen werden tijdelijk stilgezet.

De krantenkoppen waren heftig, en voor een deel terecht. Maar PHP2Shell laat ook zien wat wél werkt. De organisaties die er goed doorheen kwamen, wisten welke systemen ze draaiden, patchten snel, controleerden hun werk en hielden hun logs nauwlettend in de gaten. Dat zijn allemaal vaardigheden die je mensen kunnen opbouwen. In deze blog lees je hoe.

Wat is PHP2Shell, in gewone taal?

PHP is de programmeertaal achter ongeveer zeven op de tien websites waarvan de servertaal te herleiden is, waaronder sites op WordPress, Drupal, Joomla en Magento (iTWire). PHP2Shell is de naam voor twee kwetsbaarheden in PHP zelf, geregistreerd als CVE-2026-109618 en CVE-2026-109619. Beide krijgen voor impactniveau een score van 9,2 op 10. (Unit 42).

Met beide kwetsbaarheden kan een aanvaller zonder in te loggen eigen code uitvoeren op een webserver. Het lek zit in PHP zelf en niet in een specifieke website. Je lost het dus niet op door je contentmanagementsysteem of de plug-ins bij te werken. Je moet de PHP-interpreter zelf bijwerken.

De omvang is enorm. Palo Alto Networks telde meer dan 22,6 miljoen bereikbare installaties die mogelijk kwetsbaar zijn  (Unit 42). Veel daarvan draaien op PHP-versies die zo oud zijn dat ze geen officiële updates meer krijgen.

Wat gebeurde er, en in welk tempo?

The timeline shows how little warning defenders now get.

De kwetsbaarheden zaten al meer dan tien jaar in de code van PHP. Ze werden gevonden met hulp van AI-modellen. Dat is een van de redenen waarom de tijd tussen ontdekking en aanval zo kort was.

Waarom zijn dit soort aanvallen nu anders?

De grootste verandering is snelheid. AI helpt onderzoekers om oude kwetsbaarheden sneller te vinden. Maar AI helpt aanvallers ook om er sneller werkende aanvallen van te maken. Ismael Valenzuela van Arctic Wolf verwoordde de verschuiving treffend: “De vraag is niet langer hoe snel een patch beschikbaar is, maar hoe snel je ziet waar je kwetsbaar bent en voorkomt dat één gecompromitteerd systeem er vele worden.” (iTWire)

Dezelfde week gaf een inkijkje in hoe volledig geautomatiseerde aanvallen eruitzien. Unit 42 van Palo Alto Networks meldde een aanval op een Europese overheidsinstantie via een kwetsbare PHP-applicatie. Binnen twee uur hadden de aanvallers wachtwoordhashes en geheimen voor multifactorauthenticatie in handen. Unit 42 zag sterke aanwijzingen dat niet een mens achter het toetsenbord, maar een AI-agent de aanval uitvoerde. Inmiddels zegt Unit 42 niet te kunnen bevestigen dat PHP2Shell de toegangsweg was (Unit 42).

Hoe de aanvallers ook binnenkwamen, de les is duidelijk. Een menselijke indringer doet er soms dagen over om van een webserver door te dringen tot de kern van een netwerk. Een geautomatiseerde aanval kan dat in één middag. Beveiliging die erop rekent dat iemand morgenochtend een melding opmerkt, is dus al te traag.

Vijf stappen om direct aan de slag te gaan

Het goede nieuws: de oplossing is er en de stappen zijn bekend. Werken je teams deze vijf stappen af, dan is het acute lek gedicht en ben je beter voorbereid op de volgende keer.

1. Werk PHP zelf bij, niet alleen je website. Stap over op een gepatchte versie en bouw containerimages opnieuw. Herstart daarna webservers en PHP-workers, zodat de patch ook echt actief wordt. Controleer welke versie draait, niet alleen welke versie is geïnstalleerd.
2. Spoor PHP op waarvan je niet wist dat je het had.  Appliances, hostingpanelen, cloudimages en producten van leveranciers bevatten vaak PHP. Vraag je leveranciers om te bevestigen dat ze hebben gepatcht.
3. Houd de webomgeving gescheiden. Webservers mogen niet rechtstreeks bij directoryservices en domeincontrollers kunnen. Beperk waarmee ze verbinding kunnen maken, binnen en buiten je netwerk.
4. Ga ervan uit dat inloggegevens zijn uitgelekt. Stond een PHP-server na 17 oktober nog ongepatcht? Vervang dan de databasewachtwoorden, de inloggegevens van serviceaccounts en de API-sleutels waar die server bij kon. Registreer ook alle authenticatiegeheimen die erop stonden opnieuw.
5. Kijk terug, niet alleen vooruit. Bewaar je logs en controleer ze op sporen van een eerdere inbraak: onverwachte processen die PHP heeft gestart, ongebruikelijke uploadverzoeken en workers die herhaaldelijk crashen. Een geslaagde patch is op zichzelf nog geen reden om het ticket te sluiten.  

Wat betekent dit onder de Cyberbeveiligingswet?

Sinds 15 augustus 2026 geldt in Nederland de Cyberbeveiligingswet (Cbw), de Nederlandse uitwerking van de Europese NIS2-richtlijn. De wet geldt voor ruim 8.000 organisaties in 18 sectoren, van zorg en energie tot digitale infrastructuur en overheid. Valt jouw organisatie onder de Cbw, dan is een incident als PHP2Shell meer dan een technisch probleem. Door de zorgplicht moet je aantoonbaar je risico’s beheersen, ook in je toeleveringsketen. Dat geldt dus ook voor de PHP in producten van je leveranciers. Leidt een aanval tot een significant incident, dan moet je dat melden: een vroegtijdige waarschuwing binnen 24 uur, een vervolgmelding binnen 72 uur en een eindverslag binnen één maand. Het bestuur is eindverantwoordelijk voor het beheer van cyberrisico’s en moet daarvoor zelf een training volgen. Zijn bij een inbraak ook persoonsgegevens buitgemaakt, dan kan daarnaast de meldplicht voor datalekken uit de AVG gelden: binnen 72 uur bij de Autoriteit Persoonsgegevens. Breng je zelf software of apparaten met PHP op de Europese markt? Dan moet je sinds 11 september 2026 actief misbruikte kwetsbaarheden ook melden onder de Cyber Resilience Act.

Hoe helpt Global Knowledge je teams?

Patchen dicht dit lek. Het volgende incident komt op dezelfde manier, en de tijd tussen bekendmaking en aanval meten we inmiddels in uren. Wat de schade beperkt, zijn mensen die in elke fase weten waar ze op moeten letten: van de kwetsbare server tot in de boardroom.

Global Knowledge biedt cybersecuritytrainingen onder leiding van ervaren docenten, afgestemd op elk van die fasen. Hieronder zie je welke training bij welke fase past.

Alle trainingen worden live gegeven door docenten die zelf in het vak werken, en de meeste bereiden je voor op een erkende certificering. Je volgt ze klassikaal, in de Virtual Classroom of als private groepstraining voor je organisatie. Zo kan een team samen trainen in de fase waar het nog het minst sterk staat.

Het volgende lek komt eraan. Je teams moeten er klaar voor zijn.

Greg Brockman van OpenAI verwacht dat er de komende maanden nog veel meer van dit soort kwetsbaarheden boven water komen (iTWire). Dat is geen reden voor paniek. Het is wel een reden om ervoor te zorgen dat de mensen die je weblaag, je identiteitssystemen en je securityoperations beheren precies weten wat ze moeten doen als de volgende melding binnenkomt.

Weet je niet zeker waar de kennishiaten in je teams zitten? Neem contact op met ons team. We brengen voor je web-, identity- en securityteams in kaart hoe ze ervoor staan in de vijf fasen hierboven. Daarna stellen we een leertraject voor dat past bij hoe je werkt.

 _Sources

• Unit 42 threat brief: Critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619 (updated 25 October)
• iTWire: PHP2Shell, the 14-year-old bugs that pulled government sites worldwide offline