php2shell: hoe we PHP beschermden voordat de patch bestond

Beveiliging | Bijgewerkt: oktober 2026

Sommige kwetsbaarheden geven u weken de tijd. Bij php2shell hadden we één ochtend. Op 21 oktober 2026 lekten de technische details van twee kritieke PHP-kwetsbaarheden, uren voordat PHP zelf met een noodrelease kwam. Beide waren bereikbaar met één speciaal samengesteld uploadverzoek, nog voordat er applicatiecode wordt uitgevoerd: geen login, geen kwetsbare plugin, geen waarschuwing.

We hebben niet op de patch gewacht. Voordat PHP de oplossing publiceerde, draaide er op de PHP-servers van ons managed platform al een extensie die we diezelfde ochtend hadden gebouwd. We maakten de extensie die dag open source. Twee dagen later gebruiken beheerders van China tot Rusland de extensie om servers te beschermen waarvoor geen andere oplossing beschikbaar is.

De korte versie: php2shell (CVE-2026-109618 en CVE-2026-109619) treft PHP terwijl het een binnenkomend verzoek leest. Onze extensie, php_uploadprogress_guard, voegt de officiële oplossing toe aan een niet-gepatchte PHP-versie, zonder PHP opnieuw te bouwen, voor elke versie van PHP 5.4 tot 8.5. Sindsdien dekt de extensie ook twee nieuwere problemen waarvoor PHP zelf nog geen oplossingen heeft uitgebracht. Klanten van Hosted Power hoefden niets te doen. Alle anderen kunnen de extensie gratis gebruiken.

In dit artikel

1. Waarom php2shell anders was
2. Wat we in de eerste uren deden
3. Opnieuw opgebouwd rond de officiële oplossing
4. Wereldwijd opgepikt
5. De tweede golf
6. Wat specifiek is voor Hosted Power
7. Waar de extensie niet meer helpt

Waarom php2shell anders was

De meeste kwetsbaarheden in websites zitten in een applicatie: een plugin, een thema of een vergeten beheerpagina. U werkt de applicatie bij of plaatst er een firewallregel voor. php2shell was om twee redenen anders.

De kwetsbaarheid zit in PHP zelf, voordat uw applicatie wordt uitgevoerd. De kwetsbare code zit in de manier waarop PHP een binnenkomend verzoek leest en opruimt. WordPress, Magento, Shopware, Laravel of uw eigen code krijgen nooit de kans om het verzoek te weigeren. Voor een firewall ziet het eruit als een gewone upload.

De kwetsbaarheid treft bijna elke PHP-versie die in gebruik is. PHP 8.2 tot 8.5 kreeg een officiële oplossing. Voor PHP 8.1 en ouder, die nog op een groot deel van de servers wereldwijd draaien, was er niets om te installeren. Onafhankelijke monitoring die sindsdien is gepubliceerd, wijst erop dat ongeveer een derde van de PHP-servers versies draait die geen updates meer ontvangen.

Alles bij elkaar betekende dit dat een groot deel van het internet een kwetsbaarheid had die op afstand kon worden misbruikt, zonder een eenvoudige manier om die te verhelpen.

Wat we in de eerste uren deden

Toen de details uitlekten, volgden onze engineers de kwetsbare code in de PHP-broncode van elke branch van 5.6 tot 8.5 en bouwden ze de kleinst mogelijke oplossing die we konden verantwoorden: een kleine PHP-extensie die de getroffen session upload-progress-handler uitschakelt zodra PHP start. In tegenstelling tot de veel gedeelde php.ini-workaround kan de eigen .user.ini of .htaccess van een website de handler niet opnieuw inschakelen.

We rolden de extensie uit op ons managed platform, inclusief servers met cPanel en DirectAdmin, voordat PHP de officiële release uitbracht. Voor klanten was een korte herstart van PHP het enige zichtbare effect. Uploads, formulieren en sessies bleven werken en niemand hoefde een site offline te halen.

Daarna zetten we de extensie op GitHub, omdat de servers die deze het hardst nodig hadden niet van ons waren.

Opnieuw opgebouwd rond de officiële oplossing

Toen PHP de beveiligingsadviezen publiceerde, bleek het probleem breder dan die ochtend duidelijk was: de upload-progress-handler was één mogelijke route, maar niet de enige. Daarom bouwden we de extensie opnieuw op rond de officiële oplossing, onderdeel voor onderdeel.

Versie 3 bevat PHP's eigen aangepaste uploadparser met een geheugenbeveiliging, houdt de upload-progress-handler uitgeschakeld en weerspiegelt de rest van de officiële oplossing. Zo kan de status van een verzoek niet langer uitlekken naar het volgende verzoek. De extensie herkent PHP waarin de oplossing al is opgenomen, ook wanneer Linux-distributies updates hebben teruggeporteerd, en schakelt zichzelf dan uit.

De extensie werkt op elke PHP-versie van 5.4 tot 8.5, op Linux (x86_64 en ARM) en op Windows, zonder PHP opnieuw te bouwen. Dat laatste is belangrijk: de meeste beheerders van oudere systemen kunnen PHP niet opnieuw compileren, maar bijna iedereen kan een extensie laden.

Ondertussen installeerden we de officiële updates van PHP op ons platform zodra ze beschikbaar waren. De extensie bleef als extra beveiligingslaag actief.

Wereldwijd opgepikt

We publiceerden de extensie om onze eigen klanten te beschermen en anderen in dezelfde situatie te helpen. We hadden niet verwacht wat er daarna gebeurde.

• Beheerders van China tot Chili meldden problemen, stuurden verbeteringen in en vroegen om builds voor ARM-servers en Windows. We bouwden die nog diezelfde nacht.
• De Russische hostingprovider NetAngels verpakte de extensie voor de servers van zijn eigen klanten.
• De onafhankelijke CVE-database Defensia vermeldt de extensie als tijdelijke oplossing voor PHP-versies die geen updates meer ontvangen.
• Het Franse hostingbedrijf Gladhost levert de extensie als kant-en-klare pakketten voor Rocky Linux 8.
• Windows-builds gaan nu terug tot PHP 5.4, voor een bedrijf dat deze versie nog steeds in productie draait op Windows Server 2012 R2.
• De auteur van een concurrerende extensie stapte op zijn eigen servers over op die van ons.
• De pers besteedde er aandacht aan: Cybernews, Dutch IT Channel, IT-Connect en Born's Tech and Windows World schreven erover.

Meer dan 130 ontwikkelaars gaven het project binnen drie dagen een ster op GitHub. Voor een kleine extensie die in één ochtend is geschreven, getuigt dat van veel vertrouwen. Dat nemen we serieus.

De tweede golf

Een dag na de noodupdate van PHP kwamen twee nieuwe problemen aan het licht. PHP heeft voor geen van beide al een oplossing uitgebracht.

Een geheugenbug in unserialize(), in elke PHP-versie. Wanneer unserialize() opruimt, kan de functie geheugen vrijgeven dat een actief object nog gebruikt. Dit is de bug achter de koppen dat "de patch van PHP onvolledig is". Het probleem is minder breed aan te vallen dan php2shell, maar treft ook gepatchte PHP. (php-src#24481)

Een crash die door de beveiligingsupdate zelf is veroorzaakt. In PHP 8.4.27 en 8.5.12 kan SimpleXML hetzelfde geheugen twee keer vrijgeven. Dit eindigt in zend_mm_heap corrupted en een gecrashte PHP-worker. De oplossing is opgenomen in de PHP-broncode, maar zit nog niet in een release. (php-src#24488)

Versie 3.2 van onze extensie dekt beide problemen, zowel in gepatchte als niet-gepatchte PHP, en we rollen de extensie uit op ons platform. Daarom is ons advies veranderd: werk PHP bij en laat de extensie geïnstalleerd totdat PHP deze oplossingen zelf uitbrengt.

Een derde advies, al afgedekt. Op 23 oktober publiceerde PHP een informatief advies voor CVE-2026-115560 en raadde het aan om session upload progress uit te schakelen tot de volgende reguliere release. Het scenario is onwaarschijnlijk, maar de risicobeperkende maatregel is precies wat onze extensie sinds de allereerste versie op 21 oktober doet: de extensie schakelt de upload-progress-handler uit en vergrendelt de instelling, zodat geen enkele applicatie of .user.ini deze opnieuw kan inschakelen. Elke server met de extensie was al beschermd voordat het advies bestond. (php.net advisory)

Weet u niet zeker hoe uw servers ervoor staan?

Welke PHP-versies waar draaien, welke zijn gepatcht en welke nog niet kunnen worden bijgewerkt: dat is vaak lastiger te achterhalen dan het klinkt, vooral als er oudere applicaties of control panels in het spel zijn.

Vraag een infrastructuuraudit aan

Wat specifiek is voor Hosted Power

De extensie is open source en iedereen kan deze gebruiken. Voor onze klanten maakte alles eromheen het verschil.

We hadden engineers die onder tijdsdruk de interne werking van PHP konden doorgronden. In één ochtend een kwetsbaarheid traceren door elke PHP-branch van 5.6 tot 8.5 is niet iets wat u zomaar doet.

We konden de oplossing overal tegelijk uitrollen. TurboStack beheert elke PHP-versie op elke server op dezelfde manier. Daardoor was een oplossing die 's ochtends was geschreven diezelfde dag actief op het hele platform. Monitoring liet ons zien of deze daadwerkelijk was geladen.

We hadden beveiligingslagen vóór PHP. Terwijl de extensie het kwetsbare codepad afsloot, beperkte TurboShield het aantal uploadverzoeken en blokkeerde de extensie automatisch de bronnen van verdachte pogingen.

We wisten welke klanten wat nodig hadden. Oudere PHP-versies, maatwerkbuilds, control panels: we wisten waar elke versie draaide. Daardoor hoefde niemand zijn site offline te halen.

Waar de extensie niet meer helpt

Er zijn duidelijke grenzen. We benoemen die liever expliciet.

Het is een tijdelijke oplossing, geen vervanging voor het bijwerken van PHP. De officiële update blijft de echte oplossing. De extensie is een overbrugging voor servers die nog geen update kunnen krijgen.

De extensie neemt de bekende oplossingen over, maar voorspelt de volgende niet. De extensie dekt de gepubliceerde kwetsbaarheden en de twee vervolgproblemen. Als er iets nieuws wordt gevonden, komen we zo snel mogelijk in actie.

De extensie is niet op elke configuratie getest. We testen elke PHP-branch op PHP-FPM, Apache mod_php en CGI. Andere configuraties, zoals LiteSpeed, vallen nog niet binnen onze tests. Controleer dus of de extensie wordt geladen voordat u erop vertrouwt.

Dat laatste punt staat centraal in onze werkwijze. We vertellen u liever precies wat we hebben getest dan dat we bescherming beloven die we niet hebben geverifieerd.

Open source, omdat we het internet delen

We bouwden de extensie voor onze eigen klanten en zij waren als eerste beschermd. Maar een kwetsbaarheid als php2shell houdt niet op bij onze servers: elke niet-gepatchte PHP-server op internet is een mogelijk startpunt voor de volgende aanval. De oplossing delen was vanzelfsprekend.

Voor onze klanten is het resultaat eenvoudig: bescherming voordat de patch beschikbaar was, de officiële update zodra die uitkomt en niets wat zij zelf hoeven te doen.

Als u PHP draait dat u nog niet kunt bijwerken, vraag ons uw infrastructuur te beoordelen. We vertellen u hoe u ervoor staat en wat de veiligste aanpak is: bijwerken, tijdelijk overbruggen of migreren.