,
,
,
Context – 21 oktober 2026: Voor CVE-2026-109618 en CVE-2026-109619 zijn beveiligingspatches uitgebracht. Alle betrokken PHP-omgevingen onder ons beheer zijn inmiddels gepatcht. We hebben ook gecontroleerd welke PHP-installaties daadwerkelijk worden gebruikt en of actieve processen met de gerepareerde code werken. Dat laatste is van belang wanneer meerdere PHP-versies naast elkaar draaien, of wanneer een oudere versie de reparatie via een leverancierspatch (backport) ontvangt.
Een website kan volledig bijgewerkt zijn en toch kwetsbaar blijven. Als de fout in PHP zelf zit, helpt het niet om alleen het CMS of de plug-ins bij te werken. Op 21 oktober 2026 werden twee ernstige kwetsbaarheden in PHP bekendgemaakt. Verschillende organisaties haalden websites uit voorzorg offline, terwijl beheerders en leveranciers met de patches aan de slag gingen.
Wij moesten vooral weten welke gevolgen dit had voor onze eigen systemen. Via ASK-Solutions, de werknaam van Stichting IRADIS, beheren we webomgevingen voor onze activiteiten en voor initiatieven die we technisch ondersteunen. Daar horen verschillende toepassingen en PHP-versies bij. Bij een beveiligingsmelding als deze moet je dus verder kijken dan de PHP-versie die standaard op de server staat.
PHP verwerkt aan de serverkant verzoeken van websites en applicaties. Het genereert pagina's, handelt bijvoorbeeld formulieren af en voert de code uit waarop een CMS of maatwerkwebsite draait. Een fout op dat niveau kan gevolgen hebben voor toepassingen die verder prima onderhouden zijn.
De twee kwetsbaarheden zijn CVE-2026-109618 en CVE-2026-109619. Bij de eerste kan er iets misgaan wanneer PHP onvoldoende geheugen overhoudt. Bij de tweede kan interne toestand van een eerder verzoek onder bepaalde omstandigheden achterblijven nadat het geheugen waarop die toestand berustte al is vrijgegeven. Beide fouten kunnen leiden tot misbruik van ongeldige geheugentoestanden.
De precieze risico's hangen af van de configuratie. In de beveiligingsmelding van PHP wordt Apache met mod_php genoemd als een configuratie waarin het op afstand uitvoeren van code zonder inloggen is aangetoond, nog voordat de eigenlijke applicatiecode draait. Dat maakt de problemen ernstig. Het betekent niet dat iedere PHP-installatie langs exact dezelfde weg kan worden aangevallen, maar de betrokken webgerichte installaties moeten wel worden gepatcht.
Op onze systemen draait niet noodzakelijk overal dezelfde PHP-reeks. Een toepassing kan al met een recente versie werken, terwijl een andere nog afhankelijk is van een oudere. Ook kunnen er meerdere PHP-installaties op één server aanwezig zijn. Alleen het standaardpakket bijwerken zou daarom onvoldoende zijn geweest.
We hebben de relevante installaties nagelopen, vastgesteld welke reparaties beschikbaar waren en de benodigde patches voor beide kwetsbaarheden toegepast. Vervolgens is ook gekeken naar de PHP-processen die daadwerkelijk actief waren. Een geïnstalleerde update is immers pas nuttig voor een lopende dienst zodra die dienst de bijgewerkte code gebruikt. Vooral bij langlopende workers is dat een punt om niet over te slaan.
Die controle is afgerond: de betrokken PHP-omgevingen die wij beheren, zijn gepatcht. Dat is de concrete status van dit incident binnen onze infrastructuur.
Op 21 oktober verschenen vanuit het PHP-project de gerepareerde versies 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Voor oudere reeksen worden niet meer op dezelfde manier reguliere releases gepubliceerd. Toch kan een oudere versie nog beveiligingsreparaties ontvangen via een Linux-distributie of een leverancier die langdurige ondersteuning biedt.
Zo hebben we bij een van onze PHP 8.1-installaties vastgesteld dat beide fixes al in een leverancierspatch waren verwerkt. PHP blijft zich daar als versie 8.1 identificeren. Aan dat versienummer alleen kun je dus niet zien of de betreffende kwetsbaarheden nog aanwezig zijn. Daarvoor moet je de herkomst en patchstatus van het geïnstalleerde pakket controleren.
Dat werkt ook andersom: de aanwezigheid van een nieuwe versie op de schijf zegt nog niet welke runtime door de website wordt gebruikt. Bij parallelle installaties, PHP-workers en oudere applicaties zijn dat twee verschillende vragen. Tijdelijke aanpassingen aan de configuratie vervangen de beveiligingspatches bovendien niet.
Bij dit soort onderhoud lopen drie controles door elkaar: welke PHP-versies zijn geïnstalleerd, bevatten hun pakketten de reparaties voor beide CVE's, en welke code gebruiken de actieve processen? De antwoorden hoeven niet vanzelf samen te vallen.
Dat is ook de reden waarom een website tijdelijk offline halen soms een verstandige voorzorgsmaatregel is. Het beperkt de blootstelling wanneer een kwetsbare dienst nog niet bijgewerkt kan worden. Het zegt op zichzelf niets over een eventuele inbraak. En andersom bewijst het installeren van een patch niet of een kwetsbaarheid vóór dat moment misbruikt is. Daarvoor is afzonderlijk onderzoek nodig.
Voor onze betrokken PHP-installaties zijn de reparaties toegepast en de actieve omgevingen gecontroleerd. Een CMS-update is iets anders: die kan nog steeds nodig zijn voor eigen kwetsbaarheden in het CMS of zijn uitbreidingen, maar lost een fout in PHP zelf niet op.
De ontdekking kreeg extra aandacht omdat AI-hulpmiddelen onderdeel waren van het beveiligingsonderzoek. OpenAI beschrijft hoe onderzoekers van Calif en Wiz met de PHP-onderhouders en andere betrokkenen samenwerkten aan analyse en herstel vóór de openbaarmaking. Het PHP-project verzorgde de ontwikkeling en publicatie van de patches.
Het interessante zit voor ons niet alleen in de manier waarop de fouten werden gevonden. Iemand moet de kwetsbaarheid reproduceren, de reparatie beoordelen en testen, pakketten beschikbaar maken en ze uiteindelijk op de juiste systemen toepassen. Bij open source kunnen verschillende partijen daaraan bijdragen. Juist daardoor kan het herstel breed beschikbaar komen, ook voor software die al jaren wordt gebruikt.
Als een website een nieuw ontwerp krijgt, ziet iedereen het. Van een bijgewerkte PHP-runtime merken bezoekers doorgaans niets. Dat is precies de bedoeling, maar het betekent niet dat er weinig werk achter zit.
Voor de webomgevingen die wij beheren hoort dit soort onderhoud bij het dagelijkse technische werk. Niet iedere toepassing kan zomaar naar een andere PHP-reeks. Soms is een leverancierspatch voor een oudere versie de passende oplossing; soms moet een dienst opnieuw worden gestart of moeten we nagaan welke installatie achter een website zit. De situatie van de betreffende omgeving is daarbij belangrijker dan alleen het versienummer.
De twee PHP-kwetsbaarheden van 21 oktober zijn voor onze betrokken omgevingen verholpen. Daarmee is deze patchronde afgesloten. Het gewone onderhoud gaat verder, ook als daar aan de buitenkant niets van te zien is.
Copyright © 2026, ASK-Solutions
