PHP2Shell: het kritieke PHP-lek dat websites wereldwijd (preventief) offline haalde

Belangrijk Draait jouw website op PHP 8.1 of ouder, of op een versie lager dan 8.2.35, 8.3.36, 8.4.27 of 8.5.12? Dan is hij kwetsbaar voor PHP2Shell. Laat PHP vandaag nog bijwerken door je hostingpartij, of neem contact met ons op als je hulp nodig hebt.

Op 21 oktober 2026 bracht PHP noodupdates uit voor vier versies tegelijk. Twee kwetsbaarheden, samen PHP2Shell genoemd, laten een aanvaller zonder inlog code uitvoeren op een webserver. Niet via WordPress of een plugin, maar via PHP zelf: de programmeertaal onder zo’n zeventig procent van het web. In Nederland gingen uit voorzorg zelfs de websites van het NCSC, Overheid.nl, MijnOverheid.nl en DigiD tijdelijk offline.

Er is inmiddels een patch. Sinds 21 oktober, 16:00 uur Nederlandse tijd, zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 beschikbaar, en de eerste hostingpartijen hebben de update al doorgevoerd. De vraag is dus niet meer of er een oplossing is, maar of die al op jouw server staat.

In juli schreven we over wp2shell, het lek in de WordPress-kern. PHP2Shell zit een laag dieper: je WordPress-dashboard kan netjes melden dat alles up-to-date is, terwijl de server eronder nog openstaat.

Wat is PHP2Shell?

PHP2Shell is de naam die onderzoekers van Wiz gaven aan een reeks bugs in hoe PHP omgaat met fatale fouten, zoals een verzoek dat meer geheugen vraagt dan er is. PHP ruimt dan niet alles op, en een volgend verzoek gaat verder met de restanten in het geheugen. Wie dat bewust uitlokt, kan eigen code laten uitvoeren.

De bugs zijn ondergebracht in twee CVE’s, allebei met een score van 9,2 op 10 (CVSS 4.0):

• CVE-2026-109618: een geheugentekort onderbreekt PHP terwijl interne gegevens half zijn opgebouwd, waarna PHP die ongeldige gegevens als geldig behandelt.
• CVE-2026-109619: gegevens van een verzoek blijven bestaan nadat hun geheugen is vrijgegeven, en een volgend verzoek kan ze nog gebruiken.

Samen leveren ze een pre-auth RCE op: code uitvoeren op afstand, zonder in te loggen. Wiz liet zien dat het werkt op de nieuwste versies van WordPress, Drupal en Joomla, en volgens de onderzoekers kan zelfs een kale ‘Hello World’-pagina kwetsbaar zijn.

Daarnaast kunnen aanvallers zonder code-uitvoering stukjes servergeheugen uitlezen, met daarin mogelijk wachtwoorden, tokens en API-sleutels. Een server overnemen is dus niet eens nodig om schade aan te richten.

Tijdlijn van PHP2Shell: van ontdekking tot noodpatch

Van een ontdekking met hulp van AI tot overheden die hun eigen websites offline haalden. Alle tijden zijn Nederlandse tijd.

• 19 augustus 2026 Onderzoekers van Wiz vinden de eerste kwetsbaarheid. Samen met het beveiligingsbedrijf Calif zetten ze daarbij AI in, onder meer technologie van OpenAI.
• 20 en 21 augustus De aanval werkt zonder inlog, eerst op Drupal en een dag later op WordPress.
• 24 augustus Wiz meldt de bugs bij het beveiligingsteam van PHP.
• 21 september PHP bevestigt de meldingen en begint aan een oplossing.
• Enkele dagen voor de bekendmaking Amazon ziet naar eigen zeggen meerdere aanvalspogingen. Hoe de aanvallers van het lek wisten, is niet bekend.
• 20 oktober De CVE-nummers lekken uit via Hacker News en sociale media, twee dagen voor de geplande bekendmaking. PHP kondigt een noodrelease aan voor de volgende middag.
• 21 oktober, 05:02 uur Cloudflare zet beschermingsregels aan voor al zijn klanten, ook op het gratis abonnement.
• 21 oktober Uit voorzorg gaan wereldwijd websites offline. In Nederland onder meer die van het NCSC, Overheid.nl, MijnOverheid.nl en DigiD, internationaal onder meer Wikimedia, de Finse overheid en de BBC.
• 21 oktober, 16:00 uur De patch is uit. PHP brengt 8.5.12, 8.4.27, 8.3.36 en 8.2.35 uit, met minimale patches in de broncode voor 7.4, 8.0 en 8.1. Wiz publiceert de technische details.
• 21 oktober, later op de dag watchTowr ziet de eerste misbruikpogingen in zijn honeypots. Cloudflare ziet aanvallers hun verzoeken aanpassen om de nieuwe regels te omzeilen.
• 21 en 22 oktober Overheden wereldwijd slaan alarm. De Amerikaanse NSA zegt dat wie niet direct kan patchen, systemen offline moet halen. Het Britse NCSC adviseert te controleren op achterdeuren, en ook de EU, Singapore, Australië en de Japanse premier roepen op tot directe actie.

Er zijn wereldwijd aanvalspogingen gezien, maar een geslaagde overname van een website is nog niet publiek bevestigd. Er gaat code rond die zou werken, maar die is niet geverifieerd en bevat volgens Tenable geregeld zelf malware. Duidelijk is wel dat AI de drempel verlaagt: de bugs zaten meer dan tien jaar in PHP en werden pas met AI gevonden, en volgens OpenAI helpt dezelfde technologie aanvallers om sneller aanvallen te bouwen. Bij wp2shell kwamen de eerste aanvallen binnen enkele uren na de patch. Reken er niet op dat het nu trager gaat.

Waarom een WordPress-update je hier niet tegen beschermt

Bij wp2shell zat het lek in WordPress zelf, en dichtten automatische updates het gat bij de meeste websites snel. Bij PHP2Shell werkt dat niet. PHP draait op de server en wordt bijgewerkt door wie die beheert: meestal je hostingpartij, soms een systeembeheerder en soms niemand. Je dashboard toont wel je PHP-versie, maar waarschuwt niet dat die een kritiek lek heeft.

Dat maakt PHP2Shell verraderlijk. Iedereen kan denken dat het geregeld is: de websitebouwer omdat WordPress up-to-date is, de eigenaar omdat er iemand naar de website kijkt, en de hostingpartij omdat de server prima draait.

Welke PHP-versies zijn kwetsbaar?

Kort gezegd: vrijwel allemaal. Volgens Wiz is iedere PHP-versie van de afgelopen tien jaar kwetsbaar voor minstens één van de bugs, terug tot en met PHP 5.4.

• Gerepareerd in: PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, alle vier uitgebracht op 21 oktober 2026. Ook de testversie PHP 8.6.0 RC4 bevat de fix.
• PHP 8.1 en ouder: krijgt geen officiële update meer. Wel zijn er minimale broncode-patches voor 7.4, 8.0 en 8.1, en bieden sommige LTS-leveranciers eigen fixes.
• Elke manier waarop PHP draait: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het PHP-team schat het risico het hoogst in bij mod_php.

Kanttekening: distributies als Debian, Ubuntu en Red Hat verwerken fixes vaak zonder het versienummer op te hogen. Een ouder versienummer kan dus toch veilig zijn. Alleen je hostingpartij of beheerder weet het zeker.

Let daarnaast op de kalender. PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer. Wie nu naar 8.2.35 gaat, staat over een paar maanden opnieuw voor dezelfde keuze.

Wat je nu moet doen

Loop deze stappen langs, ook als je denkt dat het al geregeld is.

1. Zoek uit welke PHP-versie je website gebruikt. In WordPress staat die onder Hulpmiddelen > Sitegezondheid > Info, bij Server.
2. Vraag je hostingpartij of de patch is doorgevoerd. Stel de vraag concreet: draait mijn website op 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of op een pakket waarin de fix is ingebouwd? Een vaag “we houden alles up-to-date” is geen antwoord.
3. Draai je op PHP 8.1 of ouder? Upgrade dan naar een ondersteunde versie, en test dat eerst op een testomgeving: oudere plugins en thema’s werken niet altijd met een nieuwe PHP-versie.
4. Beheer je zelf een server? Installeer de update via je pakketbeheerder of bouw opnieuw vanaf de broncode, en herstart daarna PHP-FPM of Apache. Zolang de oude processen draaien, draait ook de oude code.
5. Gebruik je Cloudflare of een andere WAF? Dat geeft wat lucht, maar is volgens Cloudflare zelf een noodverband. PHP bijwerken blijft nodig.
6. Kijk in je logbestanden. Wiz noemt als signalen: ongebruikelijke uploadverzoeken gevolgd door geheugenfouten of herhaalde 500-fouten, opvallend grote of vreemde PHPSESSID-cookies, en PHP-processen die steeds opnieuw opstarten.
7. Vernieuw je geheimen als je twijfelt. Omdat servergeheugen uitgelezen kan worden, kunnen ook het databasewachtwoord, de sleutels uit wp-config.php en API-sleutels zijn meegelezen. Zie je verdachte signalen, vernieuw ze dan na het patchen.

Kun je niet direct updaten?

Voor serverbeheerders noemt PHP een paar tijdelijke maatregelen. Ze maken een server niet veilig, maar kopen tijd. Zet ze in php.ini of de FPM-pool, niet via ini_set() of .user.ini, en herstart daarna alle PHP-processen:

; Tijdelijke maatregelen, geen vervanging voor de update
session.upload_progress.enabled = 0

; 8M zonder uploads, 32M als de website uploads nodig heeft
; houd upload_max_filesize altijd lager dan post_max_size
post_max_size = 8M

; alleen op PHP 8.5
fatal_error_backtraces = 0

Het NCSC adviseert systemen die nog niet zijn bijgewerkt uit voorzorg offline te houden. De volledige lijst met tijdelijke maatregelen staat in de waarschuwing van PHP, maar ook PHP zelf is duidelijk: alleen updaten is een echte oplossing.

Wat wij bij Webbedrijf hebben gedaan

Voor de websites die wij hosten en beheren, hebben we niet gewacht tot klanten aan de bel trokken. Zo zag dat eruit:

• Dinsdag 20 oktober Na de aankondiging van PHP bereiden we de update van al onze servers voor.
• Dinsdagavond We nemen al preventieve maatregelen: we zetten onder meer PHP-instellingen uit die bij de aanval misbruikt kunnen worden, en houden de servers extra in de gaten.
• Woensdagochtend We informeren zoveel mogelijk klanten en geven ze de keuze om hun website voor de zekerheid tijdelijk offline te halen tot de patch er is.
• Woensdag 21 oktober, 16:00 uur PHP brengt de beveiligde versies uit. We beginnen direct met updaten.
• Woensdagavond tot diep in de nacht Ons team werkt door tot alle servers op een beveiligde PHP-versie draaien, zodat websites zo kort mogelijk kwetsbaar zijn.
• Donderdag 22 oktober We controleren de logbestanden op verdachte verzoeken en sporen van misbruik.

Tijdens het hele traject hebben we de situatie actief gemonitord. Het lek is op al onze servers gedicht. Wordt jouw website door ons gehost, dan hoef je zelf niets te doen: de werkzaamheden vallen onder onze service en je ontvangt er geen extra factuur voor.

Je website is meer dan WordPress

PHP2Shell laat zien dat een website uit lagen bestaat: de server, PHP, WordPress, plugins en thema. In juli zat het lek in de WordPress-kern, nu in de taal eronder. De vraag is steeds: wie merkt het op, wie voert de update door en wie controleert of het gelukt is? Bij veel websites is daar geen sluitend antwoord op.

Met WordPress onderhoud nemen wij die rol op ons: updates in een vast ritme en bij kritieke lekken direct, controle achteraf of ze echt zijn doorgevoerd, dagelijkse back-ups en monitoring op verdacht verkeer. Wil je eerst het bredere plaatje, lees dan waarom je website onderhouden geen kostenpost maar een investering is.

Bronnen

• PHP.net, Security advisory: Critical remote code execution vulnerabilities
• Wiz, PHP2Shell
• Cloudflare, Cloudflare deploys protections against php2shell
• Tenable, php2shell FAQ
• Help Net Security, PHP2Shell: Critical PHP vulnerabilities patched
• BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws
• watchTowr, PHP RCE FAQ
• Tweakers, PHP waarschuwt voor twee ernstige bugs die makkelijk uit te buiten lijken
• BBC, What is PHP and why did it spark a global cyber-security scramble?
• Rijksoverheid, Aantal websites Rijksoverheid preventief offline na kwetsbaarheden PHP
• NCSC, Kwetsbaarheden PHP: patches beschikbaar, update nu