# Plesk : comprendre les handlers PHP (FPM, FastCGI, module Apache)

> Handlers PHP de Plesk comparés : FPM, Dedicated FPM, FastCGI et module Apache sous l'angle de la sécurité, avec des conseils sur PHP2Shell, nginx et .htaccess.

Source : https://phpsos.de/fr/blog/plesk-php-handler/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** le handler PHP de Plesk détermine comment PHP s'exécute pour un site : comme application FPM avec un pool commun, comme Dedicated FPM avec un pool par site, comme application FastCGI ou comme module Apache (mod_php). Sous l'angle de la sécurité, Dedicated FPM est le plus souvent le meilleur choix sous Linux, le module Apache le pire. Plesk lui-même le qualifie d'obsolète, voire peu sûr, et pour PHP2Shell, l'équipe PHP voit le risque le plus élevé précisément avec mod_php.

## Pourquoi le handler est plus qu'une question de performance

Dans Plesk, vous choisissez pour chaque site une version de PHP et un handler. Beaucoup traitent le handler comme un détail de performance et de mémoire. Or il décide aussi du degré de séparation des sites entre eux, de l'endroit où les paramètres de sécurité agissent et des processus qu'il faut redémarrer après une mise à jour.

Après PHP2Shell, ce choix devient concret. Les failles CVE-2026-109618 et CVE-2026-109619 concernent tous les modes d'exécution courants, mais l'équipe PHP classe le risque comme le plus élevé avec mod_php. Qui exploite encore sur son serveur Plesk des domaines avec le module Apache devrait changer cela maintenant. La façon de vérifier et de corriger les versions est décrite sur la page [Serveur Plesk : vérifier et corriger les versions de PHP](https://phpsos.de/fr/server/plesk/) ; il s'agit ici du choix du mode d'exécution.

## Les handlers PHP de Plesk en un coup d'œil

Le tableau suivant repose sur la documentation de Plesk pour Plesk Obsidian, complétée par l'angle de la sécurité. Sous Linux, les handlers FPM peuvent, selon Plesk, être servis au choix par Apache ou nginx, FastCGI toujours par Apache.

| Handler | Servi par | Isolation | Recommandation selon Plesk | Angle de la sécurité |
|---|---|---|---|---|
| Dedicated FPM application | Apache ou nginx | un pool propre par site | Linux avec hébergement mutualisé | meilleure séparation, valeurs propres par pool |
| FPM application | Apache ou nginx | pool commun par version de PHP | serveurs Linux dédiés | un site défaillant peut perturber les autres de la même version |
| FastCGI application | Apache (Linux) | processus persistants, bonne séparation | serveurs Windows | solide, le plus souvent remplacé par FPM sous Linux |
| Apache module (mod_php) | Apache | PHP dans le processus du serveur web | déconseillé | risque PHP2Shell le plus élevé selon l'équipe PHP |
| CGI application | Apache | nouveau processus par requête | déconseillé | obsolète |

Le contexte des modes d'exécution eux-mêmes est expliqué sur les pages [PHP-FPM expliqué](https://phpsos.de/fr/php/php-fpm-erklaert/) et [Pourquoi mod_php porte le risque le plus élevé](https://phpsos.de/fr/php2shell/mod-php-risiko/).

## Pool commun ou pool propre ?

La différence entre FPM et Dedicated FPM est souvent sous-estimée. Avec le handler FPM normal, tous les sites de la même version de PHP partagent, selon Plesk, un pool de processus. Cela économise de la mémoire, mais signifie aussi qu'un site qui pose problème peut entraîner tous les autres de la même version, et que le cache commun est partagé.

Dedicated FPM donne à chaque site son propre pool. Selon Plesk, cela améliore l'isolation et les performances, mais coûte plus de mémoire. Du point de vue de la sécurité, le pool propre est la base pour définir séparément, par site, des paramètres comme `open_basedir`, les limites de mémoire ou les limites de téléversement. La façon de séparer systématiquement les pools est décrite dans l'article [Isoler les pools PHP-FPM par site](https://phpsos.de/fr/blog/php-fpm-pools-isolieren/).

## nginx ou Apache : le piège de .htaccess

Si vous choisissez un handler servi par nginx, quelque chose de fondamental change : selon Plesk, ces handlers ignorent le fichier `.htaccess`. Ce qui s'y trouve n'agit plus.

C'est un sujet de sécurité. De nombreuses applications et administrateurs placent des règles de protection dans `.htaccess`, par exemple l'interdiction d'exécuter des fichiers PHP dans les répertoires de téléversement ou des blocages de fichiers de configuration. Après un passage à nginx, ces règles sont silencieusement hors d'effet. Vérifiez donc avant le changement quelles règles de protection figurent dans `.htaccess`, et reportez-les dans la configuration nginx du domaine.

> **Important:**
> Un changement de handler est une modification de la configuration de sécurité. Testez ensuite de façon ciblée si les chemins bloqués le restent, et pas seulement si la page d'accueil se charge.

## Vérifier et changer le handler

Commencez par vous faire une vue d'ensemble des domaines qui utilisent quel handler. Les commandes sont en lecture seule.

```bash
# Tous les handlers enregistrés avec ID, version et type
plesk bin php_handler --list

# Domaines qui utilisent un handler donné (ID tiré de la liste)
plesk bin php_handler --get-usage -id <handler-id>

# PHP tourne-t-il dans le processus Apache ? (Debian/Ubuntu : apache2ctl, famille RHEL : httpd)
apache2ctl -M 2>/dev/null | grep -i php
```

Pour le changement, procédez domaine par domaine :

1. Relever les règles de protection de `.htaccess` si le nouveau handler est servi par nginx.
2. Définir pour le nouveau handler les valeurs transitoires contre PHP2Shell, par exemple `session.upload_progress.enabled=0`. Avec FPM, elles vont comme `php_admin_value` dans les directives supplémentaires du pool ; avec FastCGI, d'autres voies agissent.
3. Changer le handler dans les paramètres PHP du domaine, si possible d'abord sur une copie.
4. Tester les fonctions et vérifier que le domaine est servi par des processus avec le code à jour.
5. Si plus aucun domaine n'utilise le module Apache, désactiver le handler.

## Dans quel ordre basculer ?

Sur un serveur Plesk qui s'est étoffé avec le temps, on peut rarement tout basculer en un jour. Un ordre fondé sur le risque aide à employer utilement le temps limité :

- **D'abord les domaines avec le module Apache**, car le risque lié à PHP2Shell y est le plus élevé selon l'équipe PHP, et Plesk le déconseille de toute façon.
- **Ensuite les domaines contenant des données sensibles**, par exemple boutiques, portails clients ou formulaires avec des données de santé ou contractuelles. Le pool propre y est particulièrement utile.
- **Puis les domaines sur d'anciennes versions de PHP**, qui doivent de toute façon être basculés. Handler et version peuvent être changés ensemble dans une fenêtre de maintenance.
- **Enfin le passage du pool commun au pool propre** pour les autres domaines, dans la mesure où la mémoire du serveur le permet.

Avant la dernière étape, vérifiez l'utilisation de la mémoire. Plesk signale que Dedicated FPM demande davantage de mémoire et conseille une surveillance en cas de nombreux sites. Un serveur qui se met à swapper après la bascule devient lent, et une mémoire serrée n'est pas un bon état, précisément avec PHP2Shell.

## Comment PHP SOS aide-t-il concrètement ?

- Nous relevons quels domaines de votre serveur Plesk utilisent quel handler et marquons les domaines avec le module Apache.
- Nous basculons vers Dedicated FPM et reportons, si nécessaire, les règles de protection de `.htaccess` dans la configuration nginx.
- Nous définissons des valeurs transitoires et des limites par pool et vérifions qu'elles s'appliquent dans le contexte web.
- Dans le cadre du [durcissement de serveur](https://phpsos.de/fr/leistungen/server-haertung/), nous désactivons les handlers obsolètes et documentons la configuration.


## Questions fréquentes

**Quel handler PHP Plesk recommande-t-il ?**  
Selon la documentation de Plesk, FPM est le handler recommandé sur les serveurs Linux dédiés, Dedicated FPM sur les serveurs Linux pour l'hébergement mutualisé et FastCGI sur les serveurs Windows. Plesk qualifie le module Apache, CGI et ISAPI de fortement obsolètes, voire peu sûrs.

**Pourquoi le handler module Apache est-il particulièrement critique après PHP2Shell ?**  
Le handler correspond à mod_php. L'équipe PHP classe le risque de PHP2Shell comme le plus élevé avec mod_php, parce qu'un exploit y a été démontré avant l'exécution du code de l'application. De plus, Plesk lui-même déconseille ce handler.

**Qu'est-ce qui change quand PHP est servi par nginx au lieu d'Apache ?**  
Selon Plesk, les handlers servis par nginx ignorent le fichier .htaccess. Les règles de sécurité qui s'y trouvent, par exemple le blocage de PHP dans les répertoires de téléversement, ne s'appliquent alors plus et doivent être reportées dans des règles nginx.

**Dois-je redémarrer PHP après un changement de handler ?**  
Après le changement, vérifiez quels processus PHP tournent pour le domaine et depuis quand. Avec Dedicated FPM, le domaine reçoit son propre pool. Un ancien processus exécutant du code obsolète ne devrait plus travailler pour le domaine ensuite.

**Dedicated FPM est-il toujours le meilleur choix ?**  
Pour l'isolation, oui, car chaque site reçoit son propre pool. Le prix en est un besoin de mémoire plus élevé. Plesk conseille de surveiller dans ce cas les serveurs hébergeant de nombreux sites.

## Sources

- [Documentation Plesk : Choosing the PHP Handler](https://docs.plesk.com/en-US/obsidian/administrator-guide/75145/)
- [Documentation Plesk : php_handler](https://docs.plesk.com/en-US/obsidian/cli-linux/using-command-line-utilities/php_handler-php-handlers.72490/)
- [php.net : avis de sécurité](https://www.php.net/)