PHP2Shell: snel patchen vraagt voorbereiding

Het PHP-project bracht op woensdag 21 oktober een noodupdate uit voor twee kritieke lekken, CVE-2026-109618 en CVE-2026-109619, samen PHP2Shell genoemd. Een aanvaller kan daarmee zonder in te loggen code uitvoeren op je webserver. Wij hadden het bij ons dezelfde dag opgelost. Mijn advies is om nu te regelen wat je nodig hebt om de volgende keer ook binnen een dag te patchen, want veel organisaties konden deze week niet zomaar updaten.

Wat er aan de hand was

Op 20 oktober kondigde het securityteam van PHP een release aan voor de volgende dag, om 14:00 UTC. Het ging om twee lekken met allebei een CVSS-score van 9,2. Details volgden pas bij de release. Toch lekten volgens VirusTotal al uren eerder technische details uit, en volgens CERT-EU gaan er proof-of-concepts rond.

De fix zit in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Het PHP-project schrijft dat elke PHP-installatie die webverzoeken afhandelt risico loopt: PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het grootste risico loopt mod_php. Daar werkt een gedemonstreerde aanval met één verzoek zonder inlog, nog voordat je eigen code draait.

Het eerste lek zit in hoe PHP een tekort aan geheugen afhandelt. Het tweede laat gegevens van een eerder verzoek achter, die een volgend verzoek op dezelfde worker nog kan gebruiken. Je eigen code kan dus foutloos zijn en toch ben je kwetsbaar.

Wie er niet snel uit kwam

In Nederland en België gingen op 21 oktober sites offline, meldt The Brussels Times, waaronder MijnOverheid en het Belgische schoolplatform Smartschool. Het Belgische Centrum voor Cybersecurity adviseerde om een site offline te halen als je de update niet meteen kunt installeren. CERT-EU zegt hetzelfde: lukt patchen niet, haal de applicatie dan weg van het openbare netwerk.

Dat zoveel organisaties die stap zetten, verbaast me niet. VirusTotal telde op 21 oktober ongeveer 1,1 miljoen PHP-servers die hun versie laten zien. Ongeveer 758.000 daarvan draaien PHP 5.4 tot en met 8.1. Voor die versies brengt het PHP-project geen update meer uit. Op een ondersteunde versie, 8.2 tot en met 8.5, draaien er ongeveer 272.000.

Wie op PHP 7.4 of 8.1 staat, kan deze week dus niet gewoon updaten. Het securityteam publiceerde voor 7.4, 8.0 en 8.1 alleen kleine patches in de broncode. Die moet je zelf compileren, of je moet een leverancier hebben die het voor je doet.

Er zijn meer redenen waarom het traag gaat. Het PHP-project meldde dat de veelgebruikte repository rpms.remirepo.net op de dag zelf geen updates had. En CERT-EU wijst erop dat ook commerciële en open source producten met PHP erin geraakt kunnen zijn. Die update je niet zelf; daarvoor wacht je op de leverancier.

Wat snel patchen mogelijk maakt

Of je zo'n dag goed doorkomt, bepaal je vooraf. Op de dag zelf kun je alleen nog uitvoeren.

Begin met een lijst van alles waar PHP in draait: je eigen applicaties, de servers en containers eronder, en de pakketten die je erbij hebt gekocht of geïnstalleerd, zoals een webshop, een wiki of een ticketsysteem. Zet bij elk onderdeel de PHP-versie en wie het beheert. Zonder die lijst ben je de eerste uren kwijt aan zoeken.

Draai een ondersteunde versie. PHP 8.2 krijgt na 31 december 2026 geen beveiligingsupdates meer, dus ook dat is nu het moment om te plannen. Hoe je zo'n upgrade elk jaar als vast werk inplant, schreef ik in Laravel in 2026.

Zorg dat een update één vaste route heeft. Bouw je images in een pipeline, dan is een nieuwe PHP-versie een nieuwe build en een deploy. Installeer je met de hand op servers, dan moet iemand op elke server inloggen. Bij het eerste start je een build. Bij het tweede hangt het af van hoeveel servers je hebt en of er iemand tijd heeft, en dan heb je nog niet getest.

Spreek af wie mag besluiten om een site offline te halen, en zorg dat je een onderhoudspagina klaar hebt. Dat besluit wil je niet pas op de dag zelf met vijf mensen nemen.

Een vast updateritme helpt ook bij lekken zonder aankondiging. Aleksa schreef vorige week over patchen zonder op de CVE te wachten. Daar was een lek al een maand misbruikt voordat de CVE verscheen.

Wat je nu nog moet doen

Kijk op elke server en in elke container welke PHP-versie draait. Staat er geen 8.5.12, 8.4.27, 8.3.36 of 8.2.35 (of een gepatcht pakket van je distributie), update dan. Linux-distributies en leveranciers met langere ondersteuning kregen de patches vooraf, dus kijk eerst bij hen.

Kun je niet meteen updaten, gebruik dan de tijdelijke maatregelen uit de advisory van het PHP-project, zoals session.upload_progress.enabled=0 in php.ini en een herstart van alle workers. Het PHP-project is duidelijk: die maatregelen verkleinen het risico, maar je installatie is daarmee niet veilig. Mijn advies is om in dat geval de site offline te halen tot de update erop staat.

Vraag de leveranciers van je pakketten met PHP erin of ze een update hebben en wanneer. En staat er nog een applicatie op PHP 7.4 of 8.1, zet de upgrade dan bovenaan de planning. Hoe je zo'n oudere applicatie aan een nieuw team overdraagt, staat in legacy code overdragen aan een nieuw team.

Bronnen

• PHP: Security Advisory en release-aankondigingen, 20 en 21 oktober 2026
• PHP: advisory GHSA-w8hw-w9fx-j79w, RCE via OOM corruption (CVE-2026-109618)
• PHP: advisory GHSA-6wmf-4rv5-p3rp, RCE via stale global state (CVE-2026-109619)
• CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP
• VirusTotal: Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619
• The Brussels Times: Major websites go offline as critical PHP vulnerability triggers security fears