CageFS

Voor beide CVE's geldt dat de staat met de worker sterft: "When a worker dies, the stale state dies with it." Keep-alive helpt een aanvaller alleen als de frontend de verbinding aan dezelfde worker koppelt, en dat is geen garantie.

Op onze shared hosting (cl01 tot en met cl09) draait PHP als lsphp onder LiteSpeed Enterprise 6.3.7 of onder Apache met mod_lsapi, binnen CloudLinux CageFS. Op onze VPS'en en DirectAdmin-servers draait Apache met PHP-FPM. mod_php gebruiken we vrijwel nergens. Daarmee viel het bevestigde aanvalspad voor het overgrote deel van onze servers af, en was de FPM-route via upload progress het pad om dicht te zetten.

Laag 1: session.upload_progress uit, per stack

Het advies tot de patch was session.upload_progress.enabled = 0, toegepast vóór het parsen van requests, en daarna elke worker herstarten^[1][2]. Dat blokkeert de bevestigde routes van CVE-2026-109619, niet de geheugenroute van CVE-2026-109618. Op onze servers draaien PHP-versies van 5.2 tot en met 8.5 naast elkaar, verdeeld over drie configuratiemodellen.

Tussen 08:30 en 10:00 uur zetten we session.upload_progress uit op al onze servers. Daarna hebben we per server gecontroleerd dat de instelling ook werkt in de PHP-processen die bezoekers bedienen, en niet alleen in een configuratiebestand. Hoe dat zit, lees je hieronder bij het configuratieverhaal.

Imunify360 en CloudLinux als extra lagen

Op het grootste deel van onze shared hosting draait Imunify360. Die firewall kreeg op 21 oktober al in de ochtend een regel tegen het aanvalspatroon. Om 20:00 uur volgden nieuwe regels (versie 8.85), die ook de publieke aanvalstool, varianten daarvan en verdachte uploads blokkeren^[2]. Op servers waar Imunify360 nog ontbrak, hebben we het die ochtend geïnstalleerd. Daarnaast draait elk account op onze shared hosting in een eigen afgeschermde omgeving, CloudLinux CageFS. Een aanval op de ene website komt daardoor niet zomaar bij een andere.

Onze servers offline halen zou duizenden websites, webwinkels en formulieren urenlang onbereikbaar maken, voor een risico dat met deze lagen klein was. Voor klanten met gevoelige gegevens hebben we wel het advies van CERT-EU gedeeld: weeg zelf af of je je site tot de update afschermt^[4]. Dat advies volgden we zelf ook. Ons eigen klantsysteem hebben we tijdelijk achter een onderhoudsmelding gezet. Een handvol klanten vroeg ons hetzelfde voor hun website te doen, en dat hebben we gedaan.

Ja. Het grootste deel van onze shared hostingservers draait Imunify360. Dat scant bestanden doorlopend op malware en blokkeert verdachte verzoeken. Sinds vanochtend bevat het ook een regel tegen het aanvalspatroon dat nu rondgaat^[6]. Na de update van 16:00 uur laten we daarnaast een extra scan op onze servers draaien.

Kan een aanval op een andere website op dezelfde server ook mijn site raken?

Op onze shared hosting draait elk account afgeschermd van de andere accounts, met CloudLinux CageFS. Een aanvaller die via een andere site binnenkomt, kan daardoor niet zomaar bij jouw bestanden.

Mijn site draait niet op de allernieuwste PHP-versie. Moet ik iets doen?

Niet voor dit lek: we hebben ook de oudere PHP-versies op onze servers gerepareerd. Wel raden we aan om een zo hoog mogelijke versie te gebruiken, zie ons advies over de PHP-versie.