--- title: "Wat is PHP-FPM? Uitleg en betekenis | Keurig Online" description: "PHP-FPM (FastCGI Process Manager) draait PHP als een aparte dienst met eigen processen, los van de webserver." canonical: https://www.keurigonline.nl/begrippenlijst/php-fpm last_modified: 2025-12-18 --- [Terug naar begrippenlijst](https://www.keurigonline.nl/begrippenlijst) # PHP-FPM PHP-FPM (FastCGI Process Manager) draait PHP als een aparte dienst met eigen processen, los van de webserver. Actueel: [PHP-lek PHP2Shell (session.upload\_progress): status en wat je moet doen](https://www.keurigonline.nl/blog/php-kwetsbaarheid-session-upload-progress) PHP-FPM (FastCGI Process Manager) is de manier om PHP als een aparte dienst naast de webserver te draaien. De webserver ontvangt het verzoek van de bezoeker en geeft het via het FastCGI-protocol door aan PHP-FPM, dat het script uitvoert en de HTML teruggeeft. Bij de oudere opstelling mod\_php draait PHP juist als module binnen de webserver Apache zelf. PHP-FPM werkt met een masterproces en een of meer pools. Een pool is een groep workers, de PHP-processen die de verzoeken afhandelen, met een eigen gebruiker en eigen PHP-instellingen. De instelling pm bepaalt hoe die workers ontstaan: een vast aantal (static), meegroeiend met de drukte (dynamic) of alleen bij vraag (ondemand). Met pm.max\_children stel je het maximum aantal gelijktijdige workers in, en met pm.max\_requests start een worker na bijvoorbeeld 500 verzoeken opnieuw. Die scheiding maakt een server stabieler en veiliger, omdat elke site onder een eigen gebruiker kan draaien en een vastgelopen script de webserver niet meeneemt. Bij het PHP-lek van oktober 2026 (CVE-2026-109618) bleek dat ook: de bekende aanval werkte in mod\_php, terwijl PHP-FPM het proces bij die fout juist afsluit. Bij KeurigOnline draait PHP op de VPS'en en de andere DirectAdmin-servers meestal via PHP-FPM. Beheer je zelf een VPS, onthoud dan dat de FPM-master een gewijzigde configuratie pas leest na een herstart of reload. Op een DirectAdmin-server doe je dat bijvoorbeeld met systemctl reload php-fpm83 voor PHP 8.3. Zo'n reload is graceful: lopende verzoeken worden afgemaakt, dus bezoekers merken er niets van. ## Geschiedenis PHP-FPM begon als een patch van Andrei Nigmatulin. Hij wachtte vanaf 2004 op iemand die PHP via FastCGI geschikt maakte voor drukke sites, en schreef het uiteindelijk zelf ([php-fpm.org](https://php-fpm.org/about/)). Het FastCGI-protocol waarop het bouwt, stamt uit 1996 en komt van Open Market ([Wikipedia](https://en.wikipedia.org/wiki/FastCGI)). Belangrijke mijlpalen: - **1996:** Open Market publiceert de FastCGI-specificatie - **2004:** Andrei Nigmatulin begint aan PHP-FPM, eerst als losse patch voor PHP - **22 juli 2010:** [PHP 5.3.3](https://www.php.net/releases/5_3_3.php) neemt FPM op als standaard-SAPI - **1 maart 2012:** PHP 5.4.0 haalt het label experimenteel van FPM af ([changelog](https://www.php.net/ChangeLog-5.php#5.4.0)) ## Bronnen 1. **PHP.net** - [FastCGI Process Manager (FPM)](https://www.php.net/manual/en/install.fpm.php) 2. **PHP.net** - [FPM configuration: pools, pm en pm.max\_children](https://www.php.net/manual/en/install.fpm.configuration.php) 3. **PHP-FPM** - [About PHP-FPM: geschiedenis en vergelijking](https://php-fpm.org/about/) 4. **PHP.net (2010)** - [PHP 5.3.3 Release Announcement](https://www.php.net/releases/5_3_3.php) 5. **Wikipedia** - [FastCGI](https://en.wikipedia.org/wiki/FastCGI) ## 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) **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](https://www.keurigonline.nl/blog/php-lek-terugblik). 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. 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) 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. 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) ## 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](https://www.keurigonline.nl/blog/php-lek-terugblik).