Loopt je WordPress website risico door het PHP2Shell lek?

Draait je website op WordPress, dan draait hij ook op PHP, en dan raakt PHP2Shell jou ook. Het is een ernstig lek in PHP zelf, de software op de server waar WordPress op werkt. Het goede nieuws is dat de oplossing helder is. Je zorgt dat je website op een PHP-versie draait die bijgewerkt wordt, en je checkt bij je hostingpartij dat de update van vandaag echt op je server staat.

In dit artikel laat ik je zien hoe je je PHP-versie vindt, wat je je hostingpartij vraagt en wanneer je weet dat het geregeld is. Ik houd het bij zolang er nieuws bijkomt.

Wat er sinds de aankondiging is gebeurd

• 21 oktober, 21:19. De websites die ik host zijn weer online. Alle servers draaien nu de officiële updates, PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Omdat de pakketbronnen vanavond overbelast waren, hebben we de officiële pakketten zelf actief opgehaald in plaats van te wachten tot ze vanzelf binnenkwamen. Rond 20:40 waren ze geïnstalleerd, en per server hebben we gecontroleerd dat de nieuwe versie draait. Sinds 20:45 zijn de websites en webshops weer bereikbaar. We hebben de hele dag geen tekenen van misbruik gevonden. Webmail komt later weer online. Heb je een website bij een andere hostingpartij, vraag dan na of PHP is bijgewerkt naar minimaal 8.2.35, 8.3.36, 8.4.27 of 8.5.12. Draai je nog op PHP 8.1 of ouder, stap dan over naar 8.3 of hoger.
• 21 oktober, 20:25. De updates van php.net zijn uit, en daarna moeten ze nog via de pakketbronnen naar de servers. Die bronnen zijn vanavond erg druk en traag, omdat iedereen tegelijk dezelfde updates ophaalt. Bij ons staan de updates voor PHP 8.4 en 8.5 sinds 20:00 klaar, en die voor 8.2 en 8.3 komen nu binnen. We halen ze actief zelf op, installeren ze en controleren per server dat de nieuwe versie draait. Tot dat gecontroleerd is, blijven de servers bewust offline, want de tussenmaatregelen die er bestaan zijn geen garantie. Bij ons zijn geen tekenen van misbruik gevonden. Voor zover bekend zag Patchstack tot nu toe alleen verkennende pogingen en geen geslaagde aanvallen. De volgende update komt zodra de servers weer online zijn.
• 21 oktober, 16:12. Het Nederlandse NCSC heeft een advies uitgebracht en adviseert de beveiligingsupdates met spoed toe te passen. Volgens Sansec zijn de technische details en een aanvalstool nu openbaar, en daardoor verwacht Sansec grootschalige aanvallen. Volgens Sansec en Patchstack heeft Calif, het bedrijf dat de lekken bij PHP meldde, laten zien dat ook een actuele versie van WordPress zonder inloggen aan te vallen is. Patchstack ziet kort na de update nog alleen verkennende pogingen. Wachten is nu geen optie meer. Laat je hostingpartij PHP vandaag bijwerken, of haal je website offline tot dat gebeurd is.
• 21 oktober, 15:52. php.net heeft de update uitgebracht. De fixversies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. php.net bevestigt dat een aanvaller via de twee lekken code op de server kan uitvoeren zonder in te loggen. Elke PHP-installatie die webverzoeken afhandelt loopt risico, ook PHP-FPM, een gangbare opstelling bij hosting. Vraag je hostingpartij nu of jouw website op een van deze versies draait en of PHP daarna opnieuw gestart is.
• 21 oktober, 15:32. Patchstack ziet in de eigen metingen tot nu toe alleen pogingen om te verkennen welke servers kwetsbaar zijn, en nog geen hard bewijs van inbraken. Het bedrijf verwacht wel dat dit verandert zodra de details van de update openbaar worden. Het Britse NCSC geeft hetzelfde advies als ik. Kan een organisatie niet direct bijwerken, dan haalt die het systeem volgens het NCSC beter offline tot het volledig beschermd is.
• 21 oktober, 14:42. Wij hebben vandaag uit voorzorg besloten alle servers tijdelijk van internet te halen. Daardoor zijn de websites die ik host op dit moment offline en tijdelijk niet bereikbaar. Er zijn geen aanwijzingen van misbruik. Een exacte hersteltijd is er nog niet. De websites komen weer online zodra de officiële update van php.net geïnstalleerd en gecontroleerd is, en de verwachting is dat dat vanavond lukt. Dat is ook mijn advies aan jou. Weet je niet zeker dat je PHP-versie gepatcht of afgeschermd is, haal je website dan tijdelijk offline tot de officiële update van vandaag 16:00 staat.
• 21 oktober, 13:29. Volgens de NOS halen Nederlandse organisaties uit voorzorg websites offline, waaronder MijnOverheid, DigiD, de Tweede Kamer, het NCSC en de Autoriteit Persoonsgegevens. Ook Notubiz, het systeem waarmee ongeveer honderd gemeenten vergaderen, staat uit. Het NCSC heeft volgens de NOS nog geen actief misbruik gezien en vraagt bedrijven PHP zo snel mogelijk bij te werken. Zodra de release van 16:00 er is, werk ik dit artikel bij met de getroffen versies en de fixversies.
• 21 oktober, ochtend. Patchstack krijgt van meerdere hostingpartijen meldingen van aanvalspogingen, en ook Cloudflare ziet de eerste aanvallen. Andere beveiligingsbedrijven hadden op dat moment nog geen aanvallen gezien. Cloudflare zegt dat het aanvallen afvangt, ook voor gratis accounts, maar noemt dat zelf niet waterdicht.
• 20 oktober. php.net kondigt een beveiligingsupdate aan voor twee kritieke lekken, gepland voor 21 oktober om 16:00 Nederlandse tijd. Dezelfde dag lekken volgens Sansec de details uit, samen met een schermafbeelding van een aanvalstool met de naam PHP2Shell.

Wat PHP2Shell is en waarom het zoveel aandacht krijgt

PHP is de programmeertaal waarmee WordPress elke pagina van je website opbouwt. Op 20 oktober kondigde php.net een belangrijke beveiligingsupdate aan voor twee kritieke lekken. Het PHP-team beoordeelt beide als kritiek, met een score van 9,2 op 10 in CVSS, de schaal waarmee de ernst van lekken wordt gemeten. php.net noemt ze CVE-2026-109618 en CVE-2026-109619. Beveiligingsbedrijven gaven ze de bijnaam PHP2Shell.

php.net bevestigt dat een aanvaller via deze lekken op afstand code kan uitvoeren op de server, zonder in te loggen. Vergelijk het met een bakkerij waar iemand via de bezorgdeur binnenkomt zonder sleutel. Het maakt dan niet uit hoe goed je voordeur op slot zit.

Normaal blijven de details van zo’n lek geheim tot de update er is. Volgens het beveiligingsbedrijf Sansec lekten ze dit keer al op 20 oktober uit, en daarom krijgt het zoveel aandacht.

Bij de release heeft php.net ook uitgelegd waar de twee lekken zitten. Bij het eerste kan PHP bij een geheugentekort halverwege een verzoek worden onderbroken, terwijl de gegevens van dat verzoek nog maar half klaarstaan. Bij het tweede blijven gegevens van een eerder verzoek hangen, en kan een volgend verzoek die gebruiken voordat PHP ze heeft opgeruimd.

Het lek zit onder WordPress, en dat bepaalt wat helpt

Je website bestaat uit lagen. Bovenop staan je pagina’s en je content, daaronder WordPress met je plugins en thema, daaronder PHP en helemaal onderaan de server. PHP2Shell zit in de laag van PHP.

Daarom lost een WordPress-update dit niet op, en een beveiligingsplugin ook niet. Zo’n plugin draait binnen WordPress, terwijl PHP een aanval al verwerkt voordat WordPress start. Om dezelfde reden helpt de onderhoudsmodus van WordPress niet. Cloudflare zegt dat het aanvallen afvangt, ook voor gratis accounts, maar noemt dat zelf niet waterdicht, en het helpt alleen als je server uitsluitend verkeer via Cloudflare accepteert.

Het lek zit in PHP zelf, nog voordat WordPress start. Alleen een bijgewerkte PHP-versie op je server lost het op.

php.net zegt het zelf ook. Alleen een update lost het volledig op. Wil je weten wat er verder op serverniveau al voor je website geregeld kan worden, dan lees je hier hoe WordPress op serverniveau beveiligd is.

Welke PHP-versies een fix krijgen

php.net heeft de update op 21 oktober uitgebracht. De fixversies zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Volgens php.net loopt elke PHP-installatie die webverzoeken afhandelt risico, dus ook de gangbare opstellingen bij hosting.

PHP 8.1 en ouder zijn end of life, dat betekent dat het PHP-project ze niet meer bijwerkt. Voor 7.4, 8.0 en 8.1 heeft het beveiligingsteam alleen minimale bronpatches gemaakt, voor wie PHP zelf bouwt. Sommige Linux-distributies leveren een eigen fix. Voor een gewone website is de oplossing overstappen naar een versie die wel bijgewerkt wordt.

PHP-versie	Status bij php.net	Fixversie	Wat je doet
8.5	ondersteund tot 31 december 2029	8.5.12	laat de update installeren
8.4	ondersteund tot 31 december 2028	8.4.27	laat de update installeren
8.3	ondersteund tot 31 december 2027	8.3.36	laat de update installeren
8.2	beveiligingsupdates tot 31 december 2026	8.2.35	laat de update installeren en plan de overstap naar 8.3 of hoger
8.1	geen ondersteuning meer sinds 31 december 2025	geen, alleen bronpatches voor wie PHP zelf bouwt	overstappen naar 8.3 of hoger
8.0	geen ondersteuning meer sinds 26 november 2023	geen, alleen bronpatches voor wie PHP zelf bouwt	overstappen naar 8.3 of hoger
7.4 en ouder	geen ondersteuning meer	geen, voor 7.4 alleen bronpatches voor wie PHP zelf bouwt	overstappen naar 8.3 of hoger

WordPress raadt zelf PHP 8.3 of hoger aan. Stap je nu over van 8.0 of 8.1, kies dan meteen 8.3 of hoger. Met 8.2 sta je over ruim twee maanden alweer voor dezelfde keuze.

Zo zie je welke PHP-versie je website gebruikt

Log in op je WordPress website en ga naar Tools, dan Sitediagnose, het tabblad Informatie en daar het onderdeel Server. Bij de regel PHP versie zie je op welke versie je website nu draait. Is die verouderd, dan meldt WordPress dat ook op het tabblad Status. Gebruik je WordPress in het Engels, dan heet het Tools, Site Health, Info en Server.

Kom je er niet bij, of heb je geen beheerdersaccount, vraag het dan aan je hostingpartij. Die weet het meteen.

Wat je je hostingpartij vandaag vraagt

Bij de meeste websites regelt de hostingpartij de PHP-update. Je hoeft het dus niet zelf te doen, maar je wilt wel zeker weten dat het vandaag gebeurt. Stuur ze deze vragen, letterlijk zoals ze hier staan.

1. Op welke PHP-versie draait mijn website?
2. Draait mijn website al op PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35, en zo niet, wanneer installeren jullie die?
3. Kunnen jullie mijn website tijdelijk offline halen tot de update staat?
4. Herstarten jullie PHP daarna, zodat de nieuwe versie actief is?
5. Mijn website draait op 8.0 of 8.1, kunnen jullie hem vandaag naar 8.3 of hoger zetten?
6. Maken jullie vooraf een back-up van mijn website?
7. Laten jullie weten wanneer het klaar is?

Stap je over naar een nieuwere PHP-versie, maak dan eerst een back-up en kijk daarna of je website, je formulieren en eventueel je webshop goed werken. Een oude plugin is soms niet compatibel met een nieuwe PHP-versie. Doe je dat liever zelf, dan helpt dit stuk over je WordPress website zelf bijhouden. Wil je het uit handen geven, dan kan dat met WordPress SOS.

Host je zelf, dan regel je dit op je eigen server

Beheer je je eigen server of VPS, dan installeer je PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35. Linux-distributies kregen de patches volgens php.net vooraf, dus kijk bij je distributie of de bijgewerkte pakketten er staan. Werk elke PHP-versie bij die een actieve FPM-pool heeft, de groep PHP-processen die de verzoeken van een website afhandelt, en herstart daarna elke worker. Een worker is zo’n PHP-proces; draait die nog op de oude code, dan ben je niet beschermd. Installeer je PHP uit de repository van Remi, wat veel voorkomt op servers met RHEL, dan krijg je de fix vandaag niet. php.net raadt aan over te stappen op de pakketten van je distributie of PHP zelf te bouwen.

Kun je niet meteen bijwerken? php.net noemt een paar maatregelen die bepaalde aanvalspaden afsluiten, maar zegt er nadrukkelijk bij dat ze een installatie niet veilig maken. Alleen een update is een volledige oplossing. Zet session.upload_progress.enabled op 0 in php.ini, het instellingenbestand van PHP, of in de FPM-pool, en herstart elke worker. Doe dat niet via ini_set() of een .user.ini-bestand, want daar moet je volgens php.net niet op vertrouwen. Volgens php.net blokkeert dit de bevestigde aanvalspaden via sessies, maar niet andere varianten. Voor het lek rond geheugentekort noemt php.net memory_limit op -1 via php_admin_value in de FPM-pool en een lage post_max_size, 8M zonder uploads of 32M met uploads. Volgens Sansec kan met memory_limit op -1 één verzoek al het geheugen van de server gebruiken, dus houd het geheugen in de gaten en zet de limiet terug zodra je hebt bijgewerkt. Zie het als een rem tot de update er staat. Wil je zeker zijn, haal je website dan tijdelijk offline tot je hebt bijgewerkt. Volgens Sansec doe je dat door PHP-FPM te stoppen en je webserver een statische onderhoudspagina te laten tonen.

Hoe ik het vandaag regel voor mijn eigen klanten

Voor de websites die ik host pak ik het vandaag in drie stappen aan. Uit voorzorg hebben we alle servers tijdelijk van internet gehaald, ook al zijn er geen aanwijzingen van misbruik. Zo staat er via de website geen deur open voor een aanval. Websites die nog op PHP 8.0 of 8.1 draaien, zet ik over naar een ondersteunde versie, waar het kan 8.3 of hoger. En zodra de officiële update geïnstalleerd is, loop ik na of elke server de gepatchte versie echt draait en of PHP opnieuw gestart is. Sinds 20:45 zijn de websites weer online.

Wanneer het bij jou geregeld is

Je website is beschermd tegen PHP2Shell zodra je server PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 draait, of hoger, en elke PHP-worker daarna opnieuw gestart is. Een worker is een van de PHP-processen die de verzoeken van je website afhandelen. Die herstart is nodig, want anders draait de oude versie gewoon door. Vraag je hostingpartij dus niet alleen of de update is geïnstalleerd, maar ook of hij actief is.

Daarna is het slim om je website te laten nakijken op dingen die er niet horen, zoals onbekende bestanden of een beheerder die je niet kent. Een update dicht het lek, maar ruimt niets op wat er eventueel al is achtergelaten.

Rust in je hoofd over je WordPress website

Dit soort nieuws komt nooit op een handig moment. Fijn als iemand anders dan zorgt dat je PHP-versie bijgewerkt is, dat de update echt actief is en dat je website daarna goed werkt. Dat doe ik met WordPress SOS, het onderhoud waarbij ik je updates bijhoud en meekijk als er zoiets als PHP2Shell langskomt. Zoek je ook WordPress hosting die zelf patcht, dan regel ik dat op mijn eigen servers.

Veelgestelde vragen

Ben ik veilig als WordPress automatisch updatet?

Voor dit lek helpt dat niet. Automatische updates houden WordPress, je plugins en je thema bij, maar het PHP2Shell lek zit in PHP, de software op de server waar WordPress op draait. Die update regelt je hostingpartij. Vraag dus na of jouw server op PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 draait en of PHP daarna opnieuw gestart is.

Helpt een beveiligingsplugin of firewall tegen PHP2Shell?

Een beveiligingsplugin draait binnen WordPress, en PHP verwerkt een aanval al voordat WordPress start. Een plugin komt daar dus niet aan te pas. Cloudflare zegt dat het aanvallen afvangt, ook voor gratis accounts, maar noemt dat zelf niet waterdicht. Bovendien helpt het alleen als je server uitsluitend verkeer via Cloudflare accepteert. De echte oplossing is een bijgewerkte PHP-versie.

Mijn website draait op PHP 8.1, wat nu?

Dan is het verstandig om vandaag over te stappen. PHP 8.1 en ouder krijgen geen updates meer van het PHP-project, ook niet voor dit lek. Voor 7.4, 8.0 en 8.1 zijn er alleen minimale bronpatches voor wie PHP zelf bouwt, en sommige Linux-distributies leveren een eigen fix. Voor een gewone website is overstappen de oplossing. Kies liefst PHP 8.3 of hoger, de versie die WordPress zelf aanraadt. Maak eerst een back-up en kijk na de overstap of je website goed werkt.

Moet ik mijn website offline halen?

De update van php.net is uit. Weet je niet zeker dat je server al op een van de fixversies draait, haal je website dan tijdelijk offline tot dat zo is. Voor de websites die ik host deed ik dat zelf ook, uit voorzorg, tot de update overal stond. De onderhoudsmodus van WordPress is daarvoor niet genoeg, want volgens Sansec verwerkt PHP het verzoek al voordat WordPress kijkt of die aanstaat. Vraag daarom je hostingpartij om je website tijdelijk onbereikbaar te maken. Draait je server op 8.5.12, 8.4.27, 8.3.36 of 8.2.35 en is PHP opnieuw gestart, dan kan je website weer online.

Hoe weet ik of mijn website al is misbruikt?

Na de update laat je je website controleren op dingen die er niet horen, zoals onbekende bestanden, nieuwe beheerders of plugins die je niet zelf hebt geïnstalleerd. Je hostingpartij of degene die je onderhoud doet kan dat voor je nalopen. Twijfel je, vraag het dan na, want een update ruimt achtergebleven bestanden niet op.