Op 21 oktober heeft PHP een beveiligingsupdate uitgebracht voor twee kritieke lekken. Via die lekken kan iemand zonder in te loggen code uitvoeren op je server. Dat staat in het beveiligingsadvies op php.net. PHP schrijft er zelf bij: update meteen.

Waarom dit ook jou raakt: WordPress en WooCommerce draaien op PHP. Heb je een WordPress-site of -webshop, dan draait die server vrijwel zeker ook PHP. Het lek zit niet in WordPress, een plugin of je thema. Het zit een laag dieper.

Welke versies veilig zijn

Veilig zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Alles daaronder binnen die reeksen is kwetsbaar. Het gaat om CVE-2026-109618 en CVE-2026-109619, allebei met een CVSS-score van 9.2.

Volgens PHP loopt elke installatie risico die webverkeer afhandelt: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het risico is het grootst bij mod_php. Daar heeft PHP een aanval aangetoond waarbij één verzoek genoeg is, nog voordat WordPress zelf iets doet.

PHP 8.1 en ouder krijgen van het PHP-project zelf geen updates meer. Wel heeft het securityteam deze keer kleine bronpatches gemaakt voor 7.4, 8.0 en 8.1, en sommige Linux-distributies en hosters leveren eigen fixes. Daar moet je dus actief naar vragen.

Ook goed om te weten: PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer. Wie nu een upgrade plant, kan beter meteen door naar 8.3 of hoger.

Het Europese CERT-EU gaf op 21 oktober hetzelfde advies: inventariseer waar PHP draait en patch direct (advies 2026-018). De Amerikaanse cyberdienst CISA gaat een stap verder: patch meteen, en wie dat niet kan of nog op PHP 8.1 of ouder draait, haalt die systemen offline tot ze bijgewerkt zijn.

En er wordt al aan gemorreld. Amazon zag in zijn honeypots een eerste aanvalspoging op 17 oktober, vier dagen voor de bekendmaking, en daarna brede pogingen vanaf meerdere partijen (AWS Security Blog). Securitybedrijf Sophos trok een eerdere melding over een geslaagde inbraak weer in (Sophos), maar het Nederlandse Nationaal Cyber Security Centrum kreeg op 22 oktober wel signalen van succesvol misbruik (NOS). Minister Van Weel zegt dat de impact fors kan zijn. Gestolen data is tot nu toe niet bekend, en de Autoriteit Persoonsgegevens had nog geen datalekmeldingen binnen (ND). Wachten is dus geen optie meer.

Wat het betekent voor je WordPress-site

Bij de meeste kleine bedrijven draait de site bij een hostingpartij. Die bepaalt welke PHP-versie er draait en wanneer die wordt bijgewerkt. Jij kunt PHP meestal niet zelf patchen. Je hoster wel.

Daar zit voor mij het risico. Goede hosters patchen dezelfde dag. Goedkope pakketten of servers die ooit door een freelancer zijn ingericht, worden soms weken niet aangeraakt. En wie nog op PHP 8.1 of ouder draait, is afhankelijk van een hoster die zelf fixes terugzet. Doet die dat niet, dan is een upgrade naar een nieuwere PHP-versie het enige echte antwoord. Dat vraagt even testen of je thema en plugins meekomen.

Een WordPress-update doet hier niks. Een securityplugin ook niet echt, want die draait zelf op PHP.

Het lek zit niet in WordPress. Het zit in de motor eronder, en die wordt beheerd door je hoster.

PHP noemt wel tijdelijke instellingen die het risico verkleinen, zoals een lagere post_max_size en het uitzetten van session.upload_progress. Dat is werk voor je hoster of ontwikkelaar, en PHP zegt er nadrukkelijk bij dat het geen vervanging is voor de update.

Sites die op Next.js en Vercel draaien, zoals de sites die ik nu bouw, draaien geen PHP. Die raakt dit lek dus niet. Dat zeg ik niet om te verkopen, maar omdat het voor je risicoplaatje uitmaakt welke techniek onder je site zit.

Wat je nu doet

  1. Zoek op welke PHP-versie je site draait. In WordPress staat dat onder Gereedschap, Sitediagnose, tabblad Informatie, onderdeel Server.
  2. Staat daar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 of hoger? Dan is je hoster bij. Staat er iets lagers, mail of bel dan vandaag je hoster en vraag wanneer de update erop staat.
  3. Draai je op PHP 8.1 of ouder, vraag dan of je hoster een eigen fix heeft doorgevoerd. Zo niet, plan deze week een upgrade. Eerst op een testomgeving, dan live.
  4. Check of je een recente back-up hebt die buiten je hostingpakket staat.
  5. Kijk na de update of je site, je checkout en je formulieren nog werken.

Waar begin je

Weet je niet bij wie je site gehost wordt, of wie er de sleutels van heeft? Dan is dit een goed moment om dat uit te zoeken. Dat is vaak het eigenlijke probleem: niet het lek, maar dat niemand zich verantwoordelijk voelt.

Wil je dat ik meekijk naar je hosting en PHP-versie, of naar wat het kost om van een verouderde setup af te komen? Neem contact op.