php2shell: hoe snel de hosters het kritieke PHP-lek hebben gedicht

Op 20 oktober kondigde het PHP-project voor de volgende dag een kritiek beveiligingsrelease aan, om 14:00 UTC. Op 21 oktober om 16:00 uur Duitse tijd stonden PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 klaar. Wat daarna gebeurt, ligt bij de meeste website-eigenaren niet meer in eigen hand: wie shared hosting of managed WordPress gebruikt, blijft kwetsbaar tot de hoster de update op zijn servers zet.

We beheren een aantal websites en toepassingen bij verschillende hosters, eigen projecten en die van klanten. Voor 27 daarvan hebben we die avond bijgehouden wanneer de nieuwe versie aankwam. Het resultaat is geen hostertest, maar wel een eerlijk beeld van hoe verschillend het tempo is.

Wat php2shell is

Volgens het beveiligingsbericht van het PHP-project zitten achter de naam twee fouten in de omgang met geheugen tussen twee verzoeken. Bij CVE-2026-109618 kan een afbreking wegens geheugentekort gegevens in een half afgewerkte toestand achterlaten, die PHP bij het opruimen voor geldig houdt. Bij CVE-2026-109619 blijft de interne toestand van een verzoek achter nadat het geheugen ervan al is vrijgegeven, en het volgende verzoek in hetzelfde proces gebruikt die toestand. Beide hebben CVSS 9.2 en maken het in het ergste geval mogelijk eigen code op de server uit te voeren.

Getroffen is elke PHP-installatie die webverzoeken afhandelt: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het risico is het hoogst bij mod_php. De aanvaller heeft geen account nodig, en de aanval werkt al voordat WordPress of een plugin ook maar code uitvoert. Een beveiligingsplugin merkt er dus niets van.

Hoe ver aanvallen al lopen, schatten de bronnen verschillend in. Het Canadese Cyber Centre meldde op 21 en 23 oktober een openbare proof of concept, maar nog geen vastgestelde uitbuiting (waarschuwing AL26-026). Volgens Help Net Security zag Amazon al op 17 oktober een poging tot uitbuiting, vier dagen voor de publicatie.

Onze meting: 27 systemen, zeven hosters en een eigen server

We hebben van buitenaf gemeten en alleen lezend. De meeste hosters noemen de PHP-versie in de responsheader X-Powered-By. Die hebben we bij Hostinger en STRATO elke vijf minuten opgevraagd, en wel op wp-login.php, omdat die pagina nooit uit de cache komt en PHP daar zeker draait. Bij Raidboxes stond de versie in het systeemrapport van WooCommerce. All-Inkl verbergt de responsheader. Daar toonde een controlebestand van één regel de versie, en dat is daarna meteen weer verwijderd. Bij united-domains en CheckDomain was de versie van buitenaf niet af te lezen.

Twee kanttekeningen horen erbij. We hebben onze eigen accounts gemeten, geen steekproef over alle servers van een hoster. Grote hosters rollen updates vaak server voor server uit, andere klanten kunnen eerder of later aan de beurt zijn geweest. En tussen 22 en 26 oktober hebben we bij Hostinger niet gemeten, dus wanneer precies 8.3.36 kwam, weten we niet.

Wat we eruit meenemen

Het verschil is groot, en je ziet het niet

Tussen de snelste en de langzaamste hoster in onze meting zitten minstens 13 uur, een hele nacht. Van buitenaf zie je een website niet aan of de server al gepatcht is. Wie zelf niet kijkt, weet het niet.

Een eigen server is zo snel als zijn langzaamste stap

Op onze eigen server draait een applicatie in Docker, gebouwd op het officiële PHP-image. Het image met nummer 8.4.27 verscheen om 17:45 uur, de versie voor gewone Intel- en AMD-servers pas om 18:47 uur. Onze herbouw liep om 18:51 uur. Om te zorgen dat die het nieuwe basisimage haalde en niet het oude uit de cache pakte, moesten we de bouwinstructie aanpassen. Sindsdien haalt elke build het actuele image.

Coolify, het platform waarmee we deze server beheren, bracht zijn update met de gepatchte PHP-versie al twaalf minuten na de release uit. Bij ons kwam die toch pas aan met de nachtelijke automatische update. Snelle fabrikanten helpen weinig als de update op jouw systeem blijft liggen.

Oude PHP-takken krijgen niets meer

Een systeem draaide nog op PHP 8.1. Voor 8.1 en ouder maakt het PHP-project geen releases meer, er zijn alleen minimale correcties in de broncode voor wie PHP zelf compileert. Op shared hosting helpt daar alleen overstappen naar een ondersteunde tak. Een ander systeem stond al vóór het beveiligingsrelease vijf releases achter, op 8.2.29 in plaats van 8.2.34. Het goede nieuws: het beveiligingsrelease heeft het meegetrokken, bij de nameting draaide het op 8.2.35.

Zonder PHP geen PHP-lek

Onze hoofdsite hafenstudios.com was niet getroffen, omdat ze uit statische HTML-bestanden bestaat. Voor een WordPress-site is dat geen optie, maar het laat zien waarom onderdelen die geen PHP nodig hebben, ook geen PHP moeten uitvoeren.

Zo controleer je je PHP-versie in WordPress

1. In het dashboard: Tools, Sitediagnose, tabblad Informatie, en klap daarna de sectie Server open. Daar staat de PHP-versie waarmee WordPress nu draait.
2. Vergelijk met de tabel: Je tak is gepatcht vanaf het nummer in de kolom “Gepatcht vanaf”.
3. Toevoegingen goed lezen: Achter het nummer kan een afkorting van de hoster staan, bijvoorbeeld 8.3.36-nmm1. Bepalend is het nummer ervoor.

Een uitzondering: sommige Linux-distributies en hosters verwerken de correctie in hun eigen build zonder het nummer te veranderen. Staat er bij jou een ouder nummer en zegt je hoster dat hij heeft gepatcht, dan is dat geen tegenspraak. Dan geldt zijn schriftelijke bevestiging.

Wie veel sites beheert, kan vanaf WordPress 6.9 ook via de REST-API nakijken, met een applicatiewachtwoord en alleen lezend: /wp-json/wp-abilities/v1/abilities/core/get-environment-info/run geeft onder meer de PHP-versie terug.

Als je hoster nog niet heeft gepatcht

• Navragen. Eén korte zin aan de support volstaat: wanneer komt PHP 8.x.y met de correctie voor CVE-2026-109618 en CVE-2026-109619? Het antwoord laat ook zien hoe serieus je hoster dit neemt.
• De tak wisselen. Veel hosters bieden meerdere PHP-versies ter keuze aan. Wordt een andere tak al gepatcht aangeboden, dan kun je na een korte test daarheen overstappen. Eerst een back-up, daarna startpagina, login en formulieren doorklikken.
• Een firewall als overbrugging. Cloudflare heeft regels uitgerold tegen bekende aanvalsroutes, ook in het gratis abonnement. Het PHP-project schrijft echter duidelijk dat er geen volledige oplossing is. De firewall vervangt de update niet.
• Bij eigen servers: pakketten bijwerken, containers met een vers basisimage opnieuw bouwen en daarna alle PHP-processen herstarten. De instellingen waarmee het PHP-project de tijd tot de update laat overbruggen, staan in het beveiligingsbericht.

Op 23 oktober volgde een aanvulling: een derde kwetsbaarheid, CVE-2026-115560, zit in de voortgangsweergave voor uploads in sessies. Ze werkt alleen als een applicatie het opslagformaat van haar PHP-sessies tijdens de uitvoering omzet. WordPress zelf gebruikt geen PHP-sessies, in aanmerking komen hooguit plugins die dat wel doen. De correctie komt met het volgende reguliere release, tot dan raadt het PHP-project session.upload_progress.enabled=0 aan. Op shared hosting kan alleen de hoster dat instellen.

En als je toch al aan het opruimen bent: PHP-updates zijn maar de ene helft. Waarom verouderde plugins het grotere blijvende probleem zijn, staat in ons artikel over het bijwerken van WordPress-plugins. Hoe oud de minimumeisen in de plugindirectory deels nog zijn, laat onze analyse zien: 8.131 plugins noemen nog PHP 5 (in het Engels).

Veelgestelde vragen