En bref : le dépôt PHP Remi fournit des versions de PHP actuelles pour Fedora et la famille RHEL, soit comme flux de module qui remplace le PHP du système, soit comme Software Collection qui installe plusieurs versions en parallèle. Les corrections PHP2Shell 8.2.35, 8.3.36, 8.4.27 et 8.5.12 y ont été annoncées le 22 octobre 2026. Vérifiez chaque version installée individuellement et redémarrez chaque service correspondant.
Pourquoi tant de serveurs RHEL obtiennent PHP de Remi
Les distributions d'entreprise comme RHEL, AlmaLinux et Rocky Linux misent sur une longue stabilité. Elles livrent peu de branches PHP et les conservent pendant des années. Or de nombreuses applications exigent des versions plus récentes que celles proposées par la distribution. C'est là qu'intervient le dépôt de Remi Collet, mainteneur de paquets PHP de longue date dans l'environnement Fedora et RHEL.
Remi construit les versions de PHP peu après les versions officielles. Pour PHP2Shell, un article est paru dans le blog du dépôt le 22 octobre 2026 sur les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Il y cite les deux failles critiques CVE-2026-109618 et CVE-2026-109619 et recommande instamment la mise à jour. Les avis de sécurité de Red Hat ne valent pas pour ces paquets ; ce que Red Hat annonce pour ses propres paquets figure dans l'article RHEL, AlmaLinux et Rocky Linux : vérifier le correctif PHP.
Deux voies : flux de module ou Software Collection
Selon le blog de Remi, les builds pour Enterprise Linux à partir de la version 8 sont disponibles par deux voies. Celle qui est utilisée sur votre serveur détermine comment vous vérifiez et redémarrez.
| Voie | Dépôt | Effet | Service typique |
|---|---|---|---|
Flux de module, par exemple php:remi-8.3 |
remi-modular | remplace le PHP du système, une version par défaut | php-fpm |
Software Collection, par exemple php83 |
remi-safe | version supplémentaire en parallèle dans un chemin propre | un service propre par version, par exemple php83-php-fpm |
| Paquets de test et release candidates | remi-modular-test, remi-test | préversions | pas pour la production |
Les Software Collections se trouvent typiquement sous /opt/remi/phpXY, leur configuration sous /etc/opt/remi/phpXY. C'est pratique pour exploiter d'anciennes et de nouvelles applications sur un serveur. Mais c'est aussi la raison la plus fréquente pour laquelle une version est oubliée lors de la mise à jour.
Une remarque sur la ligne de commande : les Software Collections ne sont pas automatiquement disponibles sous la commande php. Selon la configuration, les tâches cron et scripts les appellent via une commande propre ou un chemin complet. Vérifiez donc aussi les crontabs et scripts de déploiement si vous voulez savoir quelle collection est utilisée pour quoi.
Vérifier le dépôt PHP Remi après PHP2Shell
Les commandes suivantes sont en lecture seule et montrent quels paquets Remi sont installés et à quel niveau.
# Sources de paquets actives : remi-modular ou remi-safe est-il intégré ?
dnf repolist
# Flux de module actif pour PHP
dnf module list --enabled php
# Paquets de base et Software Collections installées en parallèle
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Version de chaque collection installée
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
Pour les branches prises en charge, la situation est claire : si 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou plus récent y figure, la correction est incluse. Chez Remi, le numéro de version correspond en règle générale à la version amont, contrairement aux paquets de distribution qui conservent souvent leur ancien numéro.
Pour les collections plus anciennes comme php81, php80 ou php74, il n'existe pas de version cible officielle. Remi traite PHP 8.1 comme arrivé en fin de vie. Savoir si un paquet installé contient une correction contre PHP2Shell se clarifie dans le changelog, par exemple avec rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Sans résultat, traitez le paquet comme non clarifié. La manière de justifier proprement de tels résultats est décrite dans l'article Prouver les numéros CVE dans le changelog du paquet.
N'activez pas durablement des dépôts de test comme remi-test ou remi-modular-test sur des serveurs de production. Ils fournissent des release candidates destinées aux tests.
Mise à jour et redémarrage de chaque version
La mise à jour elle-même est le plus souvent sans histoire chez Remi : dnf upgrade récupère les nouveaux paquets pour le flux et les collections. La partie critique vient après. Chaque collection a son propre service FPM, et chacun doit être redémarré.
# Lister tous les services PHP-FPM, y compris ceux des collections
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Vérifier les heures de démarrage de tous les processus PHP
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Des heures de démarrage antérieures à la mise à jour signifient que ce service travaille encore avec l'ancien code. Pourquoi un rechargement ne suffit pas, la page Redémarrer PHP-FPM et tous les workers l'explique.
Remi et distribution : qui est responsable ?
Qui passe à Remi par un flux de module change de fournisseur pour PHP. Les avis de sécurité de Red Hat, AlmaLinux ou Rocky Linux ne se rapportent alors plus aux paquets PHP installés. Inversement, Remi ne signale pas de problèmes dans d'autres paquets du système. Vous devez donc garder les deux sources à l'œil.
La base de données des paquets montre d'où provient un paquet installé, par exemple avec rpm -qi php-fpm dans les champs fournisseur et empaqueteur. Comme il n'existe pas d'errata au sens de Red Hat pour les paquets Remi, le blog du dépôt convient comme voie de notification ; on peut s'y abonner par flux RSS. Pour PHP2Shell, l'avis y est paru un jour après les versions officielles.
Pour les entreprises, cette répartition n'est pas un obstacle, mais elle doit être documentée. Consignez quels serveurs obtiennent PHP de Remi, qui lit les avis et qui redémarre les services après une mise à jour. Sinon chacun compte sur l'autre.
Garder de l'ordre : moins de versions, moins de risque
Les Software Collections invitent à laisser simplement traîner d'anciennes versions. Après PHP2Shell, c'est un bon moment pour ranger :
- Pour chaque collection, déterminer quel site ou quelle tâche cron l'utilise.
- Désactiver les collections non utilisées et les supprimer après une période d'observation.
- Faire passer les applications sur d'anciennes collections à une branche prise en charge.
- Documenter les versions restantes avec leur usage et leur responsable.
Comment garder la vue d'ensemble sur de nombreuses versions parallèles, l'article Plusieurs versions de PHP sur un serveur le décrit.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons tous les flux et collections Remi sur vos serveurs et les associons aux sites et tâches cron.
- Nous vérifions le niveau PHP2Shell de chaque version via la version du paquet et le changelog.
- Nous installons les mises à jour, redémarrons chaque service et le prouvons par les heures de démarrage des processus dans le cadre du service de correctifs PHP.
- Nous retirons de façon contrôlée, après concertation, les collections qui ne sont plus nécessaires.
Questions fréquentes
Remi a-t-il fourni les versions PHP2Shell ?
Oui. Dans le blog du dépôt, les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12 ont été annoncées le 22 octobre 2026, avec la mention de deux failles critiques, CVE-2026-109618 et CVE-2026-109619, et la recommandation urgente de mise à jour.
Quelle est la différence entre flux de module et SCL chez Remi ?
Avec un flux de module, vous remplacez le PHP du système par une version Remi ; il n'y a alors qu'une version de PHP par défaut. Les Software Collections installent d'autres versions en parallèle dans des chemins propres, chacune avec son propre service.
PHP 8.1 reçoit-il encore des mises à jour de Remi ?
Remi traite PHP 8.1 comme arrivé en fin de vie, le projet PHP n'entretient plus la branche. Savoir si un paquet 8.1 précis contient une correction contre PHP2Shell se vérifie dans le changelog du paquet installé. Sans entrée, le niveau est considéré comme non clarifié.
Dois-je redémarrer chaque version de PHP après une mise à jour Remi ?
Oui. Chaque version installée en parallèle a son propre service FPM. Si seul le service de la version principale est redémarré, les autres continuent de tourner avec l'ancien code.