Dinsdagavond 20 oktober werd bekend dat PHP, de techniek achter zo'n 70% van alle websites, twee kritieke beveiligingslekken bevat. Wat volgde was een race tegen de klok: aanvallers zochten naar manieren om de lekken te misbruiken, beheerders naar manieren om hun websites te beschermen.
Sommige experts adviseerden om websites uit voorzorg offline te halen. Wij kozen een andere weg: de websites bleven online, achter tijdelijke beschermingsmaatregelen, tot de officiële update er was. Inmiddels is die update geïnstalleerd en draait alles weer zoals het hoort.
Een lek in het fundament
PHP is de programmeertaal waarop het grootste deel van het web draait, waaronder WordPress en WooCommerce. De twee lekken (CVE-2026-109618 en CVE-2026-109619, in de wandelgangen “PHP2Shell” genoemd) zitten niet in een plugin of thema, maar in PHP zelf.
Dat maakt ze bijzonder problematisch. Een aanvaller kan via de lekken eigen code op een server uitvoeren. Het PHP-beveiligingsteam gaf beide lekken een score van 9,2 op 10.
Zelfs als je voor je Wordpress website gebruik maakte van een beveiligingsplugin zoals Wordfence was je website hier niet tegen beschermd. Het lek zat namelijk in de laag onder WordPress en die code wordt geladen voordat WordPress uberhaupt geladen is.
Een race tegen de klok
Normaal gesproken wordt een lek in stilte gemeld & opgelost en worden de details pas gedeeld als de oplossing klaarstaat. Deze keer liep het anders: de details lekten uit voordat er een update was. Vanaf dat moment was het een race tussen aanvallers die het lek wilden misbruiken en beheerders die hun servers wilden beschermen.
- Dinsdag 20 oktober, rond 17:20: details over de lekken duiken online op, nog zonder oplossing.
- Dinsdag 20 oktober, 21:33: het PHP-team kondigt een noodupdate aan voor woensdag 16:00.
- Woensdag 21 oktober, 09:43: Cloudflare meldt de eerste aanvallen.
- Woensdag 21 oktober, 15:45: PHP brengt de update uit, een kwartier eerder dan gepland.
Beveiligingsbedrijf Sansec verwachtte massale aanvallen binnen een kwartier na het verschijnen van de update. Door de update zou namelijk precies duidelijk zijn wat er gerepareerd is en waar het lek dus zat. Wie dan nog niet beschermd is, loopt het grootste risico.
Alle tijden in Nederlandse tijd.
Offline halen? Wij kozen een andere route
Het zwaarste advies dat rondging, was om websites tijdelijk van het internet te halen. CERT-EU, het cyberbeveiligingsteam van de Europese instellingen, raadde aan om websites af te sluiten als patchen niet direct mogelijk was. Eén van de PHP-ontwikkelaars noemde een server een dag uitzetten zelfs “misschien het verstandigste”, voor wie zich dat kon veroorloven.
Dat is goed advies als je niets anders kunt doen. Maar een website die offline is, levert geen bezoekers, aanvragen of bestellingen op. Voor een webshop betekent een dag offline direct verlies.
Daarom keken we eerst waar het gevaar precies zat. De eerste analyses wezen naar bestandsuploads en een specifiek onderdeel van PHP. Die konden we op de server tijdelijk dichtzetten, zonder de websites zelf uit de lucht te halen.
Echter, geen enkele tijdelijke maatregel is waterdichten. Ook het PHP-team benadrukte dat alleen de update het probleem echt zou verhelpen. Onze maatregelen waren dus een brug naar de update, geen vervanging ervan.
Wat wij hebben gedaan
- Bestandsuploads tijdelijk geblokkeerd. Op serverniveau hielden we alle verzoeken met bestandsuploads tegen, nog voordat ze PHP bereikten. Bezoekers merkten hier niets van. Alleen afbeeldingen toevoegen of bijlagen meesturen via een formulier werkte een paar uur niet.
- Het kwetsbare onderdeel uitgeschakeld. Het PHP-onderdeel dat in de eerste analyses als aanvalsroute werd genoemd, hebben we op alle PHP-versies uitgezet. Ook hebben we de sessie-instellingen aangescherpt.
- De beheeromgeving afgeschermd. De beheeromgeving van de server is alleen nog bereikbaar vanaf ons eigen netwerk.
- De update direct geïnstalleerd. Zodra de update beschikbaar was, hebben we hem nog dezelfde dag op alle PHP-versies op onze servers geïnstalleerd. Daarna hebben we alle processen herstart en gecontroleerd dat nergens nog de oude versie draaide.
- Uploads weer vrijgegeven. Pas toen de update overal actief was, hebben we de uploadblokkade opgeheven en getest dat alles weer werkte.
De drukte van die middag was ook bij ons te merken. De downloadservers voor de updates bezweken bijna onder het verkeer van beheerders over de hele wereld. Met wat geduld en een omweg via een andere bron stond de update er alsnog dezelfde dag op.
Hoe staat het er nu voor?
Alle websites op onze servers draaien op de gerepareerde PHP-versie en uploads werken weer normaal. De aangescherpte instellingen laten we staan: ze kosten niets en maken de servers net iets robuuster. Daarnaast lopen we de logbestanden van de afgelopen dagen na op sporen van misbruik.
Websites die nog op een oude PHP-versie draaien, kregen deze keer ook een reparatie. Dat is echter geen garantie voor de volgende keer. We nemen daarom contact op met de eigenaren van die websites om over te stappen naar een actuele versie.
Wat betekent dit voor jou?
- Wordt je website door ons gehost? Dan hoef je niets te doen. Alles is al geregeld.
- Wordt je website ergens anders gehost? Vraag je hostingpartij of de update is geïnstalleerd: PHP 8.2.35, 8.3.36, 8.4.27 of 8.5.12, of nieuwer. Twijfel je, laat het ons weten, dan kijken we met je mee.
Dit soort momenten laat zien waarom websiteonderhoud geen bijzaak is. Het verschil zit niet alleen in de update, maar in wat je doet in de uren voordat die er is. Vragen over je eigen website? Neem contact met ons op.