# Pourquoi mod_php porte le risque le plus élevé

> Pourquoi l'équipe PHP estime le risque de PHP2Shell le plus élevé avec Apache et mod_php, comment reconnaître mod_php et ce qu'il faut corriger et changer.

Source : https://phpsos.de/fr/php2shell/mod-php-risiko/  
É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 :** tous les modes d'exécution courants sont concernés par PHP2Shell, mais avec Apache et mod_php, l'équipe PHP estime le risque le plus élevé. Un exploit y a été démontré avant même que le code de l'application ne s'exécute. Qui exploite mod_php devrait d'abord mettre PHP à jour et redémarrer Apache complètement.

## Qu'est-ce que mod_php ?

Avec mod_php, PHP est un module à l'intérieur du serveur web Apache. Chaque processus Apache contient un interpréteur PHP complet et exécute directement le code PHP. Ce mode d'exécution a longtemps été la norme et reste répandu aujourd'hui sur les anciens serveurs, dans de nombreux paquets de distribution et dans certaines images Docker.

L'alternative est PHP-FPM : PHP y fonctionne comme un service autonome avec ses propres processus, et Apache ou Nginx ne fait que transmettre les requêtes. Les deux variantes sont concernées par PHP2Shell, de même que php-cgi, FrankenPHP et LiteSpeed.

Les environnements typiques avec mod_php sont d'anciens serveurs root qui tournent inchangés depuis des années, des installations Apache standard issues de paquets de distribution et des images Docker avec Apache et PHP dans un seul conteneur. Qui ne sait pas avec certitude quel mode d'exécution son serveur utilise devrait le vérifier plutôt que le supposer.

## Pourquoi la faille mod_php est-elle jugée particulièrement risquée ?

L'équipe PHP a donné une appréciation claire sur PHP2Shell : avec mod_php, le risque est le plus élevé. Justification : un exploit y a été démontré, qui agit avant même que le code de l'application ne s'exécute.

Pour les exploitants, cela a une conséquence inconfortable. De nombreuses mesures de protection se trouvent dans l'application : plugins de sécurité dans WordPress, modules de pare-feu dans les boutiques, contrôles dans le code propre. Tous sont du code d'application. Si l'exploitation a lieu avant eux, ils arrivent trop tard.

S'y ajoute l'imbrication étroite : avec mod_php, PHP partage le processus avec Apache. Ce que PHP compromet s'exécute avec les droits du serveur web et dans sa mémoire. Avec PHP-FPM, en revanche, les pools peuvent être séparés par des utilisateurs distincts pour chaque site web, ce qui peut limiter les conséquences d'une intrusion.

Pour établir les priorités, cela signifie : si vous exploitez plusieurs serveurs, ceux avec mod_php passent en premier, et un examen ultérieur des traces y est particulièrement important.

Ce que nous ne savons pas : combien des 22,6 millions d'instances exposées et potentiellement vulnérables comptabilisées dans le monde utilisent mod_php. Aucun chiffre fiable n'a été publié à ce sujet.

## Mon serveur utilise-t-il mod_php ?

Les commandes suivantes sont en lecture seule. Les noms de services et de commandes varient selon la distribution : Debian et Ubuntu utilisent `apache2`, la famille RHEL `httpd`.

```bash
apachectl -M 2>/dev/null | grep -i php     # p. ex. php_module ou php8_module
httpd -M 2>/dev/null | grep -i php         # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php                   # Debian/Ubuntu
apt policy libapache2-mod-php8.3           # Debian/Ubuntu, version du paquet du module
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # famille RHEL
```

Si aucun module PHP n'apparaît, Apache utilise probablement PHP-FPM via `proxy_fcgi`. Les indications de [Sécuriser Nginx avec PHP-FPM](https://phpsos.de/fr/server/nginx-php-fpm/) s'appliquent alors par analogie.

## Ce que les exploitants de mod_php devraient faire maintenant

1. **Mettre à jour le module PHP** vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou un backport confirmé de votre distribution.
2. **Redémarrer Apache complètement,** et pas seulement le recharger. Avec mod_php, l'ancien code PHP se trouve dans chaque processus Apache.

```bash
sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # famille RHEL
ps -o pid,lstart,cmd -C apache2    # vérifier l'heure de démarrage, sous RHEL : -C httpd
```

3. **Mettre en place des mesures transitoires si la mise à jour n'est pas encore possible.** php.net cite notamment des limites fixes que les applications ne peuvent pas écraser :

```apache
# configuration du serveur ou VirtualHost, pas .htaccess
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
```

Avec `memory_limit=-1`, une limite de mémoire via cgroup en fait partie, et non via `RLIMIT_AS` ou `RLIMIT_DATA`. Ces mesures ne sont pas une protection complète ; les détails figurent sous [Mesures immédiates si vous ne pouvez pas encore appliquer le correctif](https://phpsos.de/fr/php2shell/sofortmassnahmen-ohne-patch/). Si ni l'un ni l'autre n'est possible immédiatement, le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) recommande de déconnecter temporairement le serveur web du réseau.

> **Agir immédiatement:**
> Si votre Apache avec mod_php est resté exposé sans protection sur Internet entre le 17 octobre et le correctif, sauvegardez les journaux à partir du 20 octobre et faites rechercher des traces sur le serveur. Le correctif seul ne prouve pas que rien ne s'est produit.

## À moyen terme : abandonner mod_php

Après le correctif, un regard sur l'architecture vaut la peine. Le passage à PHP-FPM avec Apache `mpm_event` et `proxy_fcgi`, ou avec Nginx, sépare PHP du serveur web, permet des pools et des utilisateurs distincts pour chaque site web et simplifie les redémarrages et les changements de version. Il ne referme pas PHP2Shell, mais réduit la surface d'attaque de futures failles.

La bascule exige de la planification. Les réglages définis jusqu'ici par `php_value` dans `.htaccess` n'agissent plus sous PHP-FPM et doivent migrer dans le pool. Les utilisateurs et les droits changent, les répertoires d'envoi et de cache peuvent nécessiter de nouvelles autorisations. Dans un environnement de test, c'est bien maîtrisable, pas en production sous la pression du temps. Des indications sur la bascule figurent sous [Sécuriser Apache avec mod_php](https://phpsos.de/fr/server/apache-mod-php/).

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

- **Détecter :** nous vérifions quels serveurs utilisent mod_php et de quelle source de paquets provient le module.
- **Corriger et redémarrer :** via le [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), nous installons la mise à jour et contrôlons qu'aucun ancien processus Apache ne tourne plus.
- **Sécuriser la transition :** là où la mise à jour est bloquée, nous mettons en place les mesures de php.net dans la configuration du serveur.
- **Basculer :** dans le cadre du [durcissement de serveur](https://phpsos.de/fr/leistungen/server-haertung/), nous planifions et testons le passage à PHP-FPM avec des pools séparés.


## Questions fréquentes

**Comment reconnaître si mon Apache utilise mod_php ?**  
Avec apachectl -M ou httpd -M, vous voyez les modules chargés. Si un module comme php_module ou php8_module y figure, PHP s'exécute directement dans Apache. Sous Debian et Ubuntu, a2query -m indique aussi si un module php est actif.

**Un plugin de sécurité dans WordPress me protège-t-il avec mod_php ?**  
Pas pour cette faille. Selon l'équipe PHP, un exploit a été démontré avec mod_php avant même que le code de l'application ne s'exécute. Un plugin est du code d'application et arrive donc trop tard. Seule la mise à jour de PHP avec redémarrage d'Apache protège.

**Dois-je maintenant passer de mod_php à PHP-FPM ?**  
D'abord corriger, ensuite changer. Passer à PHP-FPM est judicieux à moyen terme pour la plupart des configurations, car PHP fonctionne alors séparément du serveur web. Cela ne referme toutefois pas PHP2Shell, car PHP-FPM est lui aussi concerné.

## Sources

- [php.net : avis de sécurité](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI : office fédéral allemand de la sécurité des technologies de l'information](https://www.bsi.bund.de/)