En bref : avec Apache et mod_php, PHP s'exécute directement dans le serveur web. L'équipe PHP estime que le risque lié à PHP2Shell est le plus élevé précisément dans ce mode d'exécution, car un exploit a été démontré avant même que le code de l'application ne s'exécute. Corrigez immédiatement, redémarrez Apache complètement, puis planifiez le passage à PHP-FPM.
Ce qu'est mod_php et pourquoi c'est important maintenant
Avec mod_php, Apache charge PHP comme module dans chacun de ses processus de travail. Chaque requête vers un fichier PHP est exécutée directement dans ce processus. Ce fut longtemps la norme et c'est simple à mettre en place. Mais cela signifie aussi : tous les sites du serveur tournent avec le même utilisateur, et PHP partage le processus avec le serveur web.
PHP2Shell regroupe les failles CVE-2026-109618 et CVE-2026-109619, toutes deux CVSS v4.0 9.2. Avec la seconde, l'état interne d'une requête peut subsister après la libération de la mémoire et être utilisé par une requête ultérieure dans le même processus. Pour mod_php, l'équipe PHP a établi le risque le plus élevé. Le contexte et l'analyse figurent sous Pourquoi mod_php porte le risque le plus élevé.
Identifier Apache mod_php et vérifier la version
Vérifiez d'abord si votre Apache utilise réellement mod_php. Les commandes suivantes se contentent de lire. Les noms de commandes et de paquets varient selon la distribution et sont des exemples.
# Debian/Ubuntu : modules chargés
apache2ctl -M 2>/dev/null | grep -i php
# Famille RHEL
httpd -M 2>/dev/null | grep -i php
# Quel MPM est actif ? mod_php suppose prefork
apache2ctl -V 2>/dev/null | grep -i mpm
# État des paquets du module (exemples)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
Si un module comme php_module apparaît, mod_php est en service. La version de PHP affichée ne prouve pas à elle seule le correctif, car les distributions appliquent souvent les corrections sous forme de backport. Les versions corrigées du projet PHP sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour les paquets de distribution, c'est le journal des modifications avec les numéros CVE qui compte.
Corriger et redémarrer Apache complètement
Installez la mise à jour via le gestionnaire de paquets. Comme PHP est intégré au processus Apache, le service entier doit ensuite redémarrer. Recharger la configuration n'est pas la voie sûre ici.
# Debian/Ubuntu
systemctl restart apache2
# Famille RHEL
systemctl restart httpd
# Contrôle : heure de démarrage de tous les processus Apache
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
Tous les processus Apache doivent afficher une heure de démarrage postérieure à la mise à jour. Si PHP-FPM ou php-cgi tourne en plus sur le même serveur, redémarrez aussi ces services.
Si aucun correctif n'est encore disponible pour votre version de PHP, le BSI (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. Avec mod_php, cela pèse particulièrement lourd, car l'attaque peut agir avant le code de l'application.
Mesures transitoires dans la configuration Apache
php.net indique des mesures transitoires qui réduisent le risque mais n'offrent pas de protection complète. Avec mod_php, définissez les valeurs avec php_admin_value ou php_admin_flag dans la configuration Apache, afin que .htaccess et les applications ne puissent pas les écraser.
# Exemple : dans la configuration VirtualHost ou globale au serveur
<IfModule php_module>
php_admin_flag session.upload_progress.enabled off
php_admin_value post_max_size 8M
php_admin_value upload_max_filesize 6M
</IfModule>
Avec une fonction d'envoi de fichiers, php.net indique post_max_size = 32M, avec upload_max_filesize en dessous. Sur PHP 8.5, fatal_error_backtraces=0 s'y ajoute. La recommandation relative à memory_limit=-1 ne s'applique qu'avec une limite de mémoire pour le service via les cgroups, par exemple avec MemoryMax dans un complément systemd, et non via RLIMIT_AS ou RLIMIT_DATA. Redémarrez ensuite Apache complètement. Toutes les mesures en un coup d'œil : Mesures immédiates sans correctif.
S'éloigner de mod_php
Après le correctif d'urgence, le passage à PHP-FPM vaut la peine. PHP y tourne dans ses propres processus, séparés du serveur web. Chaque site peut recevoir son propre pool avec son propre utilisateur, des limites peuvent être définies par pool et les redémarrages ne concernent que PHP. Apache se connecte à PHP-FPM via mod_proxy_fcgi et peut alors utiliser, au lieu de prefork, un MPM plus moderne comme event.
Planifiez le changement dans un environnement de test : créer des pools par site, adapter les droits sur les fichiers aux nouveaux utilisateurs, transférer les entrées .htaccess avec php_value dans les paramètres de pool, effectuer des tests de charge. À quoi ressemble une architecture propre, Sécuriser Nginx avec PHP-FPM le montre ; les principes valent aussi pour Apache avec PHP-FPM.
Quel que soit le mode d'exécution, un correctif ne supprime pas un logiciel malveillant déjà introduit. Conservez les journaux à partir du 20 octobre 2026 et recherchez des traces sur le serveur.
Pour la recherche de traces sur les serveurs mod_php, un coup d'œil à l'utilisateur commun s'impose. Comme tous les sites tournent sous l'utilisateur Apache, par exemple www-data ou apache, un attaquant qui a pris le contrôle d'un site peut en règle générale lire et modifier aussi les fichiers des autres. Ne vérifiez donc pas seulement le site qui vous paraît suspect, mais tous les document roots du serveur. Soyez particulièrement attentif aux fichiers PHP à la date de modification récente dans les répertoires d'envoi et de cache, au code de programme appartenant à l'utilisateur Apache et aux entrées inconnues dans la crontab de cet utilisateur. Si vous trouvez quelque chose, sauvegardez d'abord l'état du système et ne supprimez rien précipitamment, afin que la cause reste compréhensible par la suite.
Comment PHP SOS aide-t-il concrètement ?
- Nous vérifions le mode d'exécution, le MPM et l'état des paquets et évaluons si votre serveur est réellement corrigé.
- Via le service de correctifs PHP, nous installons la mise à jour, redémarrons Apache complètement et documentons la preuve.
- D'ici le correctif, nous définissons les mesures transitoires sans possibilité de les écraser et limitons la mémoire au niveau du service.
- Dans le cadre du durcissement de serveur, nous planifions et testons le passage à PHP-FPM avec des pools séparés.
Questions fréquentes
Comment savoir si mon serveur utilise mod_php ?
Si Apache a chargé un module PHP, il apparaît dans la liste des modules sous le nom php_module ou avec un numéro de version dans le nom. En outre, une sortie phpinfo indique l'entrée Apache 2.0 Handler sous Server API. Supprimez immédiatement un tel fichier de test.
Pourquoi mod_php est-il particulièrement critique avec PHP2Shell ?
Selon l'équipe PHP, le risque y est le plus élevé ; un exploit a été démontré avant même que le code de l'application ne s'exécute. Même une application bien entretenue ne protège donc pas. Une mise à jour rapide est de ce fait la priorité absolue.
Un rechargement d'Apache suffit-il après la mise à jour ?
Un redémarrage complet du service est la voie sûre, car PHP est intégré comme module dans les processus Apache. Vérifiez ensuite l'heure de démarrage de tous les processus Apache. Aucun processus plus ancien que la mise à jour ne doit subsister.
Le passage à PHP-FPM est-il compliqué ?
Il est généralement bien planifiable : installer PHP-FPM, créer des pools, configurer Apache avec proxy_fcgi et passer de prefork à un autre MPM. Testez-le au préalable sur une copie de l'environnement.