Is mijn website kwetsbaar voor het PHP-lek? Zo check je het

Dat is de eerste vraag. Een paar vuistregels:

• WordPress, WooCommerce, Joomla, Drupal, PrestaShop, Magento: altijd PHP.
• Shopify, Wix, Squarespace, Webflow: geen PHP op jouw verantwoordelijkheid; het platform beheert de servers.
• Maatwerk: vraag het aan wie het bouwde.

Twijfel je over welk systeem je site gebruikt, dan toont de PHP-check het meestal meteen, omdat sites vaak sporen achterlaten zoals een wp-login.php-pagina.

Een veilige site draait op een van deze versies of hoger binnen dezelfde reeks: 8.2.35, 8.3.36, 8.4.27 of 8.5.12. Dat zijn de versies met de fix, zie de officiële releases van PHP.

Je vindt de versie op drie manieren:

1. in het controlepaneel van je hoster (cPanel, Plesk, DirectAdmin), meestal onder "PHP-versie";
2. in WordPress via Extra > Sitestatus > Info > Server;
3. door het te vragen aan je hoster of webbouwer.

Let op: "PHP 8.3" zonder het laatste cijfer zegt niets. 8.3.35 is kwetsbaar, 8.3.36 niet.

De gratis PHP-check van Marketing Scan doet één gewone aanvraag naar je homepage, zoals een browser dat doet, en leest wat de server daarover vertelt. Dat levert een van vier uitkomsten op:

• Verouderd: de server toont een PHP-versie die geen fix krijgt. Dringend.
• Niet bijgewerkt: een versie binnen een ondersteunde reeks, maar zonder de fix. Vandaag updaten.
• Verborgen: je site gebruikt PHP, maar toont de versie niet. Dat is op zich goed, maar je moet het nog navragen.
• Geen PHP gevonden: geen sporen van PHP. Waarschijnlijk niet getroffen.

De check probeert het lek nooit uit. Hij kan dus ook niets kapotmaken, en hij geeft geen garantie: alleen je hoster kan de versie op de server bevestigen.

Stuur je hoster of webbouwer dit bericht:

"Naar aanleiding van CVE-2026-109618 en CVE-2026-109619: draait onze website op PHP, en zo ja, op welke exacte versie? Is die bijgewerkt naar 8.2.35, 8.3.36, 8.4.27 of 8.5.12?"

Krijg je binnen een werkdag geen duidelijk antwoord, bel dan. Bij een lek met een CVSS-score van 9,2, zoals Tenable rapporteert, is een dag wachten al lang.

Een paar dingen geven vals vertrouwen:

• "Mijn site heeft een slotje (https)." Dat beveiligt de verbinding, niet de server.
• "WordPress is up-to-date." WordPress en PHP zijn twee aparte dingen. Een bijgewerkte WordPress op een oude PHP-versie blijft kwetsbaar.
• "Ik heb een beveiligingsplug-in." Die draait zelf op PHP en kan het lek in PHP niet dichten.
• "Er is nog niets gebeurd." Volgens VRT NWS ziet Cloudflare al de eerste aanvalspogingen.

Signalen zijn onder meer: onbekende beheerders in je CMS, nieuwe bestanden met vreemde namen, doorverwijzingen naar andere sites, of een waarschuwing van Google in Search Console. Merk je zoiets, vraag je webbouwer dan om naast de update ook een controle op achtergelaten bestanden. Een update sluit de deur, maar haalt geen inbreker weg die al binnen is.

Dan ligt de bal bij jou, want jij bent verantwoordelijk voor de gegevens die via je site binnenkomen. Drie opties, van snel naar grondig:

1. Zet zelf een nieuwere PHP-reeks aan in het controlepaneel van je hoster, als dat kan. Maak eerst een back-up.
2. Zet een firewall vóór je site, bijvoorbeeld via Cloudflare. Volgens VRT NWS rolde Cloudflare al regels uit tegen dit lek. Dat koopt tijd, maar lost het niet op.
3. Zet je site in onderhoudsmodus als je gevoelige gegevens verwerkt en niemand op korte termijn kan updaten.

Een webbouwer die na een lek van deze omvang dagen niets laat horen, is ook een signaal voor de lange termijn. Leg bij je volgende contract vast binnen welke termijn kritieke beveiligingsupdates gebeuren.