En bref : savoir si la mise à niveau de PHP ou le rétroportage est le bon choix dépend de la durée pendant laquelle votre système doit encore tourner et de la qualité de la preuve du rétroportage. Un rétroportage de sa propre distribution sur un système d'exploitation pris en charge est une voie à part entière. Les rétroportages de sources, les sources tierces et le support longue durée commercial pour PHP 8.1 et antérieur sont des ponts avec date d'expiration. À long terme, seul le passage à une version de PHP que le projet PHP prend encore officiellement en charge aide.
Pourquoi la question presse après PHP2Shell
Le 21 octobre 2026, le projet PHP a corrigé PHP2Shell dans les versions 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 versions officielles, seulement des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1. Selon la presse spécialisée, presque toutes les versions jusqu'à PHP 5.4 sont concernées.
De nombreux exploitants d'anciens systèmes se posent donc la même question : suffit-il de colmater la faille d'une manière ou d'une autre, ou la mise à niveau repoussée depuis des années doit-elle maintenant avoir lieu ? Ce que signifie concrètement une mise à niveau est décrit dans notre offre de migration de PHP 8.1 et antérieur. Ce qui s'applique sans mise à jour officielle figure dans PHP 8.1 et antérieur : ce qui s'applique maintenant. Cet article aide à arbitrer entre les deux.
Quels types de rétroportage existent
« Rétroportage » est un terme générique. Il désigne toujours qu'une correction d'une version plus récente est reprise dans une version plus ancienne. Mais qui le fait et avec quelle rigueur il est vérifié diffère fortement.
- Rétroportage de la distribution : Debian, Ubuntu, Red Hat et d'autres reprennent les corrections de sécurité dans les paquets PHP de leurs versions prises en charge. Le numéro de version reste alors souvent identique ; selon des rapports, Ubuntu 24.04 continue par exemple d'afficher 8.3.6 après la mise à jour. La correction se prouve par le journal des modifications du paquet et les avis de sécurité de la distribution.
- Source tierce : le dépôt sury.org d'Ondřej Surý a selon des rapports fourni des builds pour toutes les branches de 5.6 à 8.5. Ce n'est pas l'archive de sécurité de Debian. Les détails figurent dans Le dépôt sury.org.
- Rétroportage source du projet PHP : pour 7.4, 8.0 et 8.1, il existe des correctifs minimaux dans le code source, mais pas de versions prêtes à l'emploi. Celui qui les utilise doit compiler PHP lui-même, le tester et l'entretenir désormais lui-même.
- Support longue durée commercial : des prestataires comme TuxCare ELS ou Zend/HeroDevs proposent un entretien pour d'anciennes versions. Si et quand ils couvrent PHP2Shell doit être confirmé par écrit ; cela n'était pas prouvé dans les sources connues. Plus de détails dans Support longue durée pour d'anciennes versions de PHP.
Mise à niveau de PHP ou rétroportage : la comparaison
| Critère | Mise à niveau vers une version prise en charge | Rétroportage (selon le type) |
|---|---|---|
| Protection contre PHP2Shell | Oui, avec 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 | Oui, s'il est complet et prouvé |
| Futures mises à jour de sécurité | Officielles jusqu'à la fin du support de la version | Seulement tant que le prestataire concerné assure l'entretien |
| Preuve | Numéro de version plus redémarrage | Journal des modifications du paquet avec numéros CVE, confirmation du prestataire |
| Effort maintenant | Moyen à élevé, tests de compatibilité nécessaires | Faible avec la distribution, élevé en construction maison |
| Effort plus tard | Faible jusqu'au prochain saut de version | Croît à chaque nouvelle faille |
| Risque pour l'application | Incompatibilités avec l'ancien code et les extensions | Faible, le comportement reste largement identique |
| Adéquation comme solution durable | Oui | Seulement le rétroportage de la distribution dans le cadre d'un système d'exploitation pris en charge |
La ligne « Effort plus tard » est la plus importante. PHP2Shell ne sera pas la dernière faille. Chaque mois sur une version sans support officiel signifie que la prochaine alerte posera à nouveau la même question.
Quelle version cible pour la mise à niveau ?
Selon php.net, pour chaque branche de PHP : deux ans de support actif, puis deux ans de corrections de sécurité seulement. Il en résulte ces dates de fin de support de sécurité :
| Version | Support de sécurité jusqu'au |
|---|---|
| PHP 8.2 | 31/12/2026 |
| PHP 8.3 | 31/12/2027 |
| PHP 8.4 | 31/12/2028 |
| PHP 8.5 | 31/12/2029 |
Une mise à niveau vers 8.2 n'est donc plus qu'une courte étape intermédiaire. Celui qui migre de toute façon devrait viser une version à l'horizon plus lointain, pour autant que le CMS, la boutique et les extensions la prennent en charge. Vérifiez-le dans la configuration requise de l'éditeur, pas de mémoire. Le fonctionnement du cycle de publication est expliqué dans Versions de PHP et cycle de publication.
Quelle que soit la voie : après l'installation, tous les processus PHP doivent être redémarrés. Un rétroportage qui ne se trouve que sur le disque ne protège pas tant que d'anciens workers tournent en mémoire.
Un ordre pragmatique pour les anciens systèmes
- Immédiatement : appliquer les mesures transitoires selon php.net ou retirer temporairement le système du réseau si aucune correction prouvée n'est disponible.
- Dans les prochains jours : installer un rétroportage prouvé, si possible issu de sa propre distribution ou avec une confirmation écrite du prestataire.
- En parallèle : vérifier la compatibilité de l'application avec une version prise en charge et fixer un calendrier.
- Dans les prochains mois : mise à niveau vers la version cible, préparée sur une copie de test, avec un plan de repli.
L'idée décisive est de voir le rétroportage comme un pont, pas comme un objectif.
Quand vous n'avez pas besoin de prestataire pour cela
Si votre serveur tourne sur un Debian, Ubuntu ou RHEL pris en charge et que la distribution fournit le rétroportage, une mise à jour régulière avec redémarrage et un coup d'œil au journal des modifications suffisent. Un admin expérimenté y parvient seul. Une aide vaut la peine pour les constructions maison, les sources tierces, les très anciennes versions ou une application dont personne ne maîtrise plus la compatibilité.
Comment PHP SOS aide-t-il concrètement ?
- Nous vérifions quelles versions de PHP et sources de paquets tournent sur vos serveurs et si une correction prouvée existe.
- Nous installons les rétroportages, redémarrons et documentons la preuve par le journal des modifications.
- Nous testons votre application sur une copie contre la version cible et nommons les incompatibilités.
- Nous planifions et accompagnons la mise à niveau dans le cadre de la migration de PHP 8.1 et antérieur.
Conclusion
Le rétroportage de la distribution est une voie à part entière, tous les autres rétroportages sont des ponts. Celui qui est bloqué sur PHP 8.1 ou antérieur devrait utiliser le rétroportage pour gagner du temps pour la mise à niveau, pas pour la repousser encore.
Questions fréquentes
Un rétroportage est-il aussi sûr qu'une mise à niveau ?
Pour la faille précisément corrigée, un rétroportage peut être équivalent s'il est complet et prouvé. Mais il ne corrige que ce qui a été rétroporté. Une mise à niveau vers une version prise en charge apporte en plus toutes les futures mises à jour de sécurité officielles.
À quoi vois-je que mon rétroportage couvre PHP2Shell ?
Au journal des modifications du paquet : les numéros CVE CVE-2026-109618 et CVE-2026-109619 doivent y figurer. Sous Debian et Ubuntu, apt-get changelog le montre, dans la famille RHEL rpm -q --changelog. Le numéro de version seul n'est pas une preuve.
Pendant combien de temps PHP 8.2 reçoit-il encore des mises à jour de sécurité ?
Selon php.net, le support de sécurité de PHP 8.2 s'achève le 31/12/2026. Celui qui met à jour vers 8.2 aujourd'hui devrait donc planifier tout de suite l'étape suivante.
Le support longue durée commercial pour d'anciennes versions de PHP vaut-il la peine ?
Il peut être un pont si une mise à niveau est impossible à court terme. Faites-vous confirmer par écrit si et à partir de quand PHP2Shell est couverte. Dans les sources connues jusqu'ici, ce n'était pas prouvé.