Op 21 oktober bracht de PHP Foundation een update uit die twee ernstige beveiligingslekken in PHP dicht. PHP is de programmeertaal waarmee ongeveer zeventig procent van alle websites is gebouwd. Via de lekken kon een aanvaller van buitenaf de computer overnemen waarop een website draait. Een dag later meldde het NCSC dat het de eerste signalen van geslaagde aanvallen onderzoekt. Bij TIL zien we in dit incident ook een juridische les. Een organisatie die een update voor een ernstig beveiligingslek dagen of weken laat liggen, kan na een hack moeilijk aantonen dat haar beveiliging voldeed aan wat de AVG en de Cyberbeveiligingswet vragen.
Wat er met PHP gebeurde
PHP draait op de server, de computer waarop een website staat. Je ziet het als bezoeker niet, maar het zit in veel webwinkels, klantportalen, intranetten en websites die met WordPress zijn gemaakt. Een lek is een fout in die software waardoor een buitenstaander binnen kan komen. De oplossing is een update, in vaktaal een patch, die de fout herstelt.
De fout in PHP was niet nieuw. Een ontwikkelaar zag de eerste tekenen al in 2024, tijdens een controle van de software door een extern bedrijf. Het herstel liep daarna maandenlang vast. De PHP Foundation, de stichting achter PHP, noemt dat zelf een structureel falen: het beveiligingsteam kwam niet tot een besluit en had te weinig mensen en geld.
In augustus 2026 kwam het probleem terug. Het beveiligingsbedrijf Calif ontdekte met een AI-model van OpenAI hoe je het lek echt kon misbruiken. Het bedrijf Wiz vond daarna nog meer manieren, onder meer met AI-modellen van Google en OpenAI. Kort voor de geplande update lekten de details uit. In Nederland gingen daarop onder meer de websites van het NCSC en de Tweede Kamer uit voorzorg offline.
AI maakte het PHP-lek sneller vindbaar en sneller bruikbaar voor aanvallers
AI werkt hier naar twee kanten. Verdedigers vinden met AI fouten die mensen jarenlang lieten liggen. Aanvallers gebruiken dezelfde technologie om die fouten razendsnel te misbruiken. Cloudflare, een bedrijf dat internetverkeer beveiligt, zag in de tien uur voor de bekendmaking duizenden aanvalspogingen, en kort daarna miljoenen. Het FD noemt cijfers van beveiligingsbedrijf Palo Alto: aanvallers zoeken met AI binnen vijftien minuten nadat een lek bekend wordt naar een manier om binnen te komen.
AI zorgt ook voor veel valse meldingen. De PHP Foundation kreeg tussen juli en half oktober ruim honderd meldingen over lekken die ongeldig of dubbel bleken of niet na te bootsen waren. Het kleine team moet al die meldingen wel beoordelen.
Hoe snel je moet updaten onder de AVG en de Cyberbeveiligingswet
De AVG noemt geen vaste termijn voor het installeren van updates. Artikel 32 AVG verplicht organisaties die persoonsgegevens verwerken tot passende beveiliging. Wat passend is, hangt onder meer af van wat technisch gangbaar is, de kosten en het risico voor de mensen van wie de gegevens zijn. De wet noemt dat eerste punt de stand van de techniek.
Sinds 15 augustus 2026 geldt daarnaast de Cyberbeveiligingswet, de Nederlandse uitwerking van de Europese NIS2-richtlijn. Die wet geldt voor ruim achtduizend organisaties in belangrijke sectoren en verplicht hen tot goede digitale beveiliging. Artikel 21 van de NIS2-richtlijn noemt daarbij uitdrukkelijk de beveiliging bij leveranciers en de omgang met lekken in systemen.
Hoe een rechter naar zulke open normen kijkt, blijkt uit een uitspraak van het Europese Hof van Justitie, HvJ EU 14 december 2023, C-340/21, ECLI:EU:C:2023:986, r.o. 30-32. Een geslaagde hack betekent volgens het Hof niet automatisch dat de beveiliging tekortschoot. De rechter beoordeelt dat per geval, en de organisatie moet zelf aantonen dat haar maatregelen goed genoeg waren. Wie na een hack moet uitleggen waarom een beschikbare update voor een ernstig lek nog niet was geïnstalleerd, heeft daar een lastige taak aan.
Toezichthouders en rechters hebben nog niet bepaald welke updatetermijn passend is. Het is goed denkbaar dat zij tijd gunnen om een update eerst te testen. Toch verwachten wij dat een termijn van dagen of weken voor een ernstig lek moeilijk te verdedigen wordt, nu aanvallers binnen een kwartier aan de slag gaan. Dat geldt zeker als het NCSC uitdrukkelijk heeft geadviseerd direct bij te werken of systemen offline te halen.
Een lek in de software is nog geen datalek
De Autoriteit Persoonsgegevens kreeg in de eerste dagen geen datalekmeldingen over PHP binnen. Een woordvoerder wees erop dat een lek in software niet vanzelf een datalek is. Organisaties moeten dat zelf beoordelen. Een meldplicht ontstaat pas als er aanwijzingen zijn dat iemand echt is binnengekomen en persoonsgegevens kon inzien of meenemen. Dan moet je dat binnen 72 uur melden bij de AP, op grond van artikel 33 AVG. Valt je organisatie onder de Cyberbeveiligingswet, dan kan daarnaast een meldplicht voor ernstige incidenten gelden. Leg ook vast waarom je niet hebt gemeld en wanneer je de update hebt geïnstalleerd. Met die aantekeningen kun je later laten zien dat je zorgvuldig hebt gehandeld.
Opvallend is hoe weinig verplichtingen er liggen bij de beheerders van PHP zelf. PHP is opensourcesoftware: iedereen mag het gratis gebruiken en aanpassen, en een kleine groep ontwikkelaars onderhoudt het. Sinds 11 september 2026 moeten makers van software op grond van de Europese Cyber Resilience Act lekken melden die actief worden misbruikt. Voor stichtingen die opensourcesoftware beheren, geldt een veel lichtere regeling, zonder boetes. Of de PHP Foundation onder die lichtere regeling valt, is nog niet beslist.
De verantwoordelijkheid ligt dus vooral bij de organisaties die de software gebruiken. Dat raakt er veel. Volgens beveiligingsbedrijf Hadrian draait ongeveer dertig procent van de websites op een oude PHP-versie waarvoor de update niet werkt. Volgens Black Duck bevat negentig procent van de commerciële software opensourceonderdelen die meer dan vier jaar oud zijn, zo meldt het FD. Tweede Kamerlid Barbara Kathmann heeft in Kamervragen gevraagd of wetten en beleid strenger moeten worden.
Afspraken met IT- en AI-leveranciers na het PHP-lek
De meeste organisaties beheren PHP niet zelf. Het zit in de website, het klantportaal of een programma van een leverancier. Het NCSC heeft een stappenplan voor het PHP-lek gepubliceerd dat onderscheid maakt tussen systemen die je zelf beheert en systemen waarvoor je van een leverancier afhangt. Voor juristen zit het werk vooral bij die leveranciers.
Een verwerkersovereenkomst moet op grond van artikel 28 lid 3 AVG al bepalen dat de leverancier passende beveiliging treft en je helpt bij meldingen. Het PHP-lek laat zien dat zo'n algemene afspraak weinig houvast geeft als het erop aankomt. Deze punten verdienen aandacht in nieuwe en lopende contracten:
binnen hoeveel tijd de leverancier een update installeert, met voor ernstige lekken een termijn in uren
dat de leverancier je direct informeert over een ernstig lek, ook als er nog niets mis is gegaan
wat er gebeurt met verouderde software die geen updates meer krijgt
of de leverancier een systeem zelf offline mag halen, en wie de schade daarvan draagt
een overzicht van de onderdelen waaruit de software bestaat, zodat je bij een volgend lek snel ziet of jij geraakt bent
Dat geldt ook voor AI-tools. Die draaien op dezelfde soort servers als elke andere website of applicatie. Een aanvaller die zo'n server overneemt, kan bij alles wat daarop staat. Voor organisaties met een geheimhoudingsplicht weegt dat zwaar bij een klantportaal of documentsysteem met vertrouwelijke stukken. Vraag je leveranciers daarom wanneer zij de PHP-update hebben geïnstalleerd, en neem dat mee in de toets die wij eerder beschreven voor software-updates die AI toevoegen aan bestaande software. Leg in je AI-beleid en beveiligingsbeleid vast wie mag besluiten een systeem offline te halen. Bij een volgend lek moet dat besluit binnen minuten kunnen vallen.