PHP-lek: wat betekent het voor je WordPress-website?

Wat er op 21 oktober 2026 gebeurde

Op dinsdag 20 oktober lekten de eerste details uit over twee nieuwe kwetsbaarheden in PHP, die al snel de naam PHP2Shell kregen. In het nieuws heette het “het veiligheidslek in computertaal PHP” of “het beveiligingslek in programmeertaal PHP”: dat zijn telkens dezelfde twee lekken. Het gaat om CVE-2026-109618 en CVE-2026-109619. Het PHP-securityteam gaf beide een CVSS-score van 9,2 op 10. Via beide lekken kan een aanvaller op afstand code uitvoeren: met een gewoon verzoek aan de website laat hij eigen code draaien op de server. Dat kan uitlopen op gestolen gegevens, een bekladde website of een volledig overgenomen server.

Het vervelende was de timing. De patch stond pas woensdagnamiddag gepland, terwijl de details al rondgingen. Volgens Sansec meldde Cloudflare woensdagochtend de eerste aanvalspogingen. Het Nederlandse Nationaal Cyber Security Centrum (NCSC) en de PHP Foundation zagen in de loop van de dag nog geen actief misbruik. Veel organisaties wilden dat risico niet lopen en zetten hun site op zwart, zoals de NOS en De Morgen de hele dag bijhielden.

Iets voor 16 uur Belgische tijd verscheen de update. Volgens de advisory op php.net dichten PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12 beide lekken. Het PHP-project noemt het risico het hoogst bij servers met Apache en mod_php. Wie PHP 8.1 of ouder draait, krijgt van het PHP-project zelf geen update meer. Voor 7.4, 8.0 en 8.1 bestaan alleen minimale broncode-fixes, en de meeste hosts moeten zo’n site dus eerst naar een recentere PHP-versie overzetten.

Waarom je WordPress-website hier rechtstreeks bij betrokken is

WordPress is geschreven in PHP. Elke keer dat iemand een pagina van je site opvraagt, start de server PHP op, haalt WordPress de inhoud uit een database en bouwt PHP de pagina op dat moment op. Dat is precies het moment waarop dit lek toeslaat.

Het lek zit vóór WordPress, niet erin

Bij de meeste WordPress-problemen gaat het om een verouderde plugin of een zwak wachtwoord. Daar kan een beveiligingsplugin of een update van WordPress iets aan doen. Deze keer niet. PHP verwerkt het binnenkomende verzoek al voordat WordPress ook maar één regel code uitvoert. Sansec wijst er zelfs op dat de ingebouwde onderhoudsmodus van WordPress niet helpt: PHP heeft het verzoek dan al verwerkt.

Het herstel gebeurt dus op serverniveau. Op gedeelde hosting, het pakket waar de meeste kleine bedrijven mee werken, kun je dat niet zelf doen. Je bent afhankelijk van je host: hoe snel die de update installeert en de PHP-processen herstart.

Wat je nu doet

Je hoeft geen developer te zijn om na te gaan of je site veilig is. Loop dit lijstje af:

• Kijk je PHP-versie na. In WordPress vind je die onder Extra > Sitestatus > Info > Server.
• Vergelijk die met de veilige versies: 8.2.35, 8.3.36, 8.4.27 of 8.5.12, afhankelijk van je reeks. Een lager nummer binnen dezelfde reeks is nog niet bijgewerkt.
• Vraag je host schriftelijk of PHP is bijgewerkt en of de PHP-processen herstart zijn. Een update die nog niet actief is, beschermt niets.
• Draait je site op PHP 8.1 of ouder? Vraag dan een overstap naar een ondersteunde versie, liefst 8.3 of hoger: PHP 8.2 krijgt volgens php.net nog maar beveiligingsupdates tot 31 december 2026. Maak eerst een back-up die je ook echt kunt terugzetten, want oude thema’s en plugins werken niet altijd met een nieuwere PHP-versie.
• Gebruik je Cloudflare? Cloudflare heeft volgens Sansec firewallregels tegen de bekende aanvallen uitgerold, ook op het gratis plan. Dat is een noodoplossing, geen vervanging voor de update.
• Kijk daarna na of er geen onbekende beheerders in je WordPress zijn bijgekomen en of je site nog doet wat ze moet doen.

Een vaste onderhoudsroutine met updates, back-ups en controles beschrijf ik apart in WordPress onderhoud: wat het inhoudt en wat het kost. Zo’n routine had dit lek niet voorkomen, maar je weet dan wel wie je belt en hoe je terug kunt.

Als je WordPress-site te oud is om nog bij te werken

Voor sommige sites is “werk PHP bij” makkelijker gezegd dan gedaan. Oudere WordPress-installaties draaien soms op plugins of een thema die niet meer onderhouden worden: ze zijn end of life, en de maker brengt geen updates meer uit. Zo’n plugin werkt vaak niet meer op een recente PHP-versie of een nieuwe WordPress. Daarom bleef de hele site op een oude versie hangen.

Een lek als dit zet je dan voor een lastige keuze. Of je blijft draaien op een PHP-versie die geen beveiligingsupdates meer krijgt, of je werkt bij en aanvaardt dat delen van je site stoppen met werken. Herstellen betekent dan verouderde plugins vervangen, het thema aanpassen en alles opnieuw testen. Dat is vaak bijna evenveel werk als een nieuwe website bouwen.

Op dat punt loont het om de vraag breder te stellen: heb je nog WordPress nodig, of past een statische site beter bij wat je website vandaag doet? Ben je klant van ons en draait je site nog op zo’n oudere WordPress-installatie, dan bekijken we graag samen wat de verstandigste keuze is: bijwerken, vervangen of opnieuw bouwen.

Waarom een statische website hier geen last van heeft

Er bestaat ook een andere manier om een website te bouwen. Bij een statische website worden alle pagina’s vooraf gebouwd, één keer, op het moment dat je iets publiceert. Het resultaat is een map met gewone HTML-, CSS- en JavaScript-bestanden. Die bestanden staan op een CDN, een netwerk van servers dat ze zo dicht mogelijk bij je bezoeker aflevert.

Als iemand zo’n pagina opent, draait er geen PHP en wordt er geen database aangesproken. De server stuurt een bestand dat al klaarstond. Een lek in PHP heeft dan niets om aan te haken: er is geen PHP. Terwijl organisaties in België en Nederland op 21 oktober hun PHP-servers aan het patchen waren, hoefde er voor zo’n site niets te gebeuren. En bij een volgend PHP-lek is dat niet anders.

Deze website is daar zelf een voorbeeld van. Straffe Sites draait als statische Astro-site op Vercel. Het handvol serverfuncties die er zijn, voor formulieren en offertes, draaien in Node.js en niet in PHP. Voor deze site hoeven we bij dit lek niets te patchen of offline te halen. Dat betekent niet dat het lek ons niets aangaat: we hosten en onderhouden ook WordPress-sites van klanten, en daar geldt alles uit de vorige sectie net zo goed.

En als je zelf teksten wilt aanpassen?

Daar dient een headless CMS voor. In een headless opzet beheer je je inhoud in een CMS zoals Storyblok, dat bij de leverancier draait. Bij elke publicatie haalt de build de inhoud op en maakt er opnieuw statische pagina’s van. Je beheeromgeving staat dus niet op je eigen domein, en je bezoekers praten nooit met het CMS. De leverancier onderhoudt en patcht zijn eigen platform, met een eigen beveiligingsteam. Hoe zo’n traject verloopt, lees je op de pagina over een headless website laten bouwen.

Statisch is niet hetzelfde als onkwetsbaar

Het zou oneerlijk zijn om te doen alsof een statische website niet gehackt kan worden. Het aanvalsoppervlak is kleiner, maar het verdwijnt niet. Het verschuift naar andere plekken:

• Je hostingaccount en je Git-account. Wie daar binnenraakt, kan je site aanpassen. Zet overal tweestapsverificatie aan.
• Je domeinnaam en DNS-instellingen bij je registrar. Ook die verdienen een sterk wachtwoord en tweestapsverificatie.
• Scripts van derden, zoals chatwidgets, advertentiepixels en embeds. Elk extern script is code die je niet zelf beheert.
• Formulieren. Die sturen gegevens naar een dienst of serverfunctie, en die moet zelf veilig zijn.
• De pakketten die je bouwproces gebruikt. Die houd je bij, net zoals je WordPress-plugins zou bijhouden, alleen minder vaak en zonder dat bezoekers er rechtstreeks bij kunnen.

Wanneer statische HTML niet de juiste keuze is

Smartschool, DigiD of de website van Infrabel kun je niet in een paar HTML- en JavaScript-bestanden steken. Achter zulke platformen zitten logins, persoonsgegevens, roosters, berichten en koppelingen met andere systemen. Die hebben echte servertoepassingen nodig, en dus teams die patchen wanneer het misloopt. Dat ze op 21 oktober uit voorzorg offline gingen, was een verantwoorde keuze.

Hetzelfde geldt, kleiner, voor een webshop met veel productlogica, een ledenzone of een reserveringssysteem. Daar heb je serverlogica nodig, in PHP of in een andere taal. En werkt je WordPress-site goed, met een host en een webbouwer die snel reageren als het nodig is, dan is er geen reden tot paniek.

Maar de meeste websites van zelfstandigen en kleine bedrijven zijn geen platform. Ze tonen wie je bent, wat je doet, een paar referenties, een blog en een contactformulier. Voor zo’n site is een server die elke pagina live opbouwt een zware motor voor een korte rit. Je betaalt ervoor met onderhoud, updates en dagen zoals 21 oktober.

Van WordPress naar een statische site: hoe dat gaat

Een overstap begint met een inventaris: welke pagina’s, blogs en formulieren heb je, en welke adressen leveren nu bezoekers op uit Google. De inhoud wordt overgezet, de pagina’s worden opnieuw gebouwd in Astro, en oude adressen krijgen een redirect als ze veranderen. Formulieren gaan naar een aparte dienst of een kleine serverfunctie. Wil je zelf blijven publiceren, dan komt er een headless CMS bij. Wil je dat niet, dan kan de inhoud gewoon in de code leven, zoals bij deze site. Hoe dat werkt, beschrijf ik in een website zonder CMS.

De keuze tussen beide systemen leg ik uitgebreider uit in Storyblok vs WordPress. Wil je weten hoe wij zo’n site bouwen, dan lees je dat op de pagina over een Astro-website laten maken. En vraag je je na dit lek af of jouw site anders kan, stel je vraag. We kijken eerlijk mee, ook als het antwoord is dat je WordPress-site prima is zoals ze is.