Woensdagmiddag 21 oktober ging de ene na de andere website uit de lucht. Om 12:48 gingen DigiD en MijnOverheid uit voorzorg offline, en in de uren daarna volgden de Tweede Kamer, RTL, de KNVB en een reeks ziekenhuizen, zo blijkt uit het liveblog van de NOS. Wie die middag verantwoordelijk was voor een klantportaal of webshop op PHP, kreeg dezelfde vraag op zijn bord: moeten wij ook uit de lucht?
Het korte antwoord: installeer de beveiligingsupdate van PHP die sinds woensdagmiddag beschikbaar is, en zoek daarna uit welke systemen op een PHP-versie draaien die geen updates meer krijgt. Offline gaan is een noodgreep voor de uren tot de update erop staat, en voor oude versies helpt ook dat niet, want daar komt van het PHP-project geen update meer voor.
Wat er aan de hand is met PHP
PHP is de programmeertaal onder een groot deel van het web. WordPress, Drupal, Magento en Laravel draaien erop, net als veel zelfgebouwde portalen en backoffice-systemen. In die taal zitten twee lekken, CVE-2026-109618 en CVE-2026-109619, die volgens de advisory van het PHP-project allebei een score van 9,2 krijgen op de CVSS-schaal van 10. Een aanvaller kan er zonder in te loggen code mee uitvoeren op je server.
Het lek zit in PHP zelf, niet in een plugin of thema. Een update van WordPress of van je framework helpt dus niet. Volgens het PHP-project loopt elke installatie risico die webverzoeken afhandelt, of dat nu via PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP of LiteSpeed gaat. Het grootste risico zien de ontwikkelaars bij mod_php: daar is aangetoond dat één verzoek zonder inlog genoeg is om de aanval te starten, nog voordat er een regel van je eigen code draait.
Dit is de stand van woensdagavond 21 oktober 2026. Nu de details openbaar zijn, kan het beeld snel veranderen.
Waarom zoveel websites offline gingen
Het Nationaal Cyber Security Centrum waarschuwde dat kwaadwillenden via deze lekken iedere website of webserver met PHP konden aanvallen, schrijft de Rijksoverheid. Signalen van actief misbruik waren er op dat moment niet. Het advies aan organisaties was toch: weeg zelf de risico's af en overweeg je site offline te halen tot de update er is.
Veel organisaties deden dat. De update kwam om 15:43 uit, iets eerder dan aangekondigd, en tegen vijf uur waren de eerste sites weer bereikbaar.
Die afweging verschilt per systeem. Een informatieve website die een middag uit de lucht is, kost wat bezoekers. Een klantportaal met persoonsgegevens waar iemand binnenkomt, kost veel meer: een datalek, een melding bij de Autoriteit Persoonsgegevens en klanten aan wie je uitleg verschuldigd bent. Wie woensdag offline ging, kocht tijd. Meer niet.
Wat je nu doet tegen de PHP-kwetsbaarheid
Nu de update er is, is het werk zelf niet ingewikkeld. De meeste tijd gaat zitten in het vinden van alles wat op PHP draait.
- Maak een lijst van je PHP-systemen. Denk verder dan je website: het klantportaal, het intranet, een vergeten campagnesite, de WordPress-site van een dochterbedrijf, of een tool die een leverancier jaren geleden voor je bouwde.
- Kijk per systeem welke versie draait. Op een eigen server geeft
php -vhet antwoord. In WordPress staat het onder Gereedschap > Sitestatus > Info > Server. Bij gedeelde hosting vraag je het aan je hostingpartij. - Update naar een versie met de fix. Dat zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Linux-distributies kregen de patches vooraf, dus via de pakketbeheerder van je server komt de update meestal het snelst binnen.
- Herstart en controleer. Herstart na de update PHP-FPM of Apache, anders draait de oude versie gewoon door. Werk je met containers, bouw je images dan opnieuw en rol ze uit: een image dat op een vaste PHP-versie gebouwd is, wordt niet vanzelf bijgewerkt.
Kijk daarna op de productieserver zelf welke versie er draait. Een update in de testomgeving telt niet.
Als je nog niet kunt updaten
Soms lukt updaten niet meteen, bijvoorbeeld omdat de applicatie eerst getest moet worden of omdat de leverancier niet bereikbaar is. Het PHP-project noemt voor die situatie een paar instellingen die bekende aanvalspaden afsluiten:
session.upload_progress.enabled=0in php.ini of in de configuratie van de FPM-pool, met daarna een herstart van alle workers. Viaini_set()of een.user.iniwerkt het niet.- Een lage
post_max_size: 8M voor applicaties zonder uploads, 32M als uploads nodig zijn.
Het project is er zelf duidelijk over: deze maatregelen verkleinen het risico, maar maken een installatie niet veilig. Alleen de update doet dat. Gebruik ze dus voor de uren of dagen tot de update erop staat, en leg vast wie die update wanneer alsnog doet. Zit je site achter een webapplicatie-firewall, vraag je leverancier dan of die al regels voor deze lekken heeft.
Oude PHP-versies: daar zit het echte probleem
Voor PHP 8.1 en ouder brengt het PHP-project geen updates meer uit. Vanwege de ernst publiceerde het team wel minimale bronpatches voor PHP 7.4, 8.0 en 8.1, bedoeld voor wie PHP zelf compileert. Sommige distributies en leveranciers van langdurige ondersteuning bieden een gepatchte versie. Draai je op een nog oudere versie, dan ben je helemaal afhankelijk van je leverancier.
Ook PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer. Wie vandaag naar 8.2.35 gaat, heeft dit lek gedicht, maar staat over ruim twee maanden voor dezelfde vraag.
Bij een oude PHP-versie is updaten zelden een kwestie van één knop. Een applicatie die op PHP 7 is blijven hangen, doet dat meestal om een reden: een framework dat niet meer onderhouden wordt, functies die in PHP 8 verdwenen zijn, of code waarvan niemand meer precies weet wat hij doet. Dan is de PHP-update in feite een modernisering. Hoe je zo'n systeem herkent en wanneer vervangen verstandig is, lees je in ons blog over legacy systemen herkennen en vervangen.
Zo'n systeem hoeft niet in één keer opnieuw gebouwd te worden. Bij legacy-modernisering werken wij stap voor stap: we behouden wat werkt, vervangen wat je tegenhoudt en houden het systeem al die tijd in de lucht. Bij een applicatie op PHP 7 is de eerste stap meestal de code geschikt maken voor een ondersteunde PHP-versie, zodat je weer updates krijgt. Daarna pak je de onderdelen aan die je het meest ophouden.
Na deze week: sneller bij het volgende lek
Dit was niet het laatste ernstige lek in software waar je bedrijf op draait. Wat je deze week uitzoekt, scheelt de volgende keer uren:
- Houd een lijst bij van je applicaties, met per applicatie de taal, de versie, de hostingpartij en wie de updates doet.
- Spreek met je leverancier of hostingpartij af hoe snel een kritieke beveiligingsupdate erop staat, en wie je dan belt.
- Laat updates via een vaste route lopen, zodat een nieuwe PHP-versie getest en uitgerold wordt zonder handwerk op de server.
- Zet in je planning wanneer elke versie zijn ondersteuning verliest. Voor PHP 8.2 is dat eind dit jaar.
Isatis is sinds 2015 gecertificeerd voor ISO 27001, en die norm vraagt precies dit: weten wat je hebt draaien en aantoonbaar bijhouden dat het veilig blijft.
Veelgestelde vragen
Is mijn WordPress-site kwetsbaar?
Als de server een PHP-versie zonder de fix draait, ja. WordPress of een plugin bijwerken lost het niet op, want het lek zit in PHP. Bij gedeelde hosting werkt de hostingpartij PHP bij. Vraag na of dat gebeurd is en naar welke versie.
Wordt de kwetsbaarheid al misbruikt?
Op woensdag 21 oktober hadden het NCSC en de PHP-ontwikkelaars geen signalen van actief misbruik. Nu de technische details openbaar zijn, kan dat snel veranderen. Wacht dus niet op berichten over aanvallen.
Moet ik mijn website offline halen?
Alleen als je niet snel kunt updaten en er op de site wordt ingelogd of met persoonsgegevens gewerkt. Voor de meeste sites is updaten nu sneller en verstandiger dan offline gaan.
Zijn websites zonder PHP veilig?
Voor dit lek wel. Sites als Rijksoverheid.nl gebruiken geen PHP en worden er volgens de Rijksoverheid niet door geraakt. Andere software heeft natuurlijk zijn eigen updates nodig.
Weet je niet zeker op welke PHP-versie je portalen en koppelingen draaien, of zit een applicatie vast op een versie die geen updates meer krijgt? Neem contact met ons op voor een kort gesprek. Je krijgt binnen 24 uur antwoord.
