En bref : pour PHP 8.1 et antérieur, le projet PHP ne fournit plus de mises à jour officielles. Le support à long terme, aussi appelé support étendu, vient de distributions Linux, de dépôts de fournisseurs tiers ou de services commerciaux comme TuxCare ELS ou Zend/HeroDevs. Il peut combler le temps jusqu'à la mise à niveau si le fournisseur confirme par écrit la couverture de votre version. Mais il ne remplace ni la mise à niveau ni l'entretien du CMS et du code propre.
Pourquoi la question se pose justement maintenant
Le 21 octobre 2026, les corrections de PHP2Shell ne sont parues que pour les branches prises en charge 8.5, 8.4, 8.3 et 8.2. Pour 7.4, 8.0 et 8.1, le projet PHP n'a fourni que des rétroportages minimaux du code source, c'est-à-dire des corrections dans le code source sans version prête à l'emploi. Selon la presse spécialisée, presque toutes les versions jusqu'à PHP 5.4 sont concernées.
L'ampleur du parc, une analyse de CybelAngel la montre : environ 2,24 millions d'hôtes PHP accessibles depuis Internet, dont 59 % selon CybelAngel sur des versions sans correctif officiel à venir. Pour de nombreuses entreprises, la question du support à long terme n'est donc plus théorique. Et elle grandit : PHP 8.2 atteint la fin du support le 31/12/2026.
Ce dont un ancien système a besoin tout de suite est décrit dans PHP 8.1 et antérieur : ce qui s'applique maintenant. Cet article aide pour la question à moyen terme : quelle voie tient jusqu'à la mise à niveau, et que doit-elle fournir ?
Support étendu PHP : les voies en un coup d'œil
| Voie | Ce qu'elle apporte | Limites |
|---|---|---|
| Maintenance à long terme de la distribution | Rétroportages dans les paquets, tant que la version de la distribution est prise en charge | uniquement pour la version de PHP livrée par cette distribution |
| Dépôt de fournisseur tiers | par ex. sury.org, selon des rapports avec des builds de 5.6 à 8.5 | pas l'archive de sécurité de la distribution, question de confiance |
| Support à long terme commercial | paquets corrigés pour des versions arrivées en fin de vie, par ex. TuxCare ELS, Zend/HeroDevs | faire confirmer la couverture par version et par CVE, coûts récurrents |
| Construction maison à partir de rétroportages du code source | builds propres à partir des corrections du projet PHP | coûteux, à refaire à chaque faille |
À propos des offres commerciales : TuxCare décrit sur son site des corrections de CVE pour des versions arrivées en fin de vie, de PHP 5.2 à 8.x, livrées via la gestion de paquets existante, pour Windows et les distributions Linux courantes. Une mention sur la même page signale des corrections PHP2Shell pour des versions de PHP arrivées en fin de vie. Selon la documentation de cPanel, TuxCare promet pour les failles à partir de CVSS 7 des corrections dans les 14 jours suivant la publication ; sur les serveurs cPanel, les domaines sont pour cela basculés d'ea-php vers alt-php. Pour Zend/HeroDevs, nous ne disposions d'aucune déclaration sur la couverture de PHP2Shell.
Des indications sur la voie du fournisseur tiers figurent dans l'article Le dépôt sury.org.
Ce qu'il vous faut par écrit du fournisseur
Le support à long terme est une prestation de confiance. Vous achetez la promesse que les futures failles seront fermées. Faites-vous donc répondre par écrit, avant la décision :
- Quelles versions de PHP, quels systèmes d'exploitation et quels noms de paquets sont exactement couverts ?
- CVE-2026-109618 et CVE-2026-109619 sont-elles fermées pour votre version, avec quel état de paquet et depuis quand ?
- Comment sont traitées CVE-2026-115560 et les futures notifications de suite ?
- Les extensions que vous utilisez sont-elles incluses, ou seulement le cœur de PHP ?
- Comment vérifiez-vous vous-même qu'un correctif est appliqué, par exemple via le changelog du paquet ?
- Combien de temps la couverture de votre version dure-t-elle, et comment une fin est-elle annoncée ?
- Que deviennent les paquets installés quand le contrat prend fin ?
Des réponses qui ne renvoient qu'en général à « toutes les failles de sécurité » ne suffisent pas. Pour les auditeurs, les assureurs et votre propre documentation, c'est le rattachement concret de la version, du paquet et de la CVE qui compte.
Les limites : ce que le support à long terme ne résout pas
Le support à long terme maintient l'environnement d'exécution PHP à jour. Tout ce qui est au-dessus reste votre tâche. Et c'est précisément là que se trouve le plus souvent le plus gros problème des anciens systèmes.
- L'application continue de vieillir : un CMS ou une boutique qui exige PHP 8.1 n'est souvent lui-même plus en service dans la version actuelle.
- Bibliothèques et extensions : les paquets Composer et les extensions ne reçoivent souvent plus de mises à jour pour d'anciennes versions de PHP.
- Pas un substitut au redémarrage et au contrôle : même les paquets corrigés ne prennent effet qu'après le redémarrage de tous les processus PHP, et ils ne suppriment aucun logiciel malveillant injecté auparavant.
- La dette technique grandit : plus le pont est long, plus le saut de la migration ultérieure est grand.
- Les preuves deviennent plus coûteuses : les auditeurs, clients et assureurs s'enquièrent de plus en plus de l'état des correctifs. Une version de PHP arrivée en fin de vie avec des correctifs de fournisseur tiers peut se démontrer, mais exige plus d'explications qu'une version prise en charge.
Quand le support à long terme est-il malgré tout le bon choix ? Trois situations sont typiques : une application métier dont l'éditeur n'autorise pas encore de versions de PHP plus récentes ; un ancien système dont le remplacement est déjà décidé et qui ne doit plus tourner que quelques mois ; ou une grande base de code dont la migration doit être soigneusement planifiée. Dans les trois cas, le support à long terme achète du temps pour une solution ordonnée. Il n'est pas une solution pour des systèmes dont plus personne ne veut s'occuper.
Si un ancien système a tourné sans protection sur Internet entre le 17 et le 21 octobre, clarifiez d'abord s'il est compromis. Le support à long terme pour un système déjà infecté ne protège de rien.
Un plan de sortie en fait partie
Le support à long terme est une bonne décision quand il se termine à une date. Fixez jusqu'à quand l'application doit tourner sur une version prise en charge, qui est responsable de la migration et quels jalons s'appliquent. La durée pendant laquelle les branches de PHP sont officiellement entretenues est expliquée dans Le cycle de publication de PHP.
Savoir si une mise à niveau ou un rétroportage vaut mieux pour votre système, l'article Mise à niveau de PHP ou rétroportage ? le met en balance.
Comment PHP SOS aide-t-il concrètement ?
- Évaluer la situation : nous vérifions la version, la source des paquets et l'état des correctifs de vos anciens systèmes, et s'ils montrent des traces d'une attaque.
- Examiner les offres : nous confrontons les engagements écrits d'un fournisseur de support à long terme avec votre parc réel.
- Sécuriser le pont : jusqu'à la mise à niveau, nous appliquons les mesures transitoires de php.net et restreignons l'accessibilité.
- Mettre en œuvre la sortie : avec la migration de PHP 8.1 et antérieur, nous planifions et testons le passage à une version prise en charge.
Questions fréquentes
Qu'est-ce que le support étendu PHP ?
On désigne ainsi des offres qui continuent à fournir des corrections de sécurité aux versions de PHP après la fin officielle du support. Il peut s'agir de distributions Linux, de dépôts de fournisseurs tiers ou de services commerciaux comme TuxCare ELS ou Zend/HeroDevs.
Le support à long terme commercial couvre-t-il PHP2Shell ?
TuxCare indique sur son site avoir fourni des corrections PHP2Shell pour des versions de PHP arrivées en fin de vie. Pour votre version, votre paquet et votre système d'exploitation précis, faites-vous néanmoins confirmer cela par écrit et vérifiez-le dans le changelog.
Le support à long terme est-il une alternative à la mise à niveau ?
Seulement temporairement. Il maintient l'environnement d'exécution PHP corrigé, mais pas le CMS, les extensions et le code propre, qui sont souvent eux aussi obsolètes. Une date de sortie doit donc faire partie de toute décision en faveur du support à long terme.
Que se passe-t-il à la fin du contrat de support à long terme ?
Selon la documentation de cPanel sur TuxCare, les paquets installés continuent de fonctionner, mais ne reçoivent plus de nouvelles mises à jour de sécurité. Le système se retrouve alors dans la même situation qu'avant, simplement plus tard.
Le sujet concerne-t-il aussi PHP 8.2 ?
Oui, bientôt. PHP 8.2 reçoit encore avec 8.2.35 la correction de PHP2Shell, mais atteint la fin du support le 31/12/2026. Qui exploite 8.2 devrait planifier le changement dès maintenant.