Op woensdag 21 oktober 2026 gingen overal in Nederland websites uit de lucht. DigiD, MijnOverheid, de Tweede Kamer en nieuwssites waren urenlang onbereikbaar. De oorzaak: het PHP-lek, een ernstig beveiligingslek in PHP. Dat is de programmeertaal waar ook WordPress op draait. Ik onderhoud ruim twintig WordPress-sites, verspreid over acht hostingpartijen. Ik heb van dichtbij gezien hoe verschillend die hosts reageerden.
Wat was er aan de hand?
Op dinsdag 20 oktober werden twee kritieke lekken in PHP bekend, bijgenaamd PHP2Shell. Via een gewone upload konden aanvallers code op een server uitvoeren. Dat raakt bijna elke website, want zo’n 70% van het web draait op PHP. De officiële reparatie zou pas woensdagmiddag om 16:00 uur verschijnen. Tot die tijd was elke PHP-site kwetsbaar.
Het PHP-lek was groot nieuws. De NOS volgde het de hele dag in een liveblog en schreef dat websites van overheid en onderwijs offline gingen. De Rijksoverheid haalde uit voorzorg een aantal websites offline.
Hoe ik het als website-eigenaar en webdesigner heb ervaren
Ik zit aan twee kanten van de tafel. Mijn eigen websites draaien bij een host. En ik ben verantwoordelijk voor de websites van mijn klanten. Dat maakte die woensdag spannend.
De eerste vraag was: wat kan ik zelf doen, nu de echte reparatie er nog niet is? Het antwoord: de aanvalsroute dichtzetten. Ik heb op alle sites twee PHP-instellingen uitgezet, via de bestanden .user.ini en .htaccess. Daarmee werkt de bekende aanval niet meer. Daarnaast heb ik in de beveiligingsplugin gecontroleerd dat PHP-bestanden in de uploadmap niet kunnen draaien.
Klinkt simpel. In de praktijk was het puzzelen. Niet elke host gebruikt dezelfde serversoftware, dus niet elke instelling werkt overal. Op sommige hosts kon ik niet bij de bestanden die ik nodig had. En bij een paar sites bleek na het overstappen naar een nieuwere PHP-versie het geheugen te krap. Een site ging daardoor even plat. Dat los je op, maar het kost tijd op een dag dat je die niet hebt.
De tweede vraag: is de host al gepatcht? Dat bleek lastiger dan gedacht. Daarover zo meer.
En tussendoor mailde ik mijn klanten. Want ook al is er nergens misbruik gezien, je wilt als klant weten dat iemand ernaar kijkt.
Hoe reageerden de hosts op het PHP-lek?
Grofweg zag ik drie aanpakken:
- Alles offline tot de patch er is. Het veiligst, maar je website is een paar uur weg.
- Online blijven met extra beveiliging. Firewallregels en de aanvalsroute dicht, daarna patchen.
- Stil patchen. De reparatie inbouwen zonder het versienummer te veranderen.
Ik vind het een sterk signaal als een host durft te zeggen: we zetten alles even uit. Dat kost hen klachten, maar het beschermt jouw website en jouw bezoekers. Daarom staan die hosts bovenaan in mijn overzicht.
| Host | Klantsites offline? | Officieel versienummer? | Hosting + .nl-domein per jaar | |
|---|---|---|---|---|
| Cloudmonsters | ✅ Ja, alle klantsites rond 12:00 | Nee, stille patch | €83,40 + domein | In pakket (5 mailboxen) |
| Mijndomein | ✅ Ja, alle klantsites van ±14:30 tot ±18:00 | Ja | ±€120 | In pakket (onbeperkt) |
| Vimexx (Plus) | Nee, firewallregels | Nee, stille patch | €108,57 | In pakket (onbeperkt) |
| Antagonist | Nee | Nee, stille patch | ±€134,16 | In pakket (onbeperkt) |
| TransIP | Nee | n.v.t. | €136,38 | In pakket (5 mailboxen) |
| one.com ⚠️ | Nee, tijdelijke maatregelen | Ja | €85,87 | In pakket (1 mailbox) |
| Yourhosting / Argeweb ⚠️ | ✅ Ja, shared hosting van 21-10 tot 22-10 (ochtend/middag) | Deels | €96,37 (€276,25 met e-mail) | Apart, €14,99 per maand |
Het versienummer zegt niet alles
Dit was voor mij de grootste les. PHP bracht gerepareerde versies uit met nieuwe nummers, zoals 8.3.36 en 8.4.27. Ik verwachtte die nummers terug te zien bij elke host. Bij een flink deel was dat niet zo. Zij bouwen de reparatie in de bestaande versie in. Het nummer blijft dan bijvoorbeeld 8.3.35, terwijl het lek wel dicht is.
Dat is niet fout, maar het is wel verwarrend. Je ziet aan de buitenkant niet of je veilig bent. Ik heb daarom per host de bouwdatum van PHP gecontroleerd. Die moet op of na 21 oktober liggen. Pas dan wist ik het zeker.
Draait jouw website op een oude PHP-versie?
Een paar websites die ik tegenkwam draaiden nog op PHP 7.4, 8.0 of 8.1. Die versies krijgen officieel geen updates meer. Sommige hosts repareerden ze toch, soms tegen betaling. Maar het PHP-lek laat zien hoe kwetsbaar je dan bent. Mijn advies: zorg dat je website op PHP 8.3 of hoger draait. Ik controleer dat voortaan bij elke onderhoudsronde.
Wat neem ik mee van het PHP-lek?
- Een host die durft in te grijpen, is goud waard.
- Een recente PHP-versie scheelt je veel stress.
- Kijk niet alleen naar het versienummer, maar ook naar de bouwdatum.
- Regelmatig onderhoud betaalt zich uit op dagen als deze.
Twijfel je of jouw website veilig is? Of wil je weten of je host goed bij je past? Ik kijk graag met je mee. Voor €45,- per uur exclusief btw controleer ik je PHP-versie, je host en je beveiliging.
