Het PHP-lek overleefd: wat je na de PHP-bugs voor je website moet doen

Het PHP-lek van woensdag 21 oktober zette een flink deel van het Nederlandse internet tijdelijk op zwart, en niet door een aanval. De websites van DigiD, MijnOverheid en de Tweede Kamer gingen uit voorzorg offline, net als ziekenhuizen, gemeenten, mediasites en delen van het netwerk van scholen en universiteiten. Hostingbedrijf MijnDomein haalde preventief alle websites die het host uit de lucht, volgens de berichtgeving honderdduizenden. De aanleiding was twee PHP-bugs: kritieke kwetsbaarheden in PHP, de programmeertaal waar 69,3 procent van alle websites op draait, en een beveiligingsupdate die pas om 16.00 uur zou verschijnen.

In de loop van de avond kwamen de meeste sites weer terug. Dit artikel legt uit wat er bij het PHP-lek gebeurde, waarom de PHP-bugs zo’n groot effect hadden en wat je zelf controleert. Het is geschreven op basis van de berichtgeving van woensdagavond 21 oktober 2026. De situatie kan nog veranderen.

Het PHP-lek: wat er woensdag gebeurde

De PHP Foundation wilde de twee bugs eigenlijk donderdag bekendmaken. Eerder in de week lekte echter informatie over de bugfixes uit op Hacker News, in een bericht dat inmiddels is verwijderd, en die informatie ging rond op sociale media. PHP besloot daarom de bekendmaking naar woensdag te halen. Woensdagochtend waarschuwde PHP dat er om 16.00 uur een belangrijke beveiligingsupdate zou komen. Het Nationaal Cyber Security Centrum (NCSC) riep organisaties op zich voor te bereiden en de update direct door te voeren zodra die er was.

Daarna haalden organisaties massaal hun sites offline. Hostingbedrijf MijnDomein deed dat voor alle sites die het host. NotuBiz, het systeem waarmee gemeenten, provincies en waterschappen hun raadsinformatie publiceren, ging uit de lucht, evenals RTL Nieuws, Tweakers, de KNVB en een groot aantal ziekenhuizen. Ook in Japan, Frankrijk en Vlaanderen werden websites offline gehaald, en in Finland kregen overheidswebsites te maken met problemen. Rond 16.00 uur kwam de update online. Aan het einde van de middag en in de avond kwamen de meeste sites terug. Sommige systemen, zoals NotuBiz, wilden eerst testen of de updates goed waren doorgevoerd en komen pas donderdagochtend terug.

CERT-EU, het cybersecurityteam van de Europese instellingen, had de twee kwetsbaarheden al op 20 oktober aangekondigd in beveiligingsadvies 2026-018. Het gaat om CVE-2026-109618 en CVE-2026-109619, beide met een CVSS-score van 9,2. Voor misbruik is volgens het advies geen authenticatie nodig, en alle PHP-versies vanaf PHP 5 zijn getroffen. CERT-EU adviseerde publiek toegankelijke PHP-applicaties tijdelijk van het internet af te schermen totdat de beveiligingsupdates waren uitgebracht en toegepast.

Op het moment van schrijven ziet het NCSC geen actief misbruik, en ook PHP zelf heeft geen aanwijzingen dat de kwetsbaarheden zijn uitgebuit. DPG Media meldt dat er geen incidenten bij zijn sites zijn vastgesteld. Het NCSC noemt de kwestie een weeffout in de programmeertaal en geen aanval.

Hoe het PHP-lek te vroeg uitlekte

In een blogpost legt de PHP Foundation uit dat het in aanloop naar woensdag in meerdere stappen misging. Het begon doordat een van de ontdekkers van de kwetsbaarheden zelf het bestaan ervan te vroeg naar buiten bracht, waarna de twee CVE-nummers voor de kwetsbaarheden gingen rondzingen. Dat laatste is op zich gebruikelijk, want zulke identificatienummers worden vaak al vóór de openbaarmaking bekend. Technische details waren toen nog niet openbaar.

Als reactie op de aankondiging van de patch en het uitlekken van de nummers publiceerden beveiligingsonderzoekers van Calif een dag te vroeg een video met proof-of-conceptaanvallen. Ook advies aan enkele grote infrastructuurproviders lekte vroegtijdig uit. Volgens het onderzoek van de PHP-makers leidde dat nog niet tot aanwijzingen voor werkende exploits. Dat veranderde toen beveiligingsbedrijf Chainguard zijn updates zes uur vóór de afgesproken gezamenlijke release publiceerde. Het bedrijf had vroeg toegang tot de patches gekregen, zodat gebruikers snel konden updaten, maar brak daarmee het embargo.

Het mechanisme erachter is dat een embargo een voorsprong voor verdedigers regelt. Beveiligers en grote providers krijgen de patch eerder dan de rest, zodat ze kunnen updaten voordat aanvallers de details kennen. Elke stap waarin informatie eerder naar buiten komt dan de patch, kort die voorsprong in. Op woensdag was die voorsprong op: er was een proof of concept en nog geen update voor iedereen. Dat is waarom organisaties wereldwijd, waaronder Tweakers, hun sites offline haalden.

Waarom de PHP-bugs zo ernstig waren

Het ging om remote code execution. Zo’n fout laat een aanvaller van buitenaf opdrachten laten uitvoeren op de server van een website, en volgens CERT-EU hoeft de aanvaller daarvoor niet eerst in te loggen. Wie dat lukt, kan gegevens inzien en in het slechtste geval de site of de server overnemen. De score van 9,2 op 10 weerspiegelt dat: de impact is groot en de fout is eenvoudig uit te buiten.

Dat het ook echt eenvoudig was, bleek uit wat er al rondging. Beveiligingsonderzoekers van Watchtowr noemden de kwetsbaarheden CVE-2026-109618 en CVE-2026-109619, en er ging al vóór de officiële uitleg een proof of concept rond. De video noemt de bug PHP2Shell en toont met een eenvoudig Python-script hoe een aanvaller de inlogfunctie van websites met cms’en als Joomla en WordPress omzeilt, en hoe het wachtwoord uit een Symfony-framework te achterhalen is. Omdat PHP in zoveel applicaties zit, is het bereik groot. Dat geldt voor WordPress, Joomla, Drupal, Magento en andere websitesoftware.

Een tweede probleem komt pas na de patch. De kwetsbaarheden zitten in veel PHP-versies, en de meeste daarvan worden niet meer ondersteund. Voor die versies verschijnt dus geen beveiligingsupdate. Wie op zo’n oude versie draait, wordt aangeraden direct naar een nieuwe versie te updaten, en dat is een grotere klus dan een patch installeren.

Het mechanisme dat de dag bepaalde, is het updatevenster. Zolang de fix er niet is, is volgens het NCSC ieder systeem met PHP dat bereikbaar is vanaf het internet vermoedelijk kwetsbaar. Zodra de fix er wél is, weten aanvallers waar de fout zit en kunnen ze op basis van de update zelf een aanvalsscript schrijven en het internet gaan scannen. Cybersecurityexpert Daan Keuper wees op dat moment: wie als eerste update, is hen voor. Wie later update, loopt het risico dat iemand anders eerder bij de deur staat. Daarom ging zoveel offline: het was een noodrem in het gat tussen beschikbaar en ingevoerd.

Waarom de PHP-bugs nu pas boven water kwamen

Volgens cybersecuritybedrijf Wiz zaten de kwetsbaarheden er al minstens tien jaar in. Wiz zegt ze met AI te hebben opgespoord en spreekt van de ernstigste beveiligingslekken die ooit door AI zijn gevonden. Wat AI veranderde, schrijft Wiz, is niet de fout zelf maar de snelheid van begrijpen en misbruiken: een enkele onderzoeker lukte met de beste modellen binnen een week wat een topteam voorheen maanden kostte.

De PHP Foundation erkende zelf dat de oplossing te lang op zich liet wachten. Volgens de stichting was dat structureel falen. Al in 2024 zou het vermoeden zijn ontstaan dat een van de kwetsbaarheden kon worden misbruikt, maar het werk aan een fix liep vast doordat het beveiligingsteam het niet eens werd over de oplossing, en doordat maar een klein team de benodigde kennis had.

Het gevolg is tweezijdig. Oude fouten in oude code zijn sneller te vinden, door criminelen én door verdedigers. Wiz wijst erop dat beveiligers met dezelfde middelen ook oude fouten kunnen opruimen. Wat vroeger veilig leek omdat niemand het had gevonden, is dat niet meer.

Is jouw website geraakt? Zo check je dat

Begin met de vraag of je site op PHP draait. Bij de volgende systemen is dat het geval: WordPress, Joomla, Drupal, WooCommerce, Magento, Symfony, Laravel en elke maatwerksite met .php-bestanden. Draait je site bij een aanbieder als Wix, Squarespace of Shopify, dan regelt die de update. Een site van losse HTML-bestanden gebruikt geen PHP.

Draait je site wel op PHP, controleer dan deze signalen. Geen van deze is een bewijs, en het ontbreken ervan is geen garantie:

• Beheerders in je cms die je niet kent.
• Bestanden die je niet herkent, zeker PHP-bestanden in uploadmappen.
• Pagina’s die onverwacht doorsturen of spamlinks in je zoekresultaten.
• Uitgaande e-mail die jij niet verstuurd hebt, of een server die ineens veel belast wordt.
• Een melding of mail van je hoster.

Wat je nu doet na het PHP-lek

• Inventariseer. Welke applicaties heb je, en welke PHP-versie draait er per applicatie? Watchtowr en andere beveiligingsbedrijven raden dit als eerste stap aan.
• Controleer of je PHP-versie nog wordt ondersteund. Draait je site op een versie die geen beveiligingsupdates meer krijgt, dan komt er voor jou geen patch. Je moet dan overstappen op een ondersteunde versie, en je cms en plugins moeten dat aankunnen. Plan dat nu, niet pas als er iets misgaat. CERT-EU adviseert bij PHP 8.1 of lager om de website zo spoedig mogelijk compatibel te maken met PHP 8.2 of hoger en de PHP-versie te verhogen.
• Vraag je hoster naar de update. Het NCSC waarschuwde dat een site na de update niet altijd direct weer online kan, afhankelijk van de gebruikte versie. Het is ook mogelijk dat er later nog een update komt, mocht de eerste niet alles oplossen.
• Update ook je cms, thema’s en plugins. De PHP-update dicht dit gat, maar een verouderd onderdeel is een ander.
• Zet een back-up buiten de server en test dat je hem kunt terugzetten.
• Ververs wachtwoorden en sleutels als je vermoedt dat je site in het kwetsbare venster online stond: beheerderswachtwoorden, API-sleutels en de beveiligingssleutels in je cms-configuratie.
• Ruim op wat je niet gebruikt. Oude testsites en vergeten WordPress-installaties vallen het eerst uit de pas. Wat niet draait, kan niet lekken.
• Bedenk hoe je klanten bereikt als je site eruit ligt. RTL Nieuws bleef via sociale media berichten, Stichting Ambulance Wens werkte telefonisch door en de ANWB hield Wegenwacht bereikbaar.

Moet je offline gaan?

Offline halen levert zekerheid en kost beschikbaarheid. CERT-EU adviseerde publiek toegankelijke PHP-applicaties tijdelijk af te schermen van het internet totdat de beveiligingsupdates waren uitgebracht en toegepast, en veel organisaties volgden dat. DigiD, MijnOverheid, ziekenhuizen en gemeenten maakten die afweging op een dag waarop de update nog niet beschikbaar was.

Nu de update er is, verschuift de vraag naar de eerste stap: is jouw site gepatcht? Zolang je dat niet zeker weet, is afschermen of tijdelijk offline gaan een verdedigbare keuze, zeker als je gevoelige gegevens verwerkt. Voor een visitekaartje weegt de omzet van een paar uur anders, maar die afweging maak je zelf. Begin in elk geval bij je hoster: vraag of de update er staat en of jouw PHP-versie nog wordt ondersteund.

Hoe wij de dag doorkwamen

Onze klanten zijn niet geraakt en hebben geen schade ondervonden. Wij hebben maatregelen genomen zodra het nieuws bekend werd, en de impact bleef beperkt.

We hielden onze klanten op de hoogte met een mededeling met de feiten: de twee kwetsbaarheden, het advies van CERT-EU en de verwachte update om 16.00 uur. Daarin lieten we ook weten dat onze systeembeheerders klaarstonden om alle servers direct te updaten zodra de update live ging. Wie op PHP 8.1 of lager draaide, kreeg het advies om te upgraden naar 8.2 of hoger.

Dat de impact beperkt bleef, komt vooral doordat wij weinig pure WordPress-websites hosten. Dat is het soort site waarvoor in de proof of concept zichtbaar werd hoe de inlogfunctie te omzeilen was, en waar de PHP-update het meest direct op neerkwam. Hoe minder PHP je beheert, hoe minder je hoeft te patchen op het moment dat iedereen tegelijk patcht. Dat bepaalt of een dag als woensdag een noodmaatregel is of een routineklus.

Dat is geen reden om achterover te leunen. De volgende kwetsbaarheid zit ergens anders, en het blijft nodig om te weten wat er draait en wie het bijwerkt. Maar het bevestigt de keuze waar dit artikel op uitkomt: draai niet meer dan je nodig hebt, en weet wat je draait.

Complexe websites bouwen en veilig beheren

De PHP-dag laat zien dat het risico niet zit in de keuze voor een taal, maar in wat er onder de motorkap draait en wie dat bijhoudt. Een site met alleen informatie heeft weinig nodig. Veel bedrijven willen meer dan een visitekaartje: een webshop, een ledenplatform, een boekingssysteem of een koppeling met betaal- en administratiesystemen. Dat kan niet zonder server-side code, en dus ook niet zonder een aanpak voor updates.

Dat is werk dat wij ook doen. Op onze projectenpagina staan sites die verder gaan dan een paar pagina’s. Denk aan een ledenplatform voor de Nederlandse Vereniging voor AI- en Robotrecht, met eventregistratie, een koppeling met ClubCollect en betalen via iDEAL of WERO. Of aan een gratis QR-codegenerator die direct in de browser werkt, en een doorzoekbaar naslagwerk met ruim 200 Egyptische farao’s per dynastie en tijdlijn. Daarnaast bouwen we sites voor DJ-boekingen en fotobooths voor evenementen.

Hoe je zo’n site veilig houdt, volgt dezelfde logica als de checklist hierboven:

• Bouw alleen wat nodig is. Elke functie die draait, is een extra aanvalsroute. Wat server-side moet, bouw je server-side, de rest niet.
• Kies ondersteunde versies en plan upgrades vooraf. Dan is een dag als woensdag een routineklus en geen noodgreep.
• Regel updates, back-ups en monitoring structureel. Bij ons zit dat in het Zorgplan.
• Weet wat er draait. Houd per site bij welke versies, plug-ins en koppelingen er in zitten.

Heb je een site die ingewikkelder is dan een visitekaartje, of denk je erover na? Vertel in een gratis offerte wat de site moet kunnen. We bouwen het, houden het bij en zorgen dat het veilig blijft. Een kleine webshop begint bij €1.499, en onze websites beginnen bij €599.

Veelgestelde vragen

Wat is het PHP-lek en wat zijn de PHP-bugs?

Het PHP-lek van 21 oktober 2026 draait om twee kritieke PHP-bugs: kwetsbaarheden waarmee een aanvaller op afstand code kan uitvoeren op de server van een website (remote code execution). Beide krijgen een CVSS-score van 9,2 op 10. Beveiligingsbedrijf Watchtowr noemde ze CVE-2026-109618 en CVE-2026-109619. Volgens beveiligingsbedrijf Wiz, dat ze met AI opspoorde, zaten ze er meer dan tien jaar in. De PHP-makers brachten op 21 oktober om 16.00 uur een beveiligingsupdate uit.

Wat adviseert CERT-EU bij het PHP-lek?

CERT-EU adviseerde in beveiligingsadvies 2026-018 om publiek toegankelijke PHP-applicaties tijdelijk af te schermen van het internet totdat de beveiligingsupdates zijn uitgebracht en toegepast. Draai je PHP 8.1 of lager, dan is het advies om je website zo spoedig mogelijk compatibel te maken met PHP 8.2 of hoger en de PHP-versie te verhogen. Volgens het advies is voor misbruik geen authenticatie nodig.

Is mijn website kwetsbaar voor het PHP-lek?

Alleen als je site op PHP draait. Dat geldt voor WordPress, Joomla, Drupal, WooCommerce, Symfony en voor maatwerksites met .php-bestanden. Volgens beveiligingsbedrijf Watchtowr zitten de fouten in alle PHP-versies sinds PHP 5. Een statische website draait niet op PHP en heeft deze lekken niet. Bij een website via Wix, Squarespace of Shopify regelt de aanbieder de update.

Moet ik mijn website offline halen?

CERT-EU adviseerde publiek toegankelijke PHP-applicaties tijdelijk af te schermen totdat de beveiligingsupdates waren uitgebracht en toegepast, en veel organisaties haalden hun site daarom offline. Nu de update er is, is de eerste vraag of jouw site is gepatcht. Weet je dat niet zeker, dan is afschermen verdedigbaar, zeker bij gevoelige gegevens. Vraag bij je hoster na of de PHP-update is doorgevoerd en of jouw PHP-versie nog wordt ondersteund.

Hoe weet ik of mijn website is gehackt?

Let op onbekende beheerders in je cms, bestanden die je niet kent (zeker PHP-bestanden in uploadmappen), onverwachte doorverwijzingen of spam in je zoekresultaten, vreemde uitgaande e-mail en meldingen van je hoster. Het ontbreken van signalen is geen garantie, dus controleer ook je logbestanden bij je hoster.

Krijgt mijn oude PHP-versie ook een update?

Waarschijnlijk niet. De kwetsbaarheden zitten in veel PHP-versies, en de meeste daarvan worden niet meer ondersteund en krijgen geen beveiligingsupdate. Voor die versies is de aanbevolen oplossing om direct naar een nieuwere, ondersteunde versie te gaan. Vraag je hoster welke versie jouw site draait en of je kunt upgraden.

Wat betekent PHP2Shell?

PHP2Shell is de naam die de maker van een proof-of-conceptvideo aan de kwetsbaarheid gaf. In de video van beveiligingsonderzoekers laat de maker zien hoe een aanvaller met een eenvoudig Python-script de inlogfunctie van cms'en als Joomla en WordPress kan omzeilen. Officiële technische details kwamen pas met de update.

Overleefd, voor nu

Het internet kwam deze ronde zonder gemelde incidenten door de dag. Dat zegt iets over de snelheid van de voorzorg, niet over de afwezigheid van het risico. De fout zat meer dan tien jaar in de code, en het uitlekken ervan was een kwestie van uren. Wat nu verandert is hoe snel iemand haar kan vinden. Wie weet wat er op zijn server draait, wie een plan heeft voor een update en wie minder draait dan nodig, is bij de volgende keer sneller klaar.