Het PHP-lek van 21 oktober in gewone taal: wat er gebeurde en wat je nu doet

Bijgewerkt op 25 oktober 2026. Dit artikel is oorspronkelijk gepubliceerd op 22 oktober 2026. De tekst hieronder is niet gewijzigd. Nieuw zijn de update onder “Is het lek al misbruikt?”, de update over het onderzoek van MindYourPass vlak voor de bronnen en twee extra bronnen.

Wat is PHP?

PHP is een programmeertaal die op de server draait, niet in je browser. Vergelijk een website met een restaurant. Wat jij op je scherm ziet, is het bord dat op tafel komt. PHP is de keuken. Elke keer dat iemand een pagina opent, maakt de keuken die pagina klaar: de tekst uit de database, het menu, het contactformulier.

WordPress draait op PHP. Veel webwinkels, klantportalen en intranetten ook. Heb je een WordPress-site, dan heb je dus PHP, ook als je dat woord nog nooit hebt gezien.

Wat er misging

Op 20 oktober kondigde het PHP-team aan dat er de volgende dag een beveiligingsupdate zou komen voor twee kritieke kwetsbaarheden. CERT-EU, de cyberdienst van de Europese instellingen, waarschuwde dat ze kunnen leiden tot het overnemen van een server op afstand. In de restaurantvergelijking: iemand van buiten kan de keuken binnenlopen en daar doen wat hij wil, zonder in te loggen.

Volgens het NCSC was daar één eenvoudig verzoek aan de server voor nodig. De gevolgen kunnen groot zijn: een server die wordt overgenomen, gegevens die uitlekken, of een website waarop niemand meer kan inloggen.

Het lastige was de volgorde. De aankondiging kwam een dag eerder dan de update. Iedereen wist dus dat er iets ernstigs was, maar kon het nog niet oplossen. Volgens het NCSC was er op 21 oktober al code openbaar die laat zien hoe het lek werkt, maar had het NCSC nog geen actief misbruik gezien.

Op 21 oktober bracht PHP de gecorrigeerde versies uit: 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Voor PHP 8.1 en ouder kwam er geen gewone update. Het PHP-team leverde voor 7.4, 8.0 en 8.1 alleen een minimale correctie voor wie PHP zelf samenstelt. Voor de meeste websites betekent dat: overstappen naar een nieuwere versie.

Niet alleen websites

Het NCSC wees op iets wat in het nieuws onderbelicht bleef. PHP zit niet alleen in websites. Het zit ook in netwerkapparatuur, in dashboards van slimme apparaten en in vrijwel alle soorten beheerschermen die je via de browser opent om de instellingen van een apparaat te wijzigen. Denk aan de beheerpagina van een router, een opslagapparaat of een camerasysteem.

Bij zulke apparaten werk je PHP niet zelf bij. Je bent afhankelijk van de leverancier, die een nieuwe versie van de software moet uitbrengen. Staat zo’n beheerscherm open op internet, dan is dat het eerste dat je dichtzet.

Waarom websites offline gingen

CERT-EU gaf een duidelijk advies: kun je niet direct bijwerken, haal je internetapplicaties dan van het netwerk tot de update er is. Het NCSC adviseerde om per systeem dat PHP gebruikt en aan internet hangt een afweging te maken, inclusief de vraag of je het uitzet.

Veel organisaties kozen voor zekerheid. Het NCSC haalde ncsc.nl offline. Lokale media meldden dat onder meer gemeenten in de Zaanstreek hun website uit voorzorg uit de lucht haalden. Een website die een paar uur offline is, is vervelend. Een server die is overgenomen, is veel erger.

Waarom een plugin-update niet genoeg was

Veel mensen kennen het rode bolletje in WordPress: er zijn updates voor je thema of plugins. Die updates zijn belangrijk, maar ze lossen dit lek niet op. Het lek zat niet in WordPress, maar in PHP zelf, de keuken onder het restaurant. Die keuken werkt de hostingpartij bij, niet de website.

Daarom ging de vraag op 21 oktober niet over plugins, maar over de server: wie beheert die, en hoe snel na de update is hij bijgewerkt?

Wat wij die dag deden

Voor klanten van wie wij de website beheren, werken we samen met vaste websitepartners die de servers in de gaten houden. Onze websitepartner meldt dat het team al vroeg op de dag klaarstond en de servers vóór de update extra beveiligde. De firewall voor alle servers kreeg een update die aanvallen op het lek tegenhoudt, en een aantal opties die een aanvaller als ingang kon gebruiken, werd tijdelijk uitgezet. Daardoor konden websites overdag online blijven. Na de release rolde de partner de update direct uit op alle servers. Tijdens die uitrol is een klein aantal websites tijdelijk offline gehaald, als extra veiligheidsmaatregel. Klanten die ons vroegen hoe hun website ervoor stond, kregen van ons de stand van zaken. Al vóór de update waarschuwden we op LinkedIn dat een plugin-update niet genoeg was.

Bij onze eigen websites liepen we hetzelfde lijstje af. We maakten een verse back-up en zetten die buiten de server. We keken welke onderdelen PHP echt nodig hebben, en zetten PHP uit op onderdelen die alleen een vast bestand tonen. Wat niet draait, hoeft ook niet bijgewerkt te worden. We controleerden de versie na de update zelf, in plaats van op een melding te vertrouwen. Onze eigen websites draaien op de gecorrigeerde versie.

Vijf vragen voor wie je website beheert

Je hoeft geen programmeur te zijn om dit goed te regelen. Je moet wel het antwoord weten op deze vijf vragen:

1. Op welke PHP-versie draait mijn website? In WordPress staat het onder Hulpmiddelen, Sitegezondheid, tabblad Info, onderdeel Server.

2. Wie werkt de server bij, en hoe snel? Bij de meeste websites is dat de hostingpartij. Weet je niet wie dat is, dan is dat het eerste dat je uitzoekt.

3. Draai ik op een versie die nog updates krijgt? Voor PHP 8.1 en ouder kwam er geen gewone update. Zit je daarop, dan is overstappen nodig, niet wachten.

4. Staat mijn back-up buiten de server? Een back-up die op dezelfde server staat als de website, verdwijnt mee als die server wordt overgenomen of uitvalt.

5. Welke websites en onderdelen heb ik eigenlijk? Een oude actiepagina, een vergeten testsite, een klantportaal. Wat je niet kent, werkt niemand bij.

Wat de Security Check wel en niet ziet

Eerst de grens. De Security Check kijkt van buitenaf, zoals een bezoeker dat doet. Of de server achter je website is bijgewerkt, kan hij alleen zien als die server zijn PHP-versie zelf noemt. Bij een goed ingerichte server staat die versie verborgen. De Security Check zegt dan dat het van buitenaf niet te zien is. Of je bent bijgewerkt, hoor je in dat geval van je hostingpartij of zie je zelf in Sitegezondheid.

Nieuw: een eigen onderdeel voor dit lek

Sinds 22 oktober heeft de Security Check een onderdeel Gemelde PHP-versie, onder Hygiëne. Noemt je server een PHP-versie, dan legt de Security Check die naast de gecorrigeerde versies van 21 oktober. Wat je dan ziet:

• Een kwetsbare versie. Is je versie ouder dan de gecorrigeerde versie in dezelfde reeks, dan meldt de Security Check dat, met de versie die je minimaal nodig hebt. Dat telt mee in je score.
• PHP 8.1 of ouder. Die reeksen krijgen geen gewone updates meer. Ook dat meldt hij, met het advies over te stappen naar een versie die nog wel updates krijgt.
• Een gecorrigeerde versie. Dan zegt hij dat de fixes van 21 oktober erin zitten. Extra punten levert dat niet op: een zichtbare versie mag nooit beter scoren dan een verborgen versie. Het advies om de versie te verbergen blijft staan.
• Een versie met een toevoeging. Linux-distributies zoals Ubuntu en Debian brengen fixes terug zonder het versienummer te verhogen. Staat er zo’n toevoeging achter de versie, of gaat het om een testversie, dan is van buitenaf niet te zien of de fix erin zit. Dat zegt de Security Check dan ook, in plaats van te gokken.
• Wel PHP, geen versie. Zet je site een PHP-sessiecookie of noemt de server alleen het woord PHP, dan meldt hij dat je site PHP lijkt te gebruiken. Een oordeel over de versie geeft hij dan niet.

Hij doet daarvoor geen extra verzoeken aan je server. Hij leest alleen wat je server bij een gewoon bezoek aan de homepage al terugstuurt. Geen inlogpogingen, geen zoektocht naar verborgen pagina’s. We werken de lijst met gecorrigeerde versies bij zodra PHP een nieuwe beveiligingsupdate uitbrengt.

De rest van de buitenkant

Daarnaast meet de Security Check wat je op een dag als 21 oktober toch al nagaat: je certificaten, je beveiligingsheaders en je mail- en DNS-instellingen. Een verlopen certificaat of een ontbrekende beveiligingsheader vind je precies als je je websites één voor één langsloopt. En hij kijkt of je server aan iedereen vertelt welke software en versie hij draait. Een aanvaller ziet dan meteen welke bekende lekken het proberen waard zijn.

Je hebt er geen account voor nodig. Doe de Security Check voor je eigen domein. Krijg je een melding over je PHP-versie, of zegt hij dat het van buitenaf niet te zien is, stel dan vraag 1 en 2 hierboven aan wie je website beheert.

Een website die wordt bijgehouden

De meeste websites worden gebouwd en daarna vergeten. Tot een dag als 21 oktober. Wij regelen de bouw en het beheer van websites samen met onze websitepartners: de server wordt bijgewerkt, de back-up staat buiten de server, en bij een lek hoor je van ons wat er speelt voordat je het in de krant leest.

Wil je weten hoe jouw website ervoor staat, of wil je een website die op deze manier wordt beheerd? Plan een gesprek. We werken zelf onder ISO 27001:2023, ISO 9001:2015 en NEN 7510:2024.

Veelgestelde vragen

Mijn website bleef online. Is hij dan veilig?

Niet vanzelf. Online blijven was een keuze, geen bewijs. Je website is pas bijgewerkt als de server op 8.5.12, 8.4.27, 8.3.36 of 8.2.35 draait, of op een nieuwere versie in dezelfde reeks.

Kan de Security Check zien of mijn website is bijgewerkt?

Alleen als je server zijn PHP-versie zelf noemt. Dan legt hij die naast de gecorrigeerde versies van 21 oktober. Is de versie verborgen, dan zegt hij dat het van buitenaf niet te zien is. Een verborgen versie is goed, maar geen bewijs dat je bent bijgewerkt.

Moet ik zelf iets doen?

Vraag aan wie je website beheert op welke versie hij nu draait. Bij een WordPress-site kun je het ook zelf zien in Sitegezondheid.

Is het lek al misbruikt?

Op 21 oktober meldde het NCSC dat er voorbeeldcode openbaar was, maar dat het nog geen actief misbruik had gezien. Dat kan veranderen. Daarom is bijwerken de enige echte oplossing.

Update 24 oktober 2026: op 23 oktober schreef het NCSC dat er één melding bekend is van mogelijk misbruik in het buitenland, zonder bevestiging dat de aanval is gelukt. Volgens het NCSC is misbruik ingewikkeld en is de kans op grootschalig misbruik kleiner dan eerder ingeschat. Het advies blijft hetzelfde: zo snel mogelijk bijwerken. Controleer de actuele stand op ncsc.nl.

Helpt een beveiligingsplugin in WordPress?

Niet tegen dit lek. Het zat in PHP zelf. Een plugin draait bovenop PHP en kan de keuken eronder niet repareren.

Geldt dit ook voor mijn router of opslagapparaat?

Dat kan. Volgens het NCSC zit PHP ook in netwerkapparatuur en in beheerschermen die je via de browser opent. Kijk of de leverancier een update heeft uitgebracht, en zorg dat het beheerscherm niet open op internet staat.

Mijn website draait op PHP 8.1 of ouder. Wat nu?

Laat hem overzetten naar een versie die nog updates krijgt. Maak eerst een back-up en test daarna of je thema en plugins goed blijven werken.

Conclusie

Het PHP-lek liet zien dat een website niet klaar is als hij live staat. Iemand moet de server bijhouden, en jij moet weten wie dat is. De organisaties die op 21 oktober rustig bleven, wisten het antwoord op die vraag al vóór de update.

Weet je het antwoord niet, of wil je dat iemand het voor je bijhoudt? Plan een gesprek met ALTA-ICT.

Update 24 oktober 2026: hoe ver is het bijwerken?

48 uur na de update was het werk nog niet af. Het Eindhovense cybersecuritybedrijf MindYourPass onderzocht 494.416 webadressen van applicaties waarop medewerkers van zijn klanten inloggen. Bij 60.362 kon PHP met zekerheid worden vastgesteld. Daarvan draaide 28.615 (47%) op een verouderde, niet langer ondersteunde of getroffen versie. Dat is een meting van een leverancier onder zijn eigen klanten, geen steekproef van alle Nederlandse websites. De kwetsbaarheden zijn niet getest, en MindYourPass schrijft zelf dat de uitkomst niet bewijst dat individuele applicaties kwetsbaar zijn. Lees het onderzoek van MindYourPass.

Bronnen

PHP, News Archive 2026: aankondiging van 20 oktober en beveiligingsadvies van 21 oktober.
CERT-EU, Security Advisory 2026-018.
NCSC via Rijksoverheid, Ernstige kwetsbaarheden in PHP (21 oktober 2026).
NCSC, Security Advisories: websitebericht “Ernstige kwetsbaarheden in PHP: bereid je voor op patchen” (21 oktober 2026).
NCSC, Update: PHP-kwetsbaarheden nog steeds reden om direct te patchen (bijgewerkt 23 oktober 2026).
MindYourPass, 48 uur na kritiek PHP-lek: ruim 28.000 gebruikte webapplicaties draaien nog altijd op verouderde of getroffen versie.
Geraadpleegd op 22 oktober 2026. De NCSC-update van 23 oktober en het onderzoek van MindYourPass zijn geraadpleegd op 25 oktober 2026.