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

Wat is het PHP-lek (PHP2Shell)?

Het PHP-lek, ook PHP2Shell genoemd, bestaat uit twee kritieke kwetsbaarheden in de programmeertaal PHP. Via die lekken kan een aanvaller op afstand code uitvoeren op een webserver.

Stand van zaken op 11 november 2026: volgens het nieuwsarchief van php.net is er sinds de updates van 21 oktober geen nieuwe gewone release voor PHP 8.2 tot en met 8.5 verschenen. De veilige versies verderop in dit artikel kloppen dus nog. De noodinstelling session.upload_progress.enabled op Off blijft aangeraden tegen het latere lek CVE-2026-115560.

De eerste details lekten uit op dinsdag 20 oktober. 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.

Met een gewoon verzoek aan de website laat een aanvaller 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 nieuwe release meer. Voor 7.4, 8.0 en 8.1 bestaan alleen minimale broncode-fixes.

Toch hoeft zo’n server niet onbeschermd te blijven. Ondřej Surý, die de veelgebruikte PHP-pakketten voor Debian en Ubuntu onderhoudt, bracht op 21 oktober gepatchte pakketten uit voor onder meer PHP 7.3, 7.4 en 8.1. Die zijn er alleen voor recente systemen: Ubuntu 22.04 en 24.04 en Debian 11 tot en met 13. Op een oudere server kan een beheerder PHP ook zelf opnieuw compileren met de fix. Een oude PHP-versie patchen kan dus wel, maar niet elke host doet het, en het blijft een noodoplossing.

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 waarschijnlijk nog niet bijgewerkt. Vraag het bij twijfel na bij je host.
• Vraag je host schriftelijk of PHP is bijgewerkt en of de PHP-processen herstart zijn. Een update die nog niet actief is, beschermt niets. Sommige hosts zetten als noodmaatregel tegen PHP2Shell ook session.upload_progress.enabled op Off. Die instelling werkt pas nadat PHP-FPM opnieuw geladen is.
• Vraag je host om die noodinstelling ook na de update te behouden. Op 23 oktober meldde php.net nog een apart lek, CVE-2026-115560, dat de updates van 21 oktober niet dichten. Het treft alleen toepassingen die de instelling session.serialize_handler tijdens het draaien omzetten, en PHP noemt dat in de praktijk onwaarschijnlijk. Dezelfde noodinstelling beschermt ertegen tot de volgende gewone PHP-release. Op 11 november 2026 was die er nog niet.
• Draait je site op PHP 8.1 of ouder? Vraag je host dan niet alleen óf PHP is bijgewerkt, maar ook of dat geldt voor jouw oudere versie, zoals 7.4. Dat kan, ook al ondersteunt het PHP-project die versie zelf niet meer. Plan daarna 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. Zie je iets vreemds? Meld het dan aan je host, wijzig alle wachtwoorden en laat een back-up van vóór 20 oktober terugzetten.

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.

Voor de oudere WordPress-sites van onze eigen klanten hebben we die keuze kunnen uitstellen. Ons hostingpaneel, RunCloud, patcht alleen PHP 8.2 en nieuwer, en voor oudere Ubuntu-versies zelfs dat niet meer. Daarom bouwden we op de avond van 21 oktober elke geïnstalleerde PHP-versie van 5.6 tot en met 8.1 zelf opnieuw met de fixes, zodat die sites beschermd waren zonder PHP-overstap. Hoe we dat deden en hoe we controleerden dat er voor de sites niets veranderde, beschrijf ik in een Engelstalige uitwerking op dev.to over PHP 5.6 tot 8.1 patchen tegen PHP2Shell.

Omdat andere beheerders met hetzelfde probleem zitten, staan de 25 builds, de patches en de bouwscripts sinds 24 oktober openbaar op GitHub: gepatchte PHP-builds voor RunCloud op Ubuntu 16.04 tot 24.04. Het zijn onofficiële builds zonder garantie, los van RunCloud en het PHP-project. Ze zijn bedoeld voor serverbeheerders, niet voor een gewone WordPress-eigenaar op gedeelde hosting. Het blijft ook een noodoplossing. Met die scripts is het volgende PHP-lek een kwestie van opnieuw bouwen, maar we moeten het nog altijd zelf dichten. De echte oplossing is een overstap naar een actuele server en PHP-versie.

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 ook WordPress-sites van klanten en verzorgen daar het website-onderhoud. Voor die sites 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.