Naar inhoud
IT-Checklist

PHP-lek: waarom DigiD en RTL offline gingen en wat jij met je website doet

Laatst bijgewerkt op

Lees de uitgebreide versie

Op woensdag 21 oktober 2026 gingen in Nederland ineens tientallen websites op zwart. DigiD, MijnOverheid, de Tweede Kamer, RTL Nieuws, Tweakers, ziekenhuizen en gemeenten. Ze waren niet gehackt. Ze haalden hun sites zelf offline, uit voorzorg, omdat er twee ernstige lekken in PHP zaten. Draait jouw website op WordPress? Dan draait hij ook op PHP.

Wat er aan de hand was

PHP is de programmeertaal onder ongeveer 70 procent van alle websites (NOS (opent in nieuw venster)). WordPress, Drupal en Joomla draaien erop, en heel veel webwinkels ook. Door de twee lekken, samen PHP2Shell genoemd, kan een aanvaller met een gewoon webverzoek eigen code op de server laten draaien. Inloggen hoeft niet. Zo komt hij bij de bestanden, wachtwoorden en sleutels van je website (CERT-EU (opent in nieuw venster)). De fout zat er al meer dan tien jaar in (Wiz (opent in nieuw venster)).

Onderzoekers vonden de lekken in augustus met hulp van AI. Op dinsdagavond 20 oktober lekten er details uit, voordat de reparatie klaar was. Het NCSC schreef dat vermoedelijk ieder systeem met PHP dat vanaf internet bereikbaar is kwetsbaar was. Veel organisaties wachtten daarom niet af. Woensdagmiddag kwam de update uit en vanaf het eind van de middag gingen de eerste sites weer online (NOS (opent in nieuw venster)).

Waarom een WordPress-update niet genoeg is

Het lek zit in PHP zelf, de software op de server waarop WordPress draait. Een update van WordPress, je thema of je plug-ins verandert niets aan de PHP-versie (Hackread (opent in nieuw venster)). Die moet je hostingpartij of je webbouwer bijwerken.

Veilig zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 (CERT-EU (opent in nieuw venster)). PHP 8.1 en ouder krijgen geen gewone updates meer. Draai je zo'n versie, dan moet je naar een nieuwere. Instellingen aanpassen of een firewall zoals die van Cloudflare maakt een aanval moeilijker. Het lek blijft dan wel open.

Wat je nu doet

  1. Zoek uit welke PHP-versie je site gebruikt. Kijk in het beheerpaneel van je hostingpartij of vraag het je webbouwer. In WordPress staat het bij Sitediagnose (Site Health), onder Info en dan Server.

  2. Vraag je hostingpartij of de update erop staat. Noem de versienummers hierboven. Heb je zelf een server of VPS, installeer dan de update van je Linux-distributie en herstart PHP.

  3. Draai je PHP 8.1 of ouder? Plan de overstap. Test eerst op een kopie van je site, want oude plug-ins werken niet altijd op een nieuwe versie.

  4. Kijk of er al iemand binnen is geweest. "Een patch dicht het lek, maar maakt een eerdere inbraak niet ongedaan", zei ethisch hacker Wouter van Dongen (RD (opent in nieuw venster)). Let op onbekende beheerders en nieuwe of gewijzigde bestanden. Twijfel je, vernieuw dan je wachtwoorden en API-sleutels.

  5. Zorg voor een back-up die niet op dezelfde server staat. Dan kun je terug naar een schone versie als het toch mis is gegaan.

Zet je website in je noodplan

Bij een noodplan denken veel kleine bedrijven aan ransomware op de laptop. Deze week liet zien dat ook je website ineens offline kan moeten, zonder dat jij iets fout deed. Klanten zoeken je telefoonnummer op je site en je webwinkel neemt geen bestellingen meer aan.

Daarom hebben we het noodplan cyberaanval uitgebreid met een deel over je website. Je schrijft vooraf op wie je site offline kan halen en waar een simpele noodpagina klaarstaat. Zo'n pagina is één HTML-bestand met je naam, telefoonnummer en e-mailadres, zonder PHP en zonder database. Zet hem bij een andere partij neer dan je gewone hosting, dan heb je hem ook als die partij plat ligt.

Download en print het noodplan cyberaanval

Een checklist van een paar pagina's die je één keer invult en daarna print. Met de eerste stappen, een lijst met contactpersonen en de meldtermijnen.

Naar het noodplan cyberaanval

Wil je weten hoe je ervoor staat? Doe de gratis IT-check en kijk in de checklist leveranciers en cloud wat je met je hostingpartij afspreekt.

Uitgebreide versie: de details

Voor wie meer wil weten: technische details, de schade en de bronnen.

De twee lekken

Het gaat om CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) en CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp). Het PHP-beveiligingsteam gaf ze allebei een CVSS-score (versie 4.0) van 9,2 (php.net (opent in nieuw venster)).

CVE-2026-109618: fout bij een geheugentekort

PHP bewaakt de geheugenlimiet (memory_limit) met longjmp(). Gaat een verzoek over die limiet, dan breekt PHP het meteen af. Dat kan gebeuren terwijl PHP nog bezig is met het inlezen van een formulier met een bestandsupload. Bij het opruimen geeft PHP dan geheugen vrij dat nooit goed is klaargezet. Daarin kan nog data van de aanvaller staan uit een eerder verzoek (CERT-EU (opent in nieuw venster)).

CVE-2026-109619: verwijzingen die blijven hangen

Een verzoek laat soms interne gegevens achter, bijvoorbeeld na een fatale fout. Het geheugen is dan al vrijgegeven, terwijl de verwijzing ernaar blijft staan. Een volgend verzoek op dezelfde worker gebruikt die verwijzing voordat PHP hem opnieuw instelt (php.net (opent in nieuw venster)).

Wat Wiz liet zien

Wiz werkte vier fouten uit. Ze gaan allemaal mis als PHP midden in een verzoek stopt door een fatale fout of een geheugentekort (Wiz (opent in nieuw venster)).

  • Een use-after-free in de upload-voortgang van sessies (session upload progress). Samen met het geheugenlek hieronder kreeg Wiz zo zonder inloggen code aan de praat op WordPress, Drupal en Joomla.

  • Een geheugenlek via de cookie PHPSESSID. Bij een multipart-upload kan PHP stukken vrijgegeven geheugen terugsturen in die cookie. De website hoeft zelf geen sessies te gebruiken. Wiz las zo geheugen van andere verzoeken uit, met wachtwoorden, tokens en API-sleutels.

  • Een use-after-free in de backtrace van de laatste fatale fout. Daarmee nam Wiz Drupal over.

  • Type confusion in OPcache, de cache die gecompileerde PHP-code in gedeeld geheugen bewaart. Mislukt een geheugenaanvraag op het verkeerde moment, dan kan een andere worker een plek die als vrij staat gemarkeerd voor iets anders gebruiken. Daarmee nam Wiz WordPress over.

Volgens Wiz was zelfs een simpele "Hello World"-pagina op een kwetsbare PHP-versie aan te vallen. Er bestaan meer varianten. De update pakt de oorzaak aan en dicht ze volgens Wiz allemaal.

Welke servers het meeste risico lopen

Elke PHP-installatie die webverzoeken afhandelt, loopt risico. Dat zijn PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. PHP noemt mod_php het gevaarlijkst. Daar werkt de aanval met één verzoek zonder inloggen, nog voordat er code van de website draait (php.net (opent in nieuw venster)). Bij PHP-FPM moet de website zelf een geschikte handeling uitvoeren. Meer workers verlagen de kans per verzoek, het lek blijft bestaan (Hackread (opent in nieuw venster)).

Een aanvaller krijgt de rechten van het webproces. Daarmee kan hij bij de bestanden en wachtwoorden waar dat proces bij kan. Beheerder van de hele server is hij daarmee nog niet vanzelf (Hackread (opent in nieuw venster)). PHP zit ook in apparaten, netwerkspullen en beheerschermen. Het NCSC houdt op GitHub een overzicht bij van zulke producten (NCSC (opent in nieuw venster)).

Getroffen en gerepareerde versies

Volgens Wiz is bijna elke versie vanaf PHP 5.4 geraakt door minstens één van de fouten. De reparatie zit in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 (php.net (opent in nieuw venster)).

PHP 8.1 en ouder krijgen van het PHP-project geen updates meer. Voor 7.4, 8.0 en 8.1 kwamen er kleine broncode-patches voor wie PHP zelf bouwt. Linux-distributies en leveranciers van langdurige ondersteuning kregen de patches vooraf en leveren soms ook backports voor oude versies. De pakketbron rpms.remirepo.net, die vrijwilligers bijhouden, had op de dag zelf nog geen updates. PHP raadde aan over te stappen op de pakketten van je distributie of zelf te bouwen. Let ook op de kalender: PHP 8.2 krijgt na 31 december 2026 geen updates meer (php.net (opent in nieuw venster), CERT-EU (opent in nieuw venster)).

Tijdelijke maatregelen en waarom ze niet genoeg zijn

Kun je niet meteen updaten, dan geeft PHP een paar maatregelen. Ze maken een aanval moeilijker. PHP schrijft er zelf bij dat je installatie er niet veilig door wordt (php.net (opent in nieuw venster), CERT-EU (opent in nieuw venster)).

  • Zet session.upload_progress.enabled=0 in php.ini, de FPM-pool of de serverconfiguratie en herstart elke worker. Via ini_set() of .user.ini werkt het niet. Dit blokkeert alleen de bekende route via sessies.

  • Zet op PHP 8.5 fatal_error_backtraces=0 en herstart elke worker. Dit blokkeert alleen de route via de backtrace van fatale fouten.

  • Zet post_max_size op 8M als je geen uploads hebt, of 32M als je ze wel hebt. Houd upload_max_filesize daaronder. Stel op de webserver of proxy ook grenzen in voor de grootte van verzoeken en het aantal velden en multipart-delen.

  • Zet memory_limit=-1 via php_admin_value, zodat een website het niet kan terugzetten. Een geheugentekort op een lager niveau kan de foute code nog steeds bereiken. Gebruik geen RLIMIT_AS of RLIMIT_DATA, want die kunnen juist zo'n tekort veroorzaken. Een container- of cgroup-limiet die alleen de getroffen worker stopt, mag wel.

  • Foutmeldingen verbergen met error_reporting, display_errors of @ helpt niets.

Cloudflare zette regels in zijn firewall, ook voor klanten met een gratis abonnement. Cloudflare noemt dat zelf een noodoplossing. Het helpt alleen als je server uitsluitend verkeer via Cloudflare aanneemt (Patchstack (opent in nieuw venster)).

Werd het lek al misbruikt?

Daarover verschillen de bronnen. Het NCSC zag woensdagmiddag nog geen actief misbruik (NOS (opent in nieuw venster)). Cloudflare zag om 9.43 uur de eerste aanvallen (RD (opent in nieuw venster)). Patchstack kreeg 's ochtends meldingen van hostingpartijen, maar zag halverwege de middag in de eigen gegevens alleen aanvallers die rondsnuffelden (Patchstack (opent in nieuw venster)). Het AD sprak een platformbeheerder bij wie tientallen bots ieder uur wel honderd keer probeerden binnen te komen (AD (opent in nieuw venster)). Het NCSC verwacht dat aanvallers deze lekken nog lang zullen proberen te gebruiken (RD (opent in nieuw venster)).

De aanval gebeurt onder de website, dus in de logboeken van WordPress of Drupal zie je weinig. Wiz noemt een paar signalen (Wiz (opent in nieuw venster)).

  • Vreemde multipart-verzoeken, gevolgd door meldingen over de geheugenlimiet of herhaalde HTTP 500-fouten.

  • PHPSESSID-cookies in antwoorden van je server die ongewoon groot of raar opgebouwd zijn.

  • PHP-workers die zonder duidelijke reden opnieuw starten.

Patchstack raadt aan een server die kwetsbaar was te behandelen als gehackt en de wachtwoorden en sleutels op die server te vervangen (Patchstack (opent in nieuw venster)).

Tijdlijn

De rol van AI

Wiz gebruikte zijn eigen systeem Wiz Atlas en de AI-modellen Gemini 4 Argon van Google en GPT-5.6 Sol van OpenAI. Die hielpen bij het vinden van de fouten, het aanpassen van aanvallen aan verschillende versies en instellingen en het controleren van de reparatie. Werkende aanvallen op meerdere systemen had Wiz binnen uren. Eén onderzoeker deed in een week wat een topteam vroeger maanden kostte (Wiz (opent in nieuw venster)).

Dat werkt twee kanten op. Beveiligingsonderzoeker Costin Raiu zei dat AI een race aandrijft om lekken als eerste te misbruiken. Lukasz Olejnik van King's College London zei dat misbruik met AI meteen en op grote schaal kan gebeuren (RTÉ (opent in nieuw venster)).

Hoe andere landen reageerden

In Nederland gingen ook minstens 13 van de 25 veiligheidsregio's offline, net als NotuBiz, het vergadersysteem van meer dan honderd gemeenten, provincies en waterschappen (RD (opent in nieuw venster)). Verder onder meer de KNVB, de Unie van Waterschappen, het ziekmeldsysteem van UWV, het uploadsysteem van de NPO, Pathé Thuis en goede doelen als KWF en de Hartstichting. De Schiphol-app toonde even geen actuele vluchten (NOS (opent in nieuw venster)). Hostingpartij Mijndomein haalde zijn webhosting en webmail offline (Mijndomein (opent in nieuw venster)). Ahold Delhaize zag geen verband met de aanval op Albert Heijn van anderhalve week eerder (NOS (opent in nieuw venster)).

In België gingen alle Vlaamse overheidssites tijdelijk uit de lucht (NOS (opent in nieuw venster)). Ook de VRT, de FOD Financiën, rechtbanken, e-ID, Smartschool, acht ziekenhuizen, Infrabel, de haven van Antwerpen-Brugge en Rock Werchter gingen offline. Het Centrum voor Cybersecurity België zag woensdag nog geen aanvallen in België (VRT (opent in nieuw venster)). Het Franse ministerie van Binnenlandse Zaken zette al zijn sites in onderhoud. In Finland haalde Valtori overheidsdiensten offline en in Denemarken legde Kombit onder meer het schoolplatform stil. De Japanse premier Sanae Takaichi riep website-eigenaren op de update te installeren (RTÉ (opent in nieuw venster)). In Japan gingen ook hostingpartijen in noodonderhoud (Patchstack (opent in nieuw venster)). De Amerikaanse NSA riep op om te updaten (NOS (opent in nieuw venster)).

Toch reageerden veel landen rustiger dan Nederland. Cybersecuritykenner Sijmen Ruwhof zei tegen het AD dat dat vooral door de media-aandacht kwam. Als DigiD, het NCSC en RTL op zwart gaan, is het voor een IT'er makkelijker om de baas te vragen de eigen site ook uit te zetten (AD (opent in nieuw venster)).

De PHP Foundation

De stichting achter PHP ging diep door het stof. Al in 2024 bestond het vermoeden dat een van de fouten te misbruiken was. Het werk aan een oplossing liep steeds vast, omdat het beveiligingsteam het niet eens werd en te weinig mensen had met de juiste kennis. De stichting noemt dat zelf een structureel falen. Volgens de stichting zette Calif ook per ongeluk te vroeg een video online en brak het bedrijf Chainguard een afspraak om nog niets te publiceren (AD (opent in nieuw venster)). Het beveiligingsteam mag voortaan met een meerderheid besluiten (NOS (opent in nieuw venster)).

Wat het kost

Hoeveel het offline halen van al die sites heeft gekost, weet nog niemand. We vonden op 21 oktober geen betrouwbare schatting. Minister Van Weel van Justitie liet weten dat het offline halen impact heeft op de digitale samenleving (NOS (opent in nieuw venster)). Experts verwachten dat de gevolgen nog maanden doorwerken. Sites die niet snel updaten blijven kwetsbaar, en een eerdere inbraak komt soms pas later aan het licht (RD (opent in nieuw venster)).

Bronnen