WordPress en het PHP-lek: wat je vandaag regelt

WordPress is geschreven in PHP. Elke pagina die een bezoeker opvraagt, wordt door PHP op de server opgebouwd. De lekken CVE-2026-109618 en CVE-2026-109619 zitten in PHP zelf, in alle versies vanaf PHP 5, zo meldt Help Net Security. Een aanvaller hoeft dus geen zwakke plug-in te vinden: de server zelf is het doelwit.

Log in en ga naar Extra > Sitestatus > Info. Klap het onderdeel Server open. Daar staat de PHP-versie, bijvoorbeeld 8.2.34.

• 8.2.35, 8.3.36, 8.4.27, 8.5.12 of hoger in dezelfde reeks: je server is bijgewerkt.
• Een lager getal in die reeksen: vraag je hoster om vandaag te updaten.
• 8.1 of lager: er komt geen fix. Je moet naar een nieuwere reeks.

Geen toegang tot je beheer? De gratis PHP-check van Marketing Scan geeft van buitenaf een eerste indicatie.

Bij gedeelde hosting werkt de hoster PHP centraal bij. Bij de meeste hosters kun je ook zelf in het controlepaneel een PHP-reeks kiezen (bijvoorbeeld 8.3), en de hoster zorgt voor de laatste patch binnen die reeks.

Heb je een eigen server of VPS, dan is je webbouwer of beheerder verantwoordelijk. Vraag een bevestiging met het exacte versienummer.

Wie nog op PHP 7.4 of 8.0 draait, moet een grotere sprong maken. Oudere plug-ins en thema's werken soms niet op 8.2 of hoger. Zo pak je het veilig aan:

1. maak een volledige back-up (bestanden en database);
2. werk WordPress, je thema en alle plug-ins eerst bij naar hun laatste versie;
3. test bij voorkeur op een kopie van je site (een staging-omgeving, die de meeste hosters aanbieden);
4. schakel dan de PHP-versie om en klik de belangrijkste pagina's door: homepage, contactformulier, winkelmandje en betaling.

Plug-ins die al lang geen update kregen, zijn het grootste risico. Vervang ze liever nu dan later.

Een webshop bewaart klantgegevens en bestellingen. Wie via het PHP-lek binnenraakt, kan die gegevens inzien of de betaalstap manipuleren. Controleer na de update:

• dat bestellingen en betalingen normaal doorlopen;
• dat er geen onbekende beheerders bij Gebruikers staan;
• dat je betaalprovider (Mollie, Stripe, Payconiq) geen afwijkingen meldt.

Bij een datalek met persoonsgegevens moet je dat binnen 72 uur melden bij de Gegevensbeschermingsautoriteit.

Een beveiligingsplug-in draait zelf in PHP, na het moment waarop het lek misbruikt wordt. Ze kan het lek in PHP dus niet dichten. Een firewall vóór je site, zoals die van Cloudflare of je hoster, kan aanvallen wel tijdelijk afremmen. Toch geldt volgens Patchstack: bijwerken is de enige volledige oplossing.

PHP-lekken van deze omvang zijn zeldzaam, maar lekken in plug-ins zijn dat niet. Een paar gewoonten die het verschil maken:

• Kies een PHP-reeks die nog actief ondersteund wordt. Dan komt er bij een nieuw lek meteen een fix.
• Zet automatische updates aan voor kleine WordPress-versies en voor plug-ins die je vertrouwt.
• Ruim op. Elke uitgeschakelde of vergeten plug-in is een deur die openstaat.
• Laat je site wekelijks controleren. Met een gratis account bij Marketing Scan wordt je site elke week opnieuw nagekeken, ook op zichtbare softwareversies, en krijg je een melding als er iets verandert.

Het verschil tussen een site die bij het volgende lek offline moet en een site die op dezelfde dag bijgewerkt is, zit zelden in techniek. Het zit in wie verantwoordelijk is en hoe snel die het hoort.