# Plusieurs versions de PHP sur un serveur : corriger chacune séparément > Plusieurs versions de PHP sur un serveur : trouver toutes les installations, clarifier origine et responsabilité, corriger chacune, la redémarrer et le prouver. Source : https://phpsos.de/fr/blog/mehrere-php-versionen-server/ É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 :** lorsque plusieurs versions de PHP tournent sur un serveur, chacune doit, après PHP2Shell, être vérifiée, mise à jour et redémarrée séparément. Les sources typiques sont le système d'exploitation, les panneaux d'hébergement comme Plesk ou cPanel, les sources tierces comme sury.org ou Remi, CloudLinux, LiteSpeed et les versions compilées soi-même. Seule une liste complète établie à partir des paquets, des fichiers et des processus en cours montre si aucune version n'a vraiment été oubliée. ## La version oubliée Un serveur en service depuis quelques années accumule les versions de PHP comme un grenier les vieux meubles. Le panneau en a apporté trois branches, une version plus ancienne est venue d'une source tierce pour un client, le système d'exploitation a la sienne. Chacune a été installée un jour pour de bonnes raisons. Seulement, plus personne ne sait aujourd'hui lesquelles sont encore nécessaires. Après PHP2Shell, c'est précisément un problème. Les correctifs sont parus le 21 octobre 2026 pour PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Mais chaque installation du serveur les reçoit par sa propre voie, de son propre mainteneur de paquet et à son propre moment. Pour PHP 8.1 et antérieur, il n'existe que des rétroportages minimaux du code source. Qui ne met à jour que la version principale laisse les autres ouvertes. ## D'où viennent les nombreuses versions Le tableau suivant énumère des sources typiques et des chemins d'exemple. Les chemins exacts diffèrent selon la version et la distribution. | Source | Chemin d'exemple | Qui fournit le correctif | |---|---|---| | Système d'exploitation Debian/Ubuntu | `/usr/bin/php8.3`, `/etc/php/8.3/` | Distribution | | Système d'exploitation famille RHEL | `/usr/bin/php`, `/etc/php-fpm.d/` | Distribution | | Plesk | `/opt/plesk/php/8.3/` | Plesk | | cPanel (EasyApache 4) | `/opt/cpanel/ea-php83/` | cPanel | | CloudLinux alt-php | `/opt/alt/php83/` | CloudLinux | | Remi Software Collection | `/opt/remi/php83/` | Remi | | sury.org | `/usr/bin/php8.3` comme pour le système | sury.org | | LiteSpeed | `/usr/local/lsws/lsphp83/` | LiteSpeed ou source de paquets | | Compilé soi-même | souvent `/usr/local/bin/php` | Vous-même | | Conteneur | dans l'image | Éditeur de l'image, reconstruction par vous | Les paquets sury.org sont particulièrement trompeurs, car ils utilisent les mêmes chemins que la distribution. Seule la source du paquet indique si un `php8.3` vient de Debian ou de sury.org. Les particularités sont décrites dans les articles [Le dépôt sury.org](https://phpsos.de/fr/blog/sury-repository-php/) et [Le dépôt Remi](https://phpsos.de/fr/blog/remi-repository-php/). La façon dont Plesk gère ses versions est décrite sur la page [Serveur Plesk : vérifier et corriger les versions de PHP](https://phpsos.de/fr/server/plesk/). ## Trouver toutes les installations PHP Une liste fiable résulte de trois points de vue. Les commandes sont en lecture seule et peuvent, selon le serveur, durer un certain temps. ```bash # 1. Paquets : ce que connaît la gestion des paquets dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp" rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort # 2. Fichiers : binaires PHP exécutables, y compris hors de la gestion des paquets find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null # 3. Processus : ce qui tourne réellement en ce moment, avec l'heure de démarrage ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp" ``` Comparez les trois listes. Un fichier sans paquet évoque une version compilée soi-même ou copiée manuellement. Un processus sans fichier correspondant peut indiquer une installation supprimée mais encore en cours d'exécution. Avec Apache, vérifiez en outre si un module PHP est chargé, par exemple avec `apache2ctl -M` ou `httpd -M`. Les conteneurs et les pods Kubernetes n'apparaissent qu'en partie dans ces listes et nécessitent un contrôle séparé des images. ## Corriger chaque version séparément Quand chaque installation a une ligne dans votre liste, la même procédure suit pour chacune : 1. **Clarifier la responsabilité :** le correctif vient-il de la distribution, du panneau, d'une source tierce ou de vous-même ? 2. **Évaluer l'état :** version corrigée officielle, rétroportage confirmé, indéterminé ou ouvert. 3. **Mettre à jour :** par la voie de la source concernée, non par une autre. 4. **Redémarrer :** le service de cette version, pas seulement le service principal. Avec mod_php, le serveur web. Les détails figurent sous [Redémarrer PHP-FPM et tous les workers](https://phpsos.de/fr/php2shell/php-fpm-neustart/). 5. **Contrôler :** comparer l'heure de démarrage des processus avec la date de la mise à jour. 6. **Documenter :** version, état du paquet, preuve, heure du redémarrage. Pour les versions sans correctif, les mesures transitoires de php.net s'appliquent jusqu'à la migration. Appliquez-les séparément pour chaque version, car chaque installation a son propre php.ini et ses propres pools. > **Important:** > N'oubliez pas la ligne de commande. Les tâches cron et les scripts tournent souvent avec une autre version de PHP que le site web. Cette version aussi doit être à un état corrigé, même si elle ne traite aucune requête web. ## Quelle version utilise la ligne de commande, laquelle le conteneur ? Deux domaines échappent particulièrement souvent à la recherche. Le premier est la ligne de commande. Sous Debian et Ubuntu, le système des alternatives décide quel binaire se cache derrière la commande `php`. `update-alternatives --display php` montre quelles versions sont enregistrées et laquelle est active. Les tâches cron qui appellent un chemin fixe comme `/usr/bin/php7.4` contournent toutefois ce réglage. C'est pourquoi il vaut la peine de regarder les crontabs de tous les utilisateurs et la configuration des panneaux qui créent leurs propres tâches cron. Le second domaine, ce sont les conteneurs. Un conteneur Docker sur le serveur apporte sa propre version de PHP, qui n'apparaît dans aucune liste de paquets de l'hôte. `docker ps` montre les conteneurs en cours ; un coup d'œil dans l'image ou un `php -v` dans le conteneur révèle si PHP s'y trouve et dans quelle version. Le correctif n'y est pas appliqué sur l'hôte, mais par reconstruction de l'image et remplacement du conteneur. ## Moins, c'est plus sûr Le meilleur contrôle est celui qu'on n'a pas à faire. Chaque version de PHP installée double le travail lors de la prochaine faille. Après PHP2Shell, une règle claire s'impose donc : chaque version sur le serveur a besoin d'un objectif et d'un responsable. Ce qui n'en a pas est d'abord désactivé, puis supprimé après une période d'observation. Plus de détails dans l'article [Désactiver les anciennes versions de PHP dans le panneau d'hébergement](https://phpsos.de/fr/blog/alte-php-versionen-abschalten/). ## Comment PHP SOS aide-t-il concrètement ? - Nous établissons pour vos serveurs une liste complète de toutes les installations PHP à partir des paquets, des fichiers, des processus et des conteneurs. - Nous clarifions pour chaque version l'origine, la responsabilité et l'état des correctifs. - Dans le cadre du [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), nous mettons à jour chaque version, redémarrons chaque service et prouvons l'état obtenu. - Avec vous, nous décidons quelles versions restent et supprimons les autres de façon contrôlée. ## Questions fréquentes **Pourquoi plusieurs versions de PHP tournent-elles sur mon serveur ?** Les raisons fréquentes sont des panneaux d'hébergement qui apportent leurs propres builds de PHP, des sources tierces comme sury.org ou Remi pour des versions plus récentes, et des applications anciennes qui exigent une version précise. S'y ajoute souvent la version de PHP du système d'exploitation. **Une version de PHP qu'aucun site n'utilise est-elle dangereuse ?** Tant qu'elle est installée et active comme service, elle peut être accessible, par exemple via un domaine de test, un pool oublié ou une tâche cron. En outre, elle peut par la suite être attribuée par mégarde à un site. Les versions inutiles devraient être supprimées. **Comment trouver toutes les installations PHP sur un serveur Linux ?** Combinez trois points de vue : les paquets installés, les fichiers PHP exécutables du système de fichiers et les processus en cours. La liste n'est complète que lorsque les trois donnent la même image. **Dois-je redémarrer chaque version séparément après la mise à jour ?** Oui. Chaque version a en règle générale son propre service FPM, LiteSpeed ses propres processus lsphp, mod_php vit dans le processus Apache. Le redémarrage du service principal ne renouvelle pas les autres. ## Sources - [php.net : avis de sécurité](https://www.php.net/) - [php.net : versions prises en charge](https://www.php.net/supported-versions.php) - [Red Hat Security Bulletin RHSB-2026-013](https://access.redhat.com/security/vulnerabilities/RHSB-2026-013)