--- title: "Wat is CageFS? Uitleg en betekenis | Keurig Online" description: "CageFS is een virtueel bestandssysteem van CloudLinux dat elk hostingaccount in een eigen, afgeschermde kooi plaatst." canonical: https://www.keurigonline.nl/begrippenlijst/cagefs last_modified: 2025-12-18 --- [Terug naar begrippenlijst](https://www.keurigonline.nl/begrippenlijst) # CageFS CageFS is een virtueel bestandssysteem van CloudLinux dat elk hostingaccount in een eigen, afgeschermde kooi plaatst. Actueel: [PHP-lek PHP2Shell (session.upload\_progress): status en wat je moet doen](https://www.keurigonline.nl/blog/php-kwetsbaarheid-session-upload-progress) CageFS is een virtueel bestandssysteem van CloudLinux dat elke gebruiker op een gedeelde server in een eigen kooi zet, een cage. Binnen die kooi heeft het account een complete omgeving met systeembestanden en tools, maar van de andere accounts op dezelfde server ziet het niets. Een gebruiker in CageFS kan geen andere gebruikers of gebruikersnamen zien, geen configuratiebestanden van de server openen en alleen zijn eigen processen bekijken. Typ je via SSH het commando top, dan zie je dus alleen je eigen processen. Zelfs het bestand /etc/passwd is binnen de kooi ingekort tot een handvol regels. Dat beperkt de schade als één website wordt gehackt. Een aanvaller die via een lek in een andere site binnenkomt, belandt in de kooi van dat account en kan daardoor niet zomaar bij jouw bestanden. Elk account krijgt bovendien een eigen /tmp-map en een eigen kopie van de PHP-configuratie, zodat tijdelijke bestanden en sessies niet op een gedeelde plek staan. Bij KeurigOnline draait elk account op de shared hosting in CageFS. Tijdens het PHP-lek van oktober 2026 was dat een van de lagen die een aanval op de ene website weghield van de andere. Als klant merk je er weinig van, want je scripts, cronjobs en SSH-sessies werken gewoon, alleen binnen je eigen kooi. ## Geschiedenis CloudLinux OS verscheen in januari 2010, met LVE om CPU, geheugen en processen per account te begrenzen ([Wikipedia](https://en.wikipedia.org/wiki/CloudLinux_OS)). CageFS voegde daar de afscherming van het bestandssysteem aan toe. Volgens hoster Hawk Host is het sinds augustus 2011 publiek beschikbaar ([Hawk Host](https://www.hawkhost.com/blog/2013/02/28/introducing-cagefs-a-quick-overview/)). Belangrijke mijlpalen: - **Januari 2010:** Eerste versie van CloudLinux OS - **Augustus 2011:** CageFS wordt publiek beschikbaar - **Nu:** CageFS schermt scripts af die draaien via LiteSpeed, suEXEC, cron en SSH; mod\_php wordt niet ondersteund ([CloudLinux-documentatie](https://docs.cloudlinux.com/cloudlinuxos/cloudlinux_os_components/#cagefs)) ## Bronnen 1. **CloudLinux** - [CageFS: General information and requirements](https://docs.cloudlinux.com/cloudlinuxos/cloudlinux_os_components/#cagefs) 2. **Wikipedia** - [CloudLinux OS](https://en.wikipedia.org/wiki/CloudLinux_OS) 3. **Hawk Host (2013)** - [Introducing CageFS - A Quick Overview](https://www.hawkhost.com/blog/2013/02/28/introducing-cagefs-a-quick-overview/) ## Gerelateerde artikelen Beveiliging 22 okt 2026 [CVE-2026-109618 en -109619: de technische deepdive](https://www.keurigonline.nl/blog/php-lek-cve-2026-109618-deepdive) 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. Beveiliging 22 okt 2026 [Het PHP-lek van 21 oktober: wat we deden en waarom we online bleven](https://www.keurigonline.nl/blog/php-lek-terugblik) 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. Blog 21 okt 2026 [PHP-lek PHP2Shell (session.upload\_progress): status en wat je moet doen](https://www.keurigonline.nl/blog/php-kwetsbaarheid-session-upload-progress) 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\]](https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5). 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.