PHP2Shell: waarom dit lek in PHP zo uitzonderlijk is

Op 21 oktober 2026 bracht PHP noodupdates uit voor twee kritieke beveiligingslekken. De naam die de veiligheidswereld eraan gaf: PHP2Shell. Overheden in onder meer Nederland en Finland haalden uit voorzorg websites offline, en ook in België gingen sites tijdelijk in onderhoud.

Er worden elke week lekken gevonden. Waarom dan zoveel ophef over deze? En wat betekent het voor jouw zaak?

Wat is er aan de hand?

PHP is de programmeertaal waarop het grootste deel van het web draait. WordPress, Drupal, Joomla en de meeste webshops gebruiken het. Volgens W3Techs draait ongeveer 70% van alle websites waarvan de servertaal gekend is op PHP.

In de kern van die taal zaten twee fouten, met de officiële nummers CVE-2026-109618 en CVE-2026-109619. Beide krijgen een ernstscore van 9,2 op 10. Ze laten een aanvaller toe om op afstand code uit te voeren op de server, zonder in te loggen. In gewone taal: iemand kan de controle over de server van je website overnemen, gegevens stelen of je site bekladden.

Waarom dit geen gewoon lek is

Vijf dingen maken PHP2Shell uitzonderlijk.

1. Het zit in de kern, niet in een plug-in

Meestal zit een lek in één WordPress-plug-in of één thema. Wie die plug-in niet gebruikt, heeft geen probleem. Hier zit het in PHP zelf. De onderzoekers toonden aan dat zelfs een simpel "Hello World"-scriptje op een getroffen versie kwetsbaar is. Je website kan perfect gebouwd zijn en toch openstaan.

2. Het zat er al meer dan tien jaar

Getroffen zijn PHP-versies 5.4 tot en met 8.5. Oudere versies die geen updates meer krijgen, worden ook niet meer hersteld. En op heel wat servers draait nog zo'n oude versie, omdat "het werkt".

3. Het werd gevonden met AI

De onderzoekers van Wiz Research gebruikten AI-modellen om de fouten op te sporen en te testen. Dat is goed nieuws en slecht nieuws tegelijk. AI vindt lekken sneller, maar helpt kwaadwillenden ook sneller om ze te misbruiken. Het werk om een lek om te zetten in een aanval wordt kleiner.

4. Het lekte uit vóór de oplossing klaar was

De details doken op 20 oktober al op sociale media op, twee dagen vóór de geplande bekendmaking. PHP moest de updates daardoor vervroegen. Beheerders hadden nauwelijks tijd om zich voor te bereiden.

5. Aanvallers waren er sneller bij dan de patch

Amazon zag al op 17 oktober een aanvalspoging in zijn lokservers, vier dagen vóór de bekendmaking. Cloudflare zag het aantal pogingen binnen 45 minuten na de bekendmaking oplopen tot tienduizenden, en tegen de volgende ochtend tot miljoenen.

Wat betekent dit voor jouw zaak?

Je hoeft als zaakvoerder niet te weten hoe het geheugen van PHP werkt. Je moet wel drie vragen kunnen beantwoorden:

Vraag	Waarom het ertoe doet
Draait mijn website op PHP?	Gebruik je WordPress, een klassieke webshop of een site met een beheerpaneel, dan is het antwoord bijna zeker ja.
Is de server bijgewerkt?	Veilig zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 of hoger. Een oudere versie moet vandaag nog bijgewerkt worden.
Wie is daarvoor verantwoordelijk?	Je hostingpartij, je webbouwer of je IT-partner. Weet je het niet, dan is dat het echte probleem.

Die laatste vraag is de belangrijkste. Veel kleine zaken hebben ooit een website laten maken, en sindsdien kijkt niemand er nog naar. De bouwer is verdergegaan, het hostingpakket wordt elk jaar betaald, en niemand voelt zich eigenaar van de updates. Precies zulke sites zijn het doelwit van automatische aanvallen die het hele internet afscannen.

Wat als het al misgegaan is?

Een server die gehackt is, ziet er niet altijd anders uit. Signalen zijn wel: vreemde pagina's of doorverwijzingen op je site, een melding van Google dat je site onveilig is, een hostingpartij die je site blokkeert, of klanten die spam krijgen "van jou". Dan volstaat updaten niet meer. Dan moet de site opgekuist of opnieuw opgebouwd worden, liefst vanaf een propere back-up. Waarom back-ups daarbij het verschil maken, lees je in back-ups voor je zaak: de 3-2-1-regel.

Onze kijk: minder onderdelen, minder risico

PHP2Shell toont iets wat we al langer zien: elke laag software op je server is iets dat je moet bijhouden. PHP, een database, een CMS, tien plug-ins, een thema. Elke laag kan een lek bevatten, en iemand moet het bijwerken.

Daarom bouwen we nieuwe websites statisch. Geen PHP, geen database, geen plug-ins op de server. De pagina's worden vooraf klaargemaakt en verspreid over een wereldwijd netwerk. Wat er niet is, kan ook niet lekken. Dat is geen oplossing voor elke toepassing, maar voor een gewone bedrijfswebsite is het vaak de slimste keuze. Hoe zo'n verhuis verloopt zonder je plaats in Google te verliezen, lees je in van WordPress naar een statische site.

PHP2Shell is ook een herinnering dat beveiliging geen eenmalig project is. Het is een gewoonte: weten wat je hebt, weten wie het bijhoudt en snel kunnen reageren als het nodig is. Hoe je dat als bedrijf aanpakt, staat in onze gids cybersecurity voor kleine bedrijven.

Veelgestelde vragen

Bronnen

1. Security Advisory 2026-018: Critical Vulnerabilities in PHP — CERT-EU
2. PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches — The Hacker News
3. PHP2Shell Vulnerabilities Put 70% of Websites at Risk — TidBITS
4. PHP2Shell: Waarom websites offline gaan voor noodzakelijke beveiligingsupdates — Malwarebytes
5. Usage statistics of PHP for websites — W3Techs

Gecontroleerd op 24 oktober 2026. Regels en prijzen veranderen; kijk bij twijfel de bron na.