Het PHP-lek: was DigiD uitzetten de juiste keuze?

Op woensdag 21 oktober gingen de websites van DigiD, MijnOverheid en de Tweede Kamer uit voorzorg offline, net als die van het NCSC zelf. Overheid.nl bleef die hele dag weg. Inloggen met DigiD bij andere diensten bleef volgens de NOS wel werken. Ook ziekenhuizen haalden hun website offline. Ruim honderd gemeenten, provincies en waterschappen delen hun officiële stukken via hetzelfde raadssysteem. Dat was die dag maar deels bruikbaar, omdat de leverancier de updates eerst wilde testen. In België, Finland, Duitsland en Frankrijk gebeurde hetzelfde met overheidswebsites.

De reparatie bestond op dat moment nog niet. Het PHP-project bracht de patch pas aan het eind van die middag uit. Al die diensten gingen er dus uit terwijl er nog niets te installeren viel.

Later die middag reageerde het kabinet voor het eerst. Minister Van Weel liet weten dat het offline halen "impact heeft in onze digitale samenleving". Via zijn woordvoerder liet hij erbij weten: "Er zijn op dit moment gelukkig nog geen signalen dat de kwetsbaarheden actief misbruikt worden." In de loop van de avond kwamen de diensten weer online.

Eerst even: wat is PHP?

PHP is een programmeertaal uit 1995 die draait op de server, niet in jouw browser. Vraag je een pagina op, dan zet een programma op die server de pagina eerst in elkaar en stuurt het resultaat naar jou. Dat programma heet de interpreter en dat is de motor onder de site. De website is de carrosserie. De motor eronder is bij heel veel sites dezelfde: WordPress draait erop, net als Drupal, Joomla en talloze webwinkels.

Daarin verschilt dit van de meeste lekken. Meestal zit de fout in één website, zoals een verouderde plug-in. Dan ben jij kwetsbaar en je buurman niet. Nu zat de fout in de motor, dus moesten heel veel organisaties tegelijk iets doen terwijl de fout niet in hun eigen code zat.

Kwetsbaarheid

We noemen zo'n fout een kwetsbaarheid, maar wat betekent dat nu precies? Denk aan een bakstenen muur die er jaren staat zonder dat iemand erdoorheen komt. Tot iemand ontdekt dat er ergens een gaatje is ontstaan, met een heel eigen vorm. Dat gaatje is de kwetsbaarheid. Op zichzelf gebeurt er nog niets mee. Je hebt een steentje nodig dat precies in die vorm past. In software is dat steentje een klein programma. Wie het heeft, kan naar binnen.

Vanaf het moment dat het gaatje bekend wordt, begint een race. De verdediging wil een stuk steen gieten waarmee de muur weer dicht kan. Dat stuk steen is in software de patch, de update die je installeert. Aanvallers willen juist een steentje dat er doorheen past. Is het gaatje al bekend terwijl de steen van de verdediging er nog niet is, dan heet dat een zero day. Die nul slaat op de makers van de software: die hebben nul dagen gehad om het te repareren.

Bij PHP2Shell was dat net niet zo, want de reparatie lag al klaar en stond gepland. Maar de informatie lekte uit en er ging een video rond met een werkende aanval voordat de patch beschikbaar was. In die uren was het gaatje dus bekend terwijl de muur nog openstond. Daarom kon dat uitlekken zo veel kwaad.

Wat er lek was

Het gaat om CVE-2026-109618 en CVE-2026-109619, samen PHP2Shell genoemd. Zonder inloggegevens kan een aanvaller zijn eigen opdrachten laten draaien op jouw server en geheugen uitlezen. Volgens onderzoeksbureau Sansec kan in dat geheugen van alles staan: wachtwoorden, sessietokens en sleutels uit de verzoeken van andere bezoekers. Elke onderhouden PHP-tak vóór 8.2.35, 8.3.36, 8.4.27 of 8.5.12 is geraakt. Volgens minister Van Weel zijn alle PHP-versies vanaf versie 5 kwetsbaar.

Het eerste signaal lag er al twee jaar. In 2024 stuitte een ontwikkelaar van het PHP-project op het eerste teken van het probleem, terwijl hij een andere bevinding oploste. Daarna bleef het liggen. De PHP Foundation noemt die vertraging zelf "a structural failure". Ook de bekendmaking liep stuk: de nummers lekten twee dagen te vroeg uit en een werkende aanval kwam per ongeluk op video online.

Hoe het beeld daarna verschoof

Donderdag 22 oktober zei het NCSC eerst nog dat het bij pogingen bleef. Later die dag meldde het de eerste signalen van succesvol misbruik te onderzoeken. Vrijdag draaide dat deels terug. In het bijgewerkte alert staat nog één onbevestigde melding uit het buitenland. Het NCSC schrijft erbij dat misbruik ingewikkeld blijkt en dat grootschalig misbruik minder waarschijnlijk is dan eerst ingeschat.

Hetzelfde overkwam een gerenommeerd onderzoeksteam. Unit 42 van Palo Alto meldde op 23 oktober een inbraak bij een Europese overheidsinstantie. Twee dagen later trok het die melding in, omdat het de inbraak niet aan deze twee lekken kon koppelen.

Stand op 26 oktober. Er wordt op grote schaal geprobeerd de lekken te misbruiken en onderzoekers hebben aangetoond dat de aanval werkt. Een slachtoffer met naam is er niet. Dit beeld kan verschuiven, dus kijk voor de actuele stand in het alert van het NCSC en niet in dit artikel.

Updaten is niet hetzelfde als klaar zijn

Updaten is de enige echte oplossing, want volledige tussenoplossingen bestaan niet. Maar drie dingen gaan daarbij in de praktijk mis.

1. Een pakketupdate herstart niet altijd de draaiende workers, de processen die de pagina's in elkaar zetten. Zonder herstart blijft de oude code gewoon in het geheugen staan.
2. PHP 8.1 en ouder krijgen geen reguliere updates meer van het PHP-project. Vanwege de ernst zijn er voor 7.4, 8.0 en 8.1 wel losse broncodepatches gepubliceerd. Een distributie als Debian of Ubuntu kan daarnaast een gepatcht pakket leveren.
3. Patchen maakt een eerdere inbraak niet ongedaan. Ethisch hacker Wouter van Dongen tegen het ANP: "Een patch dicht het lek, maar maakt een eerdere inbraak niet ongedaan."

PHP zit bovendien in apparaten en beheerinterfaces. Daar zitten volgens minister Van Weel oudere versies bij die geen updates meer krijgen. Dan ben je afhankelijk van je leverancier. Beveiligingsexpert Ralph Moonen: "Veel bedrijven weten zelf niet eens waar ze PHP gebruiken."

Was het de juiste keuze?

Nu er bijna een week later nog geen slachtoffer is, dringt de vraag zich op of het nodig was om DigiD uit te zetten. Een onafhankelijk oordeel is er niet: geen toezichthouder en geen onderzoeksrapport heeft zich erover uitgesproken. Wij doen dat hier ook niet. De minister wel: in zijn Kamerbrief noemde hij het goed dat veel organisaties de adviezen van het NCSC opvolgden, al waren die maatregelen niet zonder impact. De precieze maatschappelijke impact van de kwetsbaarheden was volgens hem nog niet duidelijk. Een Kamerlid stelde er schriftelijke vragen over.

Wat wel kan, is kijken naar wat er woensdagmiddag op tafel lag. Bekend was: een lek in de motor onder een groot deel van het web, nog geen reparatie, een hoge ernstscore en een gepubliceerde video waarin een aanval werkte. Onbekend was of er al iemand binnen zat en hoe moeilijk misbruik zou blijken. Dat antwoord kwam pas twee dagen later.

Een besluit beoordeel je niet op de afloop. Dat het achteraf meeviel maakt de keuze van woensdag niet verkeerd, net zomin als een goede afloop een slordig besluit goedmaakt. Wat je wél kunt beoordelen is of het besluit op het juiste niveau viel en of vooraf vastlag wie het mag nemen.

Er is nog iets opvallends aan deze week. Opeens bemoeide de politiek zich met cybersecurity. Er kwamen Kamervragen, er lag een dag later een brief van de minister en de Tweede Kamer had zijn eigen website offline staan. De Duitsers hebben daar een mooi woord voor: Chefsache, iets dat de baas zelf oppakt. Dat vind ik een ontzettend positieve ontwikkeling. Niet omdat die uitval prettig was, maar omdat heel veel mensen nu zelf hebben gevoeld wat digitale afhankelijkheid betekent. Je hoeft niet meer uit te leggen waarom dit op de bestuurstafel hoort.

Vier vragen voor je eigen organisatie

1. Wie mag bij ons besluiten een dienst offline te halen? Wie mag dat bij onze leveranciers? Horen wij het vooraf of achteraf?
2. Zijn de PHP-workers na de update daadwerkelijk herstart? Wie heeft dat vastgesteld?
3. Welke diensten draaien bij ons en bij onze leveranciers op PHP? Met welke versie draait de webserver zelf?
4. Waar zit PHP in apparaten en beheerinterfaces die wij niet zelf kunnen bijwerken?

Het gaat in de praktijk niet mis bij het patchen, maar bij de vraag wie de knoop doorhakt terwijl de informatie onvolledig is en de klok loopt. Al die besluiten vielen in de uren waarin er nog geen reparatie was en geen bewijs van een geslaagde inbraak. Dus: als dit vanmiddag moet vallen en de eerste persoon neemt niet op, wie zet de dienst dan uit?

Over de meldtermijnen die bij zo'n incident gaan lopen schreven we eerder in wat de Cbw concreet van je vraagt. De eerste uren van een incident staan in het datalek stappenplan.