Plesk: PHP-handlers begrijpen (FPM, FastCGI, Apache-module)

Kort gezegd: De Plesk PHP-handler bepaalt hoe PHP voor een website draait: als FPM-toepassing met gedeelde pool, als Dedicated FPM met een eigen pool per website, als FastCGI-toepassing of als Apache-module (mod_php). Vanuit veiligheidsoogpunt is Dedicated FPM onder Linux meestal de beste keuze, de Apache-module de slechtste. Plesk zelf noemt haar verouderd respectievelijk onveilig, en bij PHP2Shell ziet het PHP-team het hoogste risico juist bij mod_php.

Waarom de handler meer is dan een prestatiekwestie

In Plesk kiest u voor elke website een PHP-versie en een handler. Velen behandelen de handler als een detail voor prestaties en geheugen. Hij bepaalt echter ook hoe sterk websites van elkaar gescheiden zijn, waar beveiligingsinstellingen werken en welke processen na een update moeten worden herstart.

Na PHP2Shell wordt deze keuze concreet. De lekken CVE-2026-109618 en CVE-2026-109619 treffen alle gangbare bedrijfsmodi, maar het PHP-team schat het risico bij mod_php het hoogst in. Wie op zijn Plesk-server nog domeinen met de Apache-module draait, moet dat nu wijzigen. Hoe u versies controleert en patcht, beschrijft de pagina Plesk-server: PHP-versies controleren en patchen; hier gaat het om de keuze van de bedrijfsmodus.

De Plesk PHP-handlers in overzicht

Het onderstaande overzicht berust op de Plesk-documentatie voor Plesk Obsidian, aangevuld met het veiligheidsperspectief. Onder Linux kunnen FPM-handlers volgens Plesk naar keuze via Apache of nginx worden geleverd, FastCGI altijd via Apache.

Achtergronden bij de bedrijfsmodi zelf leggen de pagina's PHP-FPM uitgelegd en Waarom mod_php het hoogste risico draagt uit.

Gedeelde of eigen pool?

Het verschil tussen FPM en Dedicated FPM wordt vaak onderschat. Bij de gewone FPM-handler delen volgens Plesk alle websites met dezelfde PHP-versie één procespool. Dat bespaart geheugen, maar betekent ook: een website die problemen veroorzaakt, kan alle andere met dezelfde versie meetrekken, en de gedeelde cache wordt gedeeld.

Dedicated FPM geeft elke website een eigen pool. Volgens Plesk verbetert dat isolatie en prestaties, maar kost het meer geheugen. Vanuit veiligheidsoogpunt is de eigen pool de basis om instellingen zoals open_basedir, geheugengrenzen of uploadlimieten per website apart in te stellen. Hoe u pools consequent scheidt, beschrijft het artikel PHP-FPM-pools per website isoleren.

nginx of Apache: de .htaccess-valkuil

Kiest u een handler die via nginx wordt geleverd, dan verandert er iets fundamenteels: volgens Plesk negeren deze handlers het bestand .htaccess. Wat daar staat, werkt niet meer.

Dat is een veiligheidskwestie. Veel toepassingen en beheerders plaatsen beschermingsregels in .htaccess, zoals een verbod om PHP-bestanden in uploadmappen uit te voeren, of blokkades voor configuratiebestanden. Na een wissel naar nginx zijn deze regels stilzwijgend buiten werking. Controleer daarom vóór de wissel welke beschermingsregels in .htaccess staan en draag ze over naar de nginx-configuratie van het domein.

De handler controleren en omzetten

Eerst verschaft u zich een overzicht van welke domeinen welke handler gebruiken. De opdrachten zijn uitsluitend lezend.

# Alle geregistreerde handlers met ID, versie en type
plesk bin php_handler --list

# Domeinen die een bepaalde handler gebruiken (ID uit de lijst)
plesk bin php_handler --get-usage -id <handler-id>

# Draait PHP in het Apache-proces? (Debian/Ubuntu: apache2ctl, RHEL-familie: httpd)
apache2ctl -M 2>/dev/null | grep -i php

Voor de omzetting gaat u domein voor domein te werk:

1. Beschermingsregels uit .htaccess vastleggen als de nieuwe handler via nginx wordt geleverd.
2. Overbruggingswaarden tegen PHP2Shell, bijvoorbeeld session.upload_progress.enabled=0, instellen voor de nieuwe handler. Bij FPM horen ze als php_admin_value in de aanvullende directieven van de pool, bij FastCGI werken andere wegen.
3. Handler in de PHP-instellingen van het domein wijzigen, bij voorkeur eerst op een kopie.
4. Functies testen en controleren of het domein door processen met actuele code wordt bediend.
5. Wordt de Apache-module door geen enkel domein meer gebruikt, dan de handler deactiveren.

In welke volgorde omzetten?

Op een gegroeide Plesk-server is zelden alles in één dag om te zetten. Een volgorde op basis van risico helpt de schaarse tijd zinvol in te zetten:

• Eerst domeinen met de Apache-module, want daar is het risico door PHP2Shell volgens het PHP-team het hoogst en Plesk raadt het ook al af.
• Dan domeinen met gevoelige data, zoals webshops, klantenportalen of formulieren met gezondheids- of contractgegevens. Hier loont de eigen pool bijzonder.
• Daarna domeinen op oude PHP-versies, die toch al moeten worden omgezet. Handler en versie kunnen in één onderhoudsvenster samen worden gewijzigd.
• Tot slot de wissel van gedeelde naar eigen pool voor de overige domeinen, voor zover het geheugen van de server dat toelaat.

Controleer vóór de laatste stap de geheugenbelasting. Plesk wijst erop dat Dedicated FPM meer geheugen nodig heeft, en adviseert bij veel websites monitoring. Een server die na de omzetting gaat swappen, wordt traag, en krap geheugen is juist bij PHP2Shell geen goede toestand.

Hoe helpt PHP SOS concreet?

• Wij leggen vast welke domeinen op uw Plesk-server welke handler gebruiken, en markeren domeinen met Apache-module.
• Wij zetten om naar Dedicated FPM en dragen beschermingsregels uit .htaccess waar nodig over naar de nginx-configuratie.
• Wij stellen overbruggingswaarden en grenzen per pool in en controleren dat ze in de webcontext werken.
• In het kader van de serverbeveiliging deactiveren wij verouderde handlers en documenteren wij de configuratie.

Veelgestelde vragen

Bronnen

• Plesk-documentatie: Choosing the PHP Handler
• Plesk-documentatie: php_handler
• php.net: beveiligingsmeldingen