Kritiek PHP-lek raakt bijna elke website: de update die je hostingpartij moet draaien, niet jij

Op 21 oktober kreeg PHP, de taal waar WordPress en een groot deel van het zakelijke web op draait, een kritieke update voor twee lekken met de hoogst mogelijke risicoscore. Die update installeer je niet zelf: hij ligt bij je hostingpartij. Wat er gebeurde, en welke vraag je nu kunt stellen.

Op 6 oktober bracht WordPress een beveiligingsupdate uit met zeven afzonderlijke lekken, waaronder een kwetsbaarheid voor cross-site scripting en een voor SQL-injectie. Twee weken later, op 21 oktober, volgde een bericht van een heel andere orde. PHP zelf, de programmeertaal waar WordPress en talloze andere bedrijfswebsites op draaien, kreeg een kritieke update voor twee lekken met de hoogst mogelijke risicoscore. Voor wie een website beheert of laat beheren, is dat tweede bericht het belangrijkste, en tegelijk het makkelijkst te missen.

Beide updates kwamen met dezelfde boodschap: direct bijwerken. Maar waar de WordPress-update via het vertrouwde Dashboard, Updates scherm loopt, zit de PHP-update een laag dieper. Dat verschil bepaalt wie de update eigenlijk moet uitvoeren, en waarom je dat zelf vaak niet eens kunt, ook niet als je het zou willen.

Wat er in oktober precies gebeurde

WordPress 7.1.3 verhielp op 6 oktober zeven beveiligingsproblemen: onder meer een kwetsbaarheid voor cross-site scripting op het reactiescherm, een denial-of-service-fout in de functie die URL's verwerkt, en een lek waardoor een gebruiker met een beperkte rol berichten kon vastzetten zonder daar toestemming voor te hebben. Niets daarvan is op zichzelf wereldschokkend, maar samen laten ze zien dat een CMS dat een groot deel van het web aandrijft voortdurend onder de loep ligt, zowel van beveiligingsonderzoekers als van kwaadwillenden.

Op 21 oktober volgde een advisory van een andere orde. PHP maakte twee kritieke lekken bekend met een risicoscore van 9,2 op een schaal tot 10. Beide konden in theorie leiden tot het op afstand uitvoeren van code op een server, de ernstigste categorie die een kwetsbaarheid kan hebben. Binnen een dag stonden gerepareerde versies klaar: PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35.

Waarom dit een hostingvraag is, geen contentvraag

Een WordPress-update installeer je, of laat je installeren, via het CMS zelf. Een PHP-update ligt op een ander niveau: PHP draait op de server, onder je website, en wordt beheerd door de partij die die server beheert. Heb je zelf geen toegang tot de serverconfiguratie, een gangbare situatie bij gedeelde of beheerde hosting, dan kun je deze update niet zelf uitvoeren. Het risico zit dus niet in wat jij vergeet, maar in wat je hostingpartij wel of niet snel genoeg doet.

Dat maakt de keuze van een hostingpartij relevanter dan veel ondernemers beseffen. Een partij die server-updates automatisch en snel doorvoert, sluit zo'n lek vaak al binnen enkele dagen. Een partij die handmatig werkt, of pas reageert na een melding van een klant, laat een kritiek lek soms wekenlang openstaan zonder dat iemand het merkt.

Wat een risicoscore van 9,2 in de praktijk betekent

De officiële PHP-advisory noemt het risico het hoogst voor servers die draaien met mod_php, een veelgebruikte manier om PHP binnen de webserver te laten werken. Tijdelijke maatregelen, zoals het uitschakelen van een specifieke functie in de configuratie, verkleinen het risico enigszins, maar de enige volledige oplossing is updaten naar een van de gerepareerde versies. Voor een aanvaller die zo'n lek misbruikt, is het doel zelden die ene website die jij beheert. Geautomatiseerde scans zoeken continu naar servers die nog de oude versie draaien, ongeacht wie de eigenaar is.

Dat verklaart ook waarom de PHP-ontwikkelaars zo snel schakelden: binnen een dag na de eerste waarschuwing stonden de gerepareerde versies al klaar, inclusief een testversie van de volgende grote PHP-release die dezelfde reparatie meekreeg. Voor oudere PHP-versies die niet meer worden onderhouden, zoals de 8.1-lijn en ouder, is er geen officiële patch. Draait jouw website nog op zo'n oudere versie, dan is een upgrade naar een onderhouden versie op dit moment geen keuze meer, maar een voorwaarde om veilig online te blijven.

De vraag die je nu aan je hostingpartij kunt stellen

Je hoeft geen PHP-kennis te hebben om hier iets mee te doen. Eén gerichte vraag aan je hostingpartij of ontwikkelaar volstaat: welke PHP-versie draait mijn website op dit moment, en is de update van 21 oktober al doorgevoerd? Een helder en snel antwoord is een goed teken. Een ontwijkend antwoord, of de mededeling dat updates pas bij een volgend regulier onderhoudsmoment worden meegenomen, is een signaal om het gesprek over je hostingafspraken breder te voeren.

Vraag ook hoe vaak dit soort updates in het algemeen worden doorgevoerd: automatisch bij elke release, binnen een vaste termijn na een kritieke melding, of pas na een incident. Voor een website met een contactformulier, een webshop of een klantportaal is een structureel patchproces op serverniveau geen overdreven voorzorg. Het is de basis waarop de rest van je beveiliging rust.

Onderhoud dat je niet ziet, is nog steeds onderhoud

De meeste ondernemers zien hun website pas als een onderhoudsvraagstuk wanneer er iets zichtbaar misgaat: een trage pagina, een foutmelding, een gehackt contactformulier. De PHP-update van oktober speelt zich af op een niveau dat je nooit ziet, en dat maakt het risico makkelijk te onderschatten. Wil je weten welke PHP-versie je website op dit moment gebruikt, of zoek je een hostingpartner die kritieke updates binnen dagen doorvoert in plaats van maanden? Zarioh denkt met je mee over hosting waarbij dit onderhoud structureel geregeld is, niet pas na een incident.