Een woensdag waarop het internet even op slot ging
Op 21 oktober 2026 had je grote kans dat je op een website een onderhoudspagina zag, of een foutmelding waar je normaal een webshop of nieuwsbericht vindt. Dat lag niet aan jouw internetverbinding. Die dag bracht het PHP-team een spoedupdate uit voor twee kritieke kwetsbaarheden, en beheerders over de hele wereld haalden uit voorzorg websites tijdelijk uit de lucht.
Het ging niet om een paar kleine sites. Het Europese computercrisisteam CERT-EU raadde organisaties die niet direct konden patchen aan om hun websites van het internet te halen. Daarop gingen onder meer overheidsdiensten in Finland offline, en in Nederland de websites van het parlement, van cybersecurity-instanties en van de privacytoezichthouder. Ook de privacyorganisatie noyb haalde haar website tijdelijk weg.
De kwetsbaarheden kregen de naam PHP2Shell. Die naam klinkt dramatisch, en dat is ook de bedoeling: het lek kon een aanvaller in theorie een 'shell' geven, oftewel een opdrachtregel op jouw server.
Wat er precies mis was
Om te begrijpen waarom dit zo groot werd, helpt het om te weten wat PHP is. WordPress is geschreven in PHP. Je kunt PHP zien als de motor onder de motorkap: WordPress, je thema en je plugins zijn de carrosserie, het dashboard en de stoelen, maar PHP is wat de boel daadwerkelijk laat draaien. Niet alleen bij WordPress, ook bij Drupal, Joomla, Magento en talloze hostingpanelen.
De twee kwetsbaarheden (CVE-2026-109618 en CVE-2026-109619) zaten in die motor zelf. Ze kregen allebei een score van 9,2 op 10 en maakten het mogelijk om zonder in te loggen code uit te voeren op een server. In sommige serverconfiguraties kon dat zelfs al gebeuren voordat de code van de website zelf werd geladen. Een goed beveiligd WordPress, met een sterk wachtwoord en de nieuwste plugins, bood dan dus geen bescherming.
Twee dingen maakten dit lek bijzonder:
- Het was oud. Volgens onderzoekers van Wiz zat het probleem er al jarenlang in. Elke PHP-versie van het afgelopen decennium was kwetsbaar voor minstens een van de twee fouten.
- AI maakte het bruikbaar. De fout uitbuiten vroeg lange tijd zoveel stappen dat het in de praktijk lastig was. Met moderne AI-modellen werd die drempel volgens de onderzoekers flink lager. Daardoor veranderde een theoretisch probleem in een werkende aanval.
Censys telde zo'n 55 miljoen webomgevingen die op PHP draaien. Dat verklaart de schaal: dit raakte niet een niche, maar een flink deel van het internet.
Waarom haalden beheerders hun sites offline?
Het klinkt tegenstrijdig om je eigen website uit te zetten om hem te beschermen. Maar bekijk het als een gaslek: je sluit eerst de hoofdkraan en gaat daarna zoeken waar het lekt.
Vanaf het moment dat zo'n lek openbaar wordt, begint een race. Aanvallers gaan massaal scannen naar servers die nog niet zijn bijgewerkt. Cloudflare meldde al vroeg dat de eerste aanvallen zichtbaar waren. Wie niet binnen een paar uur kon patchen, koos dus liever voor een paar uur onderhoudspagina dan voor het risico dat er iemand binnenkwam.
Een belangrijke nuance: een website die tijdens PHP2Shell offline was, is daarmee niet gehackt. Tijdelijke downtime was in de meeste gevallen juist een teken dat iemand zijn werk goed deed.
Waarom op 'bijwerken' klikken deze keer niet hielp
Hier zit voor veel website-eigenaren de verrassing. Je WordPress-dashboard kan op alle fronten groen zijn: nieuwste WordPress-versie, alle plugins bijgewerkt, automatische updates aan. En toch was je kwetsbaar.
Dat komt doordat WordPress en PHP los van elkaar worden bijgewerkt. WordPress updaten verandert niets aan de PHP-versie op je server. Die versie wordt beheerd door je hostingpartij of door degene die je server onderhoudt. De reparatie zit in deze versies:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Draait je website nog op PHP 8.1 of ouder? Dan is er geen officiële reparatie. Die versies krijgen geen beveiligingsupdates meer, en dan zit er weinig anders op dan overstappen naar een ondersteunde versie. Dat is precies het soort klus dat je liever rustig plant dan midden in een crisis uitvoert.
Zo voorkom je dat je de volgende keer verrast wordt
Een lek in PHP kun je als website-eigenaar niet voorkomen. Wel kun je ervoor zorgen dat het voor jou een paar uur onderhoud betekent in plaats van een week stress. Dit zijn de punten die het verschil maken:
- Weet op welke PHP-versie je draait. In WordPress vind je dat onder Gereedschap > Sitediagnose > Info > Server. Staat daar een versie die niet meer wordt ondersteund? Zet het upgraden dan bovenaan je lijst.
- Weet wie PHP bijwerkt. Is dat je hostingpartij, je bureau of je eigen IT? Leg het vast. Bij een spoedupdate wil je niet eerst drie mails moeten sturen om erachter te komen wie de sleutel heeft.
- Vraag om bevestiging, niet om een belofte. 'We pakken het op' is iets anders dan 'PHP 8.4.27 is geïnstalleerd en de site werkt'. Vraag na een kritieke update om het versienummer en een korte controle van de belangrijkste functies.
- Houd PHP actueel, ook als er niets aan de hand is. Wie op een ondersteunde versie draait, krijgt een reparatie meestal met een kleine update. Wie achterloopt, moet onder tijdsdruk een grote sprong maken, inclusief het risico dat oudere plugins of maatwerk breken.
- Zorg voor een recente, werkende back-up. Liefst een die buiten je server staat en die ook echt teruggezet kan worden. Een back-up die je nooit hebt getest, is vooral een geruststelling.
- Gebruik een firewall voor je website. Een web application firewall, zoals die van Cloudflare, kan bekende aanvalspatronen tegenhouden terwijl de patch wordt uitgerold. Het is een tijdelijke pleister, geen vervanging voor de update zelf.
- Controleer achteraf op ongewenste bezoekers. Na een lek als dit proberen aanvallers vaak een achterdeurtje (een zogenoemde web shell) achter te laten. Een malwarescan en controle op onbekende bestanden na het patchen geeft zekerheid.
- Heb een nette onderhoudspagina klaarstaan. Moet je site toch even offline, dan zien bezoekers liever 'we zijn zo terug' dan een kale foutmelding.
Wat je hier als ondernemer van meeneemt
PHP2Shell laat zien dat de veiligheid van je website niet ophoudt bij het WordPress-dashboard. Onder je website zit een hele stapel techniek, en elke laag heeft iemand nodig die er verantwoordelijk voor is. Op 21 oktober werd duidelijk wie dat goed had geregeld: zij hadden een paar uur onderhoud en gingen daarna gewoon door.
Bij WPDirect kijken we daarom naar meer dan alleen plugin-updates. Technisch onderhoud, monitoring en beveiliging horen bij elkaar, net als duidelijke afspraken over wie wat doet als het erop aankomt. Wil je weten of jouw website op een veilige PHP-versie draait? Laat het ons weten, dan kijken we even met je mee.
