Nou, dat was niet echt hoe ik gedacht had mijn woensdagmiddag (en stukje avond) in de herfstvakantie te besteden. De melding dat er een grote kwetsbaarheid in PHP gevonden was, zorgde ervoor dat ik toch wat langer achter de computer zat dan gewild. Ten eerste om te achterhalen welke van de servers die ik in de lucht heb gebruik maken van PHP, welke daarvan “van buiten” zichtbaar zijn (geldt namelijk niet voor alle) en hoe ernstig of het probleem was.
Zoals wel vaker levert zo’n probleem ook wel weer positieve dingen op. Zo bleken er een aantal websites te zijn die helemaal geen PHP nodig hebben (gebruiken), maar die achter een server hingen die wél PHP ondersteuning aanbood. Is bij deze opgelost. De twee WordPress-websites die ik draai zijn zelf bijgewerkt, nu ook naar de nieuwste PHP-versie waar het probleem waar het vandaag om ging in opgelost is.
In de berichtgeving , o.a. bij nu.nl werd duidelijk gemaakt dat AI het probleem gevonden had, dat het probleem al heel lang in PHP zat en dat het wel vaker voor zou gaan komen. Ik vrees het ook. Gelukkig hebben normale mensen zoals ik tegenwoordig ook de beschikking over AI en dat hielp bij het lokaliseren van de problemen, het inschatten van het risico, maar ook het snel in de lucht brengen van een Docker container die in de tussentijd voor een nette boodschap zorgde, ipv een foutmelding.
En ook daarna, bij het “stappen om te zetten voordat je na het updaten de site weer in de lucht brengt” hielp Claude. Bijvoorbeeld met de commando’s die ik kon uitvoeren om de checken of de sites niet al gehackt waren. Claude gaf de commando’s, ik voerde uit, of stelde vragen als ik het niet begreep.
De uitleg van Claude over het probleem (de links heb ik toegevoegd):
Op 21 oktober 2026 bracht het PHP-team noodpatches uit voor twee kritieke kwetsbaarheden, CVE-2026-109618 en CVE-2026-109619, die al snel de bijnaam php2shell kregen. Beide scoren 9,2 op 10 en maken het mogelijk om zonder in te loggen code uit te voeren op de server. De fout zit in PHP zelf, niet in WordPress, Drupal of een andere applicatie die erop draait. Volgens het officiële advies gaat het mis wanneer PHP tijdens het verwerken van een binnenkomend verzoek door zijn geheugen heen raakt. PHP wordt dan onderbroken terwijl de interne gegevens van dat verzoek maar half zijn opgebouwd, en bij het opruimen worden die ongeldige gegevens behandeld alsof ze kloppen. Met een slim opgebouwd verzoek kan een aanvaller zo het geheugen manipuleren en eigen code laten uitvoeren. Omdat dit gebeurt voordat de applicatie het verzoek te zien krijgt, helpen beveiligingsplugins of een inlogscherm niet. Vrijwel elke PHP-installatie die webverzoeken afhandelt was kwetsbaar, met het grootste risico bij Apache met mod_php, de opzet die onder andere de officiële WordPress-Docker-images gebruiken.
De ernst zat ook in de timing. De patch was een dag vooraf aangekondigd, er circuleerden al geruchten en proof-of-concepts, en experts verwachtten massale aanvallen kort na de release, omdat iedereen vanaf dan uit de patch kan afleiden waar de fout zit. CERT-EU adviseerde daarom kwetsbare websites offline te halen als ze niet direct gepatcht konden worden. Alleen bijwerken naar PHP 8.2.35, 8.3.36, 8.4.27 of 8.5.12 lost het echt op. PHP 8.1 en ouder krijgen geen officiële fix meer. Een update van WordPress zelf verandert niets, want het gaat om de PHP-versie op de server. Wie met Docker werkt, moet dus wachten tot het image waarop de site draait opnieuw is gebouwd met de gepatchte PHP, en dat daarna ook echt binnenhalen.
Voor nu dus een potentiële crisis afgewend. Als het nou afgelopen weekend gebeurd was, toen ik lekker in Zeeland en zonder laptop aan het uitwaaien was, dan waren de servers wat langer offline geweest. Want dit had ik niet op mijn telefoon voor elkaar gekregen vrees ik.
