PHP2Shell uitgelegd: wat er aan de hand was met het PHP-lek
Op woensdag 21 oktober 2026 kwam er een dringende beveiligingsupdate uit voor PHP. Die update dichtte twee ernstige lekken, die al snel PHP2Shell werden genoemd. Overheidssites als DigiD en Overheid.nl en verschillende hostingbedrijven gingen die dag uit voorzorg offline. In dit artikel leggen we uit wat er aan de hand was, ook als je niets met techniek hebt. En we vertellen eerlijk wat wij hebben gedaan.
Heb je een website bij Theory7? Dan hoef je zelf niets te doen. Wij hebben de updates op al onze webhostingservers geïnstalleerd en per server gecontroleerd. We hoefden daarvoor geen enkele website uit voorzorg offline te halen. Wil je het zelf nakijken, dan lees je in dit artikel hoe dat werkt.
PHP2Shell in het kort
- Wat: twee ernstige lekken in PHP, CVE-2026-109618 en CVE-2026-109619, samen PHP2Shell genoemd.
- Ernst: 9,2 op een schaal van 10. Een aanvaller kon zonder wachtwoord een webserver overnemen.
- Wie: vrijwel elke website die op PHP draait. Dat is ongeveer 70 procent van het web.
- Oplossing: PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12, uitgebracht op 21 oktober 2026.
- Bij Theory7: bekende aanvalsroute dicht op woensdagochtend, alle servers bijgewerkt in de nacht van 21 op 22 oktober.
Wat is PHP eigenlijk?
Een website heeft twee kanten. De voorkant zie je in je browser: teksten, foto's, knoppen. De achterkant draait op een server en zorgt dat die voorkant op het juiste moment klopt. Vul je een contactformulier in, log je in bij een webshop of leg je iets in je winkelwagen, dan regelt de achterkant dat.
Vergelijk het met een restaurant. De eetzaal is wat de gast ziet. De keuken is waar het werk gebeurt. PHP is de taal waarin die keuken bij heel veel websites is ingericht.
En dat is niet overdreven. Volgens het onderzoeksbureau W3Techs draait ongeveer 70 procent van alle websites waarvan bekend is welke techniek ze gebruiken op PHP. WordPress is in PHP gebouwd, net als WooCommerce, Joomla, Drupal en Magento, en daarnaast talloze webshops, boekingssystemen en klantportalen. Een fout in PHP zelf is dus geen fout in één website. Het is een fout in het fundament onder een groot deel van het internet.
Wat is PHP2Shell precies?
Onderzoekers vonden twee fouten in de manier waarop PHP met het werkgeheugen van een server omgaat. Een server onthoudt tijdens zijn werk van alles in dat geheugen. Gaat er bij een verzoek iets mis, dan hoort PHP alles netjes op te ruimen. In bepaalde situaties gebeurde dat niet goed.
Je kunt het vergelijken met een hotel dat een kamer opnieuw verhuurt, terwijl de vorige gast nog een sleutelkaart heeft die werkt. Wie weet hoe hij die kaart moet gebruiken, komt binnen op een plek waar hij niets te zoeken heeft. Bij PHP2Shell kon een aanvaller op die manier de server zijn eigen opdrachten laten uitvoeren.
Drie dingen maakten PHP2Shell zo ernstig:
- Er was geen wachtwoord voor nodig. Een aanvaller kon het van buitenaf proberen, met een gewoon verzoek aan een website.
- De aanvaller kreeg de controle. In vaktaal heet dit remote code execution: de server doet wat de aanvaller zegt.
- Het zat in PHP zelf. Niet in een plugin of thema, maar in de basis. Vrijwel alle PHP-versies sinds 2012 waren kwetsbaar.
Beide lekken kregen een score van 9,2 op een schaal van 10 voor ernst. De officiële beschrijvingen staan in de beveiligingsadviezen van PHP voor CVE-2026-109618 en CVE-2026-109619.
Hoe kon dit gebeuren?
PHP bestaat al sinds 1995 en wordt door een grote groep vrijwilligers en bedrijven onderhouden. In zoveel code zitten altijd fouten, dat geldt voor alle software. Deze twee zaten in een hoek die je zelden tegenkomt: het moment waarop een server midden in een verzoek zonder geheugen komt te zitten. Zulke uitzonderingen zijn lastig te testen, en daardoor bleven de fouten jarenlang onopgemerkt.
Normaal verloopt het oplossen van zo'n lek in stilte. Onderzoekers melden het aan de makers, die maken een oplossing, en op een afgesproken dag verschijnen de update en de uitleg tegelijk. Zo hebben beheerders een voorsprong op aanvallers. De onderzoekers vonden deze lekken in augustus en meldden ze bij PHP. De update stond gepland voor donderdag 22 oktober.
Dat liep anders. Op dinsdag 20 oktober lekten de eerste details uit op internet. PHP haalde de update daarom een dag naar voren, naar woensdagmiddag. Volgens beveiligingsbedrijf Sansec zag Cloudflare op woensdagochtend al de eerste aanvalspogingen, nog voordat de update er was. Amazon meldt zelfs een poging van 17 oktober, vier dagen voor de bekendmaking.
Dat zorgde in Nederland voor een bijzondere woensdag. DigiD, MijnOverheid en Overheid.nl gingen uit voorzorg tijdelijk uit de lucht. Ook verschillende hostingbedrijven haalden websites van hun klanten offline, in afwachting van de update.
Wat heeft AI met PHP2Shell te maken?
AI speelde in dit verhaal aan twee kanten een rol.
Bij het vinden. De onderzoekers die PHP2Shell vonden, werkten met AI-modellen van onder meer OpenAI en Google. Google schrijft dat zijn model Gemini een grote bijdrage leverde, van het vinden van het lek tot het controleren van de oplossing. AI kan in korte tijd enorme hoeveelheden code doorlezen en patronen zien waar mensen overheen kijken. Dat is goed nieuws: oude, verstopte fouten komen sneller boven water.
Aan de andere kant. Dezelfde technologie is ook beschikbaar voor mensen met slechte bedoelingen. Het ombouwen van een beschrijving van een lek naar een werkende aanval kostte vroeger dagen of weken uitzoekwerk. Met AI gaat dat veel sneller. De tijd tussen "er is een lek bekend" en "de eerste aanvallen" wordt daardoor steeds korter. Bij PHP2Shell was dat minder dan een dag.
Voor een hostingbedrijf betekent dat: een update "ergens deze week" installeren is niet meer genoeg. Je moet vooraf precies weten wat er op welke server draait, en direct kunnen handelen als de update er is. Wij gebruiken daar zelf ook automatisering en AI voor, bijvoorbeeld om al onze servers tegelijk na te lopen zodat er nergens een vergeten PHP-versie blijft staan. Elke ingreep op een server gebeurde pas na akkoord van een van onze beheerders.
Wat hebben wij tegen PHP2Shell gedaan?
Bij ons kies je zelf welke PHP-versie je website gebruikt, van oudere versies tot de nieuwste. Dat betekent dat er op onze servers veel verschillende PHP-versies naast elkaar draaien, en die moesten allemaal bijgewerkt worden.
Het belangrijkste besluit namen we woensdagochtend. Het lek werkte via een bekende ingang: een onderdeel van PHP dat vrijwel geen enkele website gebruikt. Dat onderdeel hebben we op al onze webhostingservers en beheerde servers uitgezet, nog voordat de update er was. Daardoor konden we websites online laten, in plaats van ze uit voorzorg uit te zetten. Ook hebben we alle PHP-versies alvast bijgewerkt naar de nieuwste beschikbare versie, zodat de echte update daarna sneller kon.
| Wanneer | Wat er gebeurde |
|---|---|
| Augustus 2026 | Onderzoekers vinden de lekken, mede met AI, en melden ze bij PHP. |
| Dinsdag 20 oktober | Details lekken uit en PHP vervroegt de update. Wij brengen alle PHP-versies op al onze servers in kaart, ook op onze interne systemen. |
| Woensdag 21 oktober, ochtend | Wij zetten de bekende ingang voor de aanval dicht op al onze servers. Cloudflare ziet de eerste aanvalspogingen. |
| Woensdag 21 oktober, overdag | Overheidssites en verschillende hostingbedrijven gaan uit voorzorg offline. Wij hoeven websites niet offline te halen. |
| Woensdag 21 oktober, 15:38 | PHP brengt de update uit. Binnen het uur is onze eerste server bijgewerkt. |
| Woensdagavond | De standaard-PHP van al onze servers draait op de nieuwe versie. CloudLinux levert bijgewerkte versies, ook voor oudere PHP-versies. |
| Nacht naar donderdag 22 oktober | Alle PHP-versies op al onze webhostingservers zijn bijgewerkt. |
| Donderdag 22 oktober, ochtend | Eindcontrole op alle servers en interne systemen: niets vergeten. |
De PHP-versies die je zelf kiest voor je website komen van CloudLinux, het besturingssysteem op onze servers. CloudLinux maakt ook oplossingen voor oudere PHP-versies waar PHP zelf geen updates meer voor uitbrengt. Per server hebben we na de update gecontroleerd of die er echt in zat, en websites voor en na getest.
Wat had PHP2Shell kunnen aanrichten?
Stel dat een server niet op tijd bijgewerkt was. Wat kan een aanvaller dan met een website?
- Gegevens stelen. De database van een website bevat vaak namen, adressen, bestellingen en inloggegevens van klanten.
- Betalingen afluisteren. In een webshop kan stiekem code worden geplaatst die betaalgegevens van bezoekers afvangt, zonder dat de eigenaar iets merkt.
- Geheimen uitlezen. Via het geheugen van de server kunnen wachtwoorden en sleutels uitlekken, bijvoorbeeld die van de koppeling met je betaalprovider of boekhoudpakket.
- Je website misbruiken. Voor nep-inlogpagina's, spam of het doorsturen van bezoekers naar oplichterssites. Gevolg: Google waarschuwt bezoekers dat je site mogelijk gehackt is, en je e-mail belandt op zwarte lijsten.
Misschien denk je: mijn website is te klein om interessant te zijn. Helaas werkt het zo niet. Aanvallers zoeken niet met de hand naar slachtoffers. Ze laten programma's het hele internet afzoeken naar kwetsbare websites, binnen enkele uren na zo'n bekendmaking. Elke website met een kwetsbare PHP-versie is dan een doelwit, groot of klein.
En de schade blijft niet bij techniek. Lekken er persoonsgegevens uit, dan moet je dat als ondernemer melden bij de Autoriteit Persoonsgegevens. Daar komen herstelkosten, verloren omzet en een deuk in het vertrouwen van je klanten bij.
Bij ons draait elke website in een eigen afgeschermde omgeving. Gaat het ergens toch mis, dan komt een inbraak op de ene website niet zomaar bij de buren terecht. Dat is een extra veiligheidslaag, maar geen vervanging voor op tijd updaten.
Moet je zelf iets doen na PHP2Shell?
Voor de PHP-update zelf niet. Toch hebben we een paar tips:
- Controleer het als je wilt. In ons kennisbankartikel lees je hoe je ziet dat de update erin zit, en waarom je versienummer soms gelijk blijft.
- Gebruik je PHP 8.1 of ouder? Deze keer kwam er ook voor die versies een oplossing, maar dat is niet altijd zo. Stap over op PHP 8.2 of hoger. In dit artikel lees je hoe je de juiste versie kiest.
- Houd je website zelf bij. Wij zorgen voor de server en PHP. WordPress, plugins en thema's werk je zelf bij. Meer tips vind je in website beveiligen: 8 tips tegen hackers.
- Heb je elders een website of een eigen server? Controleer dan of PHP is bijgewerkt naar versie 8.2.35, 8.3.36, 8.4.27 of 8.5.12, of nieuwer.
De actuele stand van zaken bij storingen en onderhoud vind je altijd op status.theory7.net. Twijfel je over je eigen website, maak dan een ticket aan met je domeinnaam. We kijken het graag voor je na.
Lekken in software zullen blijven bestaan, ook in de basis van het internet. Wat telt is hoe snel ze gedicht worden. Daar waren we deze week druk mee, en zo blijven we het doen.
Veelgestelde vragen
Wat is PHP2Shell?
PHP2Shell is de bijnaam voor twee ernstige lekken in PHP (CVE-2026-109618 en CVE-2026-109619), bekendgemaakt op 21 oktober 2026. Een aanvaller kon er zonder wachtwoord een webserver mee overnemen. PHP heeft ze opgelost in versie 8.2.35, 8.3.36, 8.4.27 en 8.5.12.
Was mijn website bij Theory7 kwetsbaar?
Elke website die op PHP draait was in principe kwetsbaar tot de update. Wij hebben op woensdagochtend 21 oktober al een bekende ingang voor de aanval afgesloten en de updates daarna op al onze webhostingservers geïnstalleerd, de laatste in de nacht van 21 op 22 oktober.
Waarom gingen andere websites offline en die van Theory7 niet?
Wie de update niet kon afwachten zonder risico, haalde websites uit voorzorg offline. Wij hadden de bekende ingang voor de aanval woensdagochtend al dichtgezet, nog voor de update er was. Daardoor konden websites bij ons online blijven terwijl we de update installeerden.
Moet ik zelf iets doen?
Voor de PHP-update niet, die hebben wij geïnstalleerd. Gebruik je PHP 8.1 of ouder, dan raden we aan over te stappen op PHP 8.2 of hoger. Houd daarnaast je website zelf, zoals WordPress en plugins, up-to-date.
Hoe controleer ik of mijn PHP bijgewerkt is?
Kijk naar de builddatum van je PHP-versie. Staat daar 21 oktober 2026 of later, dan zit de update erin. In ons kennisbankartikel over de PHP-beveiligingsupdate lees je stap voor stap hoe je dat controleert.
