PHP-FPM

Samenvatting: de techniek achter onze aanpak van CVE-2026-109618 en -109619

Beide lekken zitten in de PHP-engine, nog vóór de code van een site draait. Hoe groot het risico is, hangt af van de SAPI: mod_php was het bevestigde doelwit, PHP-FPM en LiteSpeed draaien PHP in aparte processen. Wij zetten session.upload_progress uit op elke PHP-build, maten na dat ook de draaiende processen de instelling gebruikten, lieten Imunify360 het aanvalspatroon blokkeren en installeerden de vendor-builds zodra ze verschenen. Omdat het versienummer na de fix vaak gelijk blijft, controleerden we elke binary op de symbolen die de fix meebrengt.

Zo controleer je je eigen build

Dit is het technische vervolg op onze terugblik op het PHP-lek van 21 oktober. Daar lees je wat we deden en waarom we online bleven. Hier gaan we de diepte in: wat er in de engine misgaat, waarom de SAPI uitmaakt, welke configuratie we op welke stack zetten, hoe de vendor-builds binnenkwamen en hoe je zelf controleert of een binary de fix bevat. Beheer je zelf PHP-servers, dan is dit voor jou.

Sommige hosters kozen ervoor om hun servers tot de update offline te halen. Wij hebben die afweging ook gemaakt, en kwamen op een andere uitkomst. Dat had drie redenen.

PHP draait bij ons apart van de webserver

Het grootste risico zat bij servers waar PHP als module ín de webserver Apache draait, mod_php genoemd. Dat schreef CloudLinux^[2], en de aanvalstool die rondging werkte volgens de maker ook alleen in die opstelling. Bij ons draait PHP vrijwel overal als aparte processen: via PHP-FPM op onze VPS'en en DirectAdmin-servers, en via LiteSpeed op onze shared hosting met CloudLinux.

Een latere technische analyse van beveiligingsonderzoeker Daniele Berardinelli laat zien waarom dat uitmaakt^[3]. Bij mod_php kan een aanvaller de beschadigde toestand van PHP in hetzelfde verzoek misbruiken. PHP-FPM sluit het proces bij die fout juist af. Voor PHP-FPM beschrijft hij één bevestigde aanvalsroute, en die loopt via session.upload_progress. Dat is precies het onderdeel dat wij die ochtend al hadden uitgezet.

Veelgestelde vragen

Waarom halen jullie niet alle websites offline, zoals sommige andere hosters?

Omdat het risico bij ons anders ligt. De aanvalstool die nu rondgaat, werkt volgens de maker zelf alleen als PHP op een oudere manier ín de webserver draait. Bij ons draait PHP vrijwel overal apart van de webserver, via PHP-FPM of LiteSpeed, en daar werkt die tool volgens hem niet. Dat betekent niet dat het lek daar niet bestaat, maar wel dat de aanval die nu bekend is er niet werkt.

Daarnaast is je website op onze shared hosting op drie manieren beschermd. De tijdelijke maatregel is actief, en we hebben nagemeten dat hij in de draaiende PHP-processen werkt. De firewall van Imunify360 bevat een regel tegen het aanvalspatroon. En CloudLinux schermt elk account af van de andere. Alles offline halen zou duizenden websites onbereikbaar maken, voor een risico dat bij ons klein is. Inmiddels is de officiële update geïnstalleerd. Hoe we die afweging maakten, lees je in onze terugblik: waarom we geen websites offline haalden.