En bref : php-cgi est la plus ancienne manière d'exploiter PHP derrière un serveur web et tourne encore sur de nombreux serveurs, souvent sans qu'on le remarque. La faille php-cgi de PHP2Shell concerne expressément ce mode d'exécution. Corrigez, arrêtez tous les processus php-cgi en cours et planifiez le passage à PHP-FPM.
Ce qu'est php-cgi et où il tourne encore
PHP existe en plusieurs variantes : comme programme en ligne de commande, comme module Apache, comme PHP-FPM et comme php-cgi. php-cgi est un programme que le serveur web lance et auquel il transmet les requêtes via CGI ou FastCGI. Sans gestion des processus propre, il est plus simple que PHP-FPM, mais aussi moins contrôlable.
On le trouve typiquement dans d'anciens panneaux d'hébergement, avec Apache et mod_fcgid, dans des scripts wrapper maison pour plusieurs versions de PHP et avec PHP sous Windows et IIS via FastCGI. Dans les agences et les administrations, on trouve en outre des serveurs configurés il y a des années et simplement exploités depuis.
La faille php-cgi dans PHP2Shell
PHP2Shell regroupe les failles CVE-2026-109618 et CVE-2026-109619 dans PHP lui-même, chacune évaluée à CVSS v4.0 9.2. Toutes deux permettent l'exécution de code malveillant sans authentification. Le projet PHP cite expressément php-cgi parmi les modes d'exécution concernés, à côté de PHP-FPM, mod_php, FrankenPHP et LiteSpeed.
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour officielles, seulement des backports minimaux du code source pour 7.4, 8.0 et 8.1. Les configurations php-cgi tournent justement plus souvent que la moyenne sur d'anciennes versions. php-cgi n'est d'ailleurs pas concerné pour la première fois : dès 2024, une faille de php-cgi sous Windows (CVE-2024-4577) avait fait du bruit. Les héritages de ce type méritent donc une attention particulière.
Trouver php-cgi sur le serveur
Les commandes suivantes se contentent de lire et aident à repérer php-cgi. Les chemins et noms de modules sont des exemples.
# Processus php-cgi en cours avec heure de démarrage et utilisateur
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep
# Programmes php-cgi installés
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null
# Apache : mod_fcgid ou mod_cgi est-il chargé ?
apache2ctl -M 2>/dev/null | grep -Ei 'fcgid|cgi'
grep -RniE 'FcgidWrapper|AddHandler.*php|Action.*php' /etc/apache2 /etc/httpd 2>/dev/null
Si vous trouvez des entrées FcgidWrapper ou des handlers pointant vers un programme php-cgi, ce mode d'exécution est en service. Pour chaque programme trouvé, vérifiez la version avec -v. Pour les paquets de distribution, c'est le journal des modifications avec les numéros CVE qui prouve le correctif, car les backports ne modifient souvent pas le numéro de version.
Corriger et arrêter tous les processus
Installez la mise à jour via le gestionnaire de paquets ou la source dont provient php-cgi. Tous les processus php-cgi en cours doivent ensuite disparaître. Avec mod_fcgid, Apache garde des processus en réserve pendant un moment ; un redémarrage complet d'Apache les arrête.
# Redémarrer Apache complètement (Debian/Ubuntu ou famille RHEL)
systemctl restart apache2 # ou : systemctl restart httpd
# Contrôle : reste-t-il des processus php-cgi plus anciens que la mise à jour ?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep
Si php-cgi tourne via un gestionnaire de processus propre ou un service de panneau, redémarrez-le. Sous Windows avec IIS, recyclez les pools d'applications, voir PHP sous Windows et IIS.
Si php-cgi tourne avec PHP 8.1 ou antérieur sur un serveur accessible publiquement, il n'existe pas de correctif officiel. Appliquez immédiatement les mesures transitoires et envisagez, conformément à la recommandation du BSI (office fédéral allemand de la sécurité des technologies de l'information), de déconnecter temporairement le serveur du réseau.
Mesures transitoires avec php-cgi
php.net recommande des mesures transitoires qui n'offrent pas de protection complète. Avec php-cgi, les valeurs doivent figurer dans le php.ini que charge le programme concerné ou dans la configuration du serveur. Les fichiers .user.ini et ini_set() ne suffisent pas pour session.upload_progress.enabled, selon php.net.
; php.ini de l'installation php-cgi
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Avec une fonction d'envoi de fichiers, php.net indique post_max_size = 32M. Sur PHP 8.5, fatal_error_backtraces=0 s'y ajoute. Définissez les limites de mémoire via les cgroups pour le service du serveur web, et non via RLIMIT_AS ou RLIMIT_DATA. Redémarrez ensuite tous les processus.
La voie vers PHP-FPM
À long terme, php-cgi n'est pas un bon choix. PHP-FPM offre des pools par site, des utilisateurs propres, des limites par pool, des pages d'état et des redémarrages contrôlés. Le passage est généralement bien planifiable : installer PHP-FPM, créer des pools, configurer le serveur web en FastCGI vers PHP-FPM, supprimer les scripts wrapper. À quoi ressemble une architecture propre, Sécuriser Nginx avec PHP-FPM le montre. Si une ancienne version de PHP tourne en plus, associez le changement à la mise à niveau.
D'ici le passage, examinez de façon critique la configuration existante. Le serveur web ne doit transmettre à php-cgi que les fichiers avec l'extension .php et pas des chemins qui pointent vers des fichiers inexistants. Dans les répertoires d'envoi, aucune exécution de PHP ne doit être possible. Les scripts wrapper qui chargent un php.ini propre pour chaque site doivent être vérifiés : ces fichiers annulent-ils les valeurs transitoires ? Si un programme php-cgi se trouve directement dans un répertoire accessible publiquement comme cgi-bin, il doit y être supprimé. De tels héritages proviennent souvent d'instructions d'installation d'années passées et sont tout simplement oubliés lors de transformations ultérieures. Documentez chaque découverte avec le chemin et l'usage, afin que la transformation ultérieure n'oublie rien.
Reste important : un correctif ne supprime pas les logiciels malveillants introduits auparavant. Conservez les journaux à partir du 20 octobre 2026.
Comment PHP SOS aide-t-il concrètement ?
- Nous repérons les installations php-cgi, wrappers et handlers et les associons aux sites.
- Nous corrigeons, arrêtons tous les anciens processus et documentons l'état.
- Pour PHP 8.1 et antérieur, nous planifions avec vous la migration vers une version de PHP prise en charge.
- Dans le cadre du durcissement de serveur, nous remplaçons php-cgi par PHP-FPM avec des pools séparés.
Questions fréquentes
Est-ce que j'utilise php-cgi sans le savoir ?
C'est plus fréquent qu'on ne le pense. Des panneaux anciens, des configurations FastCGI avec mod_fcgid et PHP sous Windows avec IIS lancent souvent PHP sous forme de php-cgi. Une liste des processus ou la Server API dans phpinfo l'indique de façon fiable.
FastCGI est-il la même chose que php-cgi ?
Pas tout à fait. FastCGI est un protocole. PHP-FPM et php-cgi peuvent tous deux parler FastCGI, mais php-cgi est le programme plus ancien et plus simple, sans pools ni gestion des processus. PHP2Shell concerne expressément php-cgi.
Que signifie CGI classique avec PHP ?
Avec le CGI classique, le serveur web lance un nouveau processus PHP pour chaque requête. C'est lent et rare aujourd'hui. Plus fréquent est php-cgi derrière mod_fcgid ou FastCGI, où les processus traitent plusieurs requêtes.
Dois-je redémarrer quelque chose après la mise à jour ?
Oui. Dans les configurations FastCGI, les processus php-cgi continuent de tourner pendant un certain temps. Redémarrez le serveur web ou le gestionnaire de processus et vérifiez qu'aucun processus php-cgi n'est plus ancien que la mise à jour.