Assistance étendue pour PHP : couverture et principaux prestataires en 2026

Principaux enseignements

• Le support étendu de PHP assure la rétroportabilité des correctifs de sécurité pour les versions de PHP dont la fin de vie (EOL) est dépassée, ce qui vous permet de garantir la sécurité de vos applications en production sans avoir à procéder à une migration forcée.
• Le support étendu ne modifie ni votre version de PHP ni le comportement de votre application. Il corrige les failles de sécurité connues tout en vous permettant de procéder à la migration selon votre propre calendrier.
• À compter d'août 2026, PHP 8.1 et toutes les versions antérieures seront en fin de vie (EOL) et ne bénéficieront plus d'aucun correctif de la communauté. PHP 8.2, 8.3, 8.4 et 8.5 sont toujours pris en charge, mais chacune de ces versions a une date d'expiration fixe.
• L'utilisation de versions de PHP en fin de vie (EOL) sans support étendu entraîne l'absence de correctifs pour les vulnérabilités CVE, un risque accru en matière d'audit et de conformité, ainsi qu'une surface d'attaque de plus en plus étendue.

Si vous utilisez PHP en environnement de production, la fin de vie vous place dans une situation familière et délicate : mettre à jour une application qui n’a pas été modifiée depuis des années, ou continuer à utiliser un moteur d’exécution qui ne bénéficie plus de correctifs de sécurité. Aucune de ces options n’est idéale.

La troisième option est le support étendu de PHP.

Cet article explique ce que couvre réellement le support étendu (et ce qu'il ne couvre pas), les risques liés à la conformité et aux vulnérabilités CVE en cas de non-souscription, les versions de PHP qui en ont besoin à l'heure actuelle, comment évaluer cette option par rapport à une mise à niveau, ainsi que les prestataires à connaître en 2026.

Qu'est-ce que le support étendu PHP ?

Le support étendu de PHP est un service proposé par un fournisseur qui permet de continuer à fournir des correctifs de sécurité pour une version de PHP après que le projet PHP lui-même a cessé ses activités. Lorsqu’une version de PHP arrive en fin de vie, le projet PHP tire un trait dessus : plus de correctifs CVE, plus de correctifs, plus rien.

La prise en charge étendue permet de relancer ce dossier. Un fournisseur surveille les vulnérabilités récemment révélées et intègre les correctifs dans l'environnement d'exécution en fin de vie, ce qui permet à votre application de continuer à fonctionner sur un environnement corrigé pendant que vous planifiez la migration selon votre propre calendrier, et non selon celui d'un tiers.

Fonctionnement du cycle de vie des versions de PHP

Les versions de PHP suivent désormais un cycle de vie de quatre ans : deux ans de support actif, puis deux ans de support de sécurité. Ce nouveau cycle a été instauré en mars 2024 dans le cadre d'une modification du cycle de publication de PHP et s'applique à PHP 8.1 et aux versions ultérieures. Les branches plus anciennes, telles que PHP 7.4 et 8.0, conservent l'ancien cycle de vie de trois ans, comprenant deux ans de support actif et un an de support de sécurité.

Phase du cycle de vie	La durée	Ce que vous obtenez
Soutien actif	Les deux premières années	Corrections de bogues, optimisations des performances, correctifs de sécurité
Assistance en matière de sécurité	Les deux prochaines années	Uniquement les correctifs de sécurité critiques
Fin de vie	Après 4 ans	Rien. Aucun correctif d'aucune sorte.

Voici où se situe chaque version de PHP :

Version de PHP	Publié	Fin de vie	Situation (août 2026)
7.4	Novembre 2019	28 novembre 2022	Fin de vie (EOL) – pas de correctifs communautaires
8.0	novembre 2020	26 novembre 2023	Fin de vie (EOL) – pas de correctifs communautaires
8.1	novembre 2021	31 décembre 2025	Fin de vie (EOL) – pas de correctifs communautaires
8.2	Décembre 2022	31 décembre 2026	Uniquement pour la sécurité (fin de vie : fin 2026)
8.3	Novembre 2023	31 décembre 2027	Réservé à la sécurité
8.4	novembre 2024	31 décembre 2028	Assistance active jusqu'au 31 décembre 2026, puis assistance limitée à la sécurité
8.5	novembre 2025	31 décembre 2029	Soutien actif

Le saviez-vous ? Le projet PHP aligne désormais toutes les dates de fin de vie (EOL) sur le 31 décembre de l'année concernée. PHP 8.1 a été la première version à bénéficier de ce cycle prolongé, sa sa fin de vie (EOL) a été repoussée de novembre 2024 au 31 décembre 2025.

Ce qu'offre réellement le support étendu de PHP

Le support étendu est volontairement limité. Son objectif est d'assurer la sécurité d'une version de PHP arrivée en fin de vie (EOL), et non de la moderniser, de la refactoriser ou d'y ajouter des fonctionnalités. Il fournit les correctifs de sécurité que la communauté a cessé de publier, sous une forme que vous pouvez déployer sans perturber le fonctionnement de l'application qui dépend précisément de cet environnement d'exécution.

 

Retour à la réalité : La prolongation de la prise en charge n'est pas un passe-droit pour ne jamais effectuer de mise à niveau. Elle vous donne simplement le temps de migrer sans urgence. Considérez-la comme une piste d'atterrissage, et non comme une destination.

Correctifs de sécurité rétroportés

Le service principal est le « backporting ». Lorsqu'une nouvelle vulnérabilité CVE est signalée sur une branche PHP encore prise en charge, le fournisseur vérifie si la version en fin de vie est concernée, puis intègre le correctif dans votre ancien environnement d'exécution sans en modifier le comportement. Vous continuez à utiliser PHP 7.4 ou 8.1, mais la vulnérabilité est corrigée.

Tests de compatibilité et déploiement sans interruption

Un correctif rétroporté doit tout de même préserver la stabilité de l'application. Une prise en charge étendue de PHP de qualité inclut des tests de régression par rapport à la version en fin de vie, afin que le correctif n'entraîne pas de changements de comportement. Selon le fournisseur et la plateforme, les correctifs sont fournis sous forme de paquets natifs (RPM ou DEB sous Linux) qui s'installent via votre gestionnaire de paquets existant, avec des programmes d'installation équivalents pour Windows.

Version et prise en charge des systèmes d'exploitation

Chaque fournisseur prend en charge un ensemble spécifique de versions de PHP sur un ensemble spécifique de systèmes d'exploitation. Par exemple, le service Endless Lifecycle Support (ELS) de TuxCare pour PHP couvre les versions de PHP allant de la 5.2 à la 8.4, en appliquant les correctifs de sécurité ELS à chaque branche dès qu’elle atteint sa fin de vie (actuellement de la 5.2 à la 8.1), sur Windows et les principales distributions Linux, notamment AlmaLinux, CentOS, Ubuntu, Debian et Oracle Linux. Si vous êtes bloqué sur un environnement d’exécution en fin de vie (EOL) qui ne se migre pas sans heurts, ce type de correctifs pris en charge par le fournisseur est l’un des rares moyens de combler la faille CVE sans avoir à remanier immédiatement l’application pour un environnement d’exécution plus récent.

Remarque : La mise à niveau de PHP 5.x vers PHP 8.x peut nécessiter des modifications importantes du code, en particulier pour les applications qui s'appuient sur des fonctionnalités du langage supprimées, des API obsolètes ou des frameworks dépassés.

Risques liés à la sécurité et à la conformité liés à l'utilisation d'une version de PHP arrivée en fin de vie (EOL) sans support étendu

Le site se charge, le processus de paiement fonctionne, les journaux semblent en ordre. Mais le risque s'accumule insidieusement à mesure que de nouvelles vulnérabilités (CVE) sont identifiées dans votre version et ne sont jamais corrigées. « Ça fonctionne encore » : voilà le piège.

Un environnement d'exécution en fin de vie (EOL) qui fonctionne correctement aujourd'hui est également celui qui présente la plus longue liste de vulnérabilités non corrigées et documentées publiquement, ce qui correspond exactement à ce que recherchent les pirates.

 

Vulnérabilités CVE non corrigées et exploitation active

Une fois qu'une version est en fin de vie (EOL), les vulnérabilités récemment découvertes qui l'affectent ne font plus l'objet de correctifs de la part du projet PHP, et ce pour une durée indéterminée. Les pirates peuvent identifier les versions qui ne bénéficient plus de correctifs, et les exploits rendus publics continuent de fonctionner sur les systèmes qui n'ont jamais reçu de correctif rétroporté.

Le rapport DBIR 2026 de Verizon a révélé que l’exploitation des vulnérabilités est désormais le principal vecteur d’accès initial aux violations de données, représentant 31 % des cas, contre 20 % dans le rapport de l’année précédente. C’est la première fois en 19 ans d’existence du rapport que l’exploitation des vulnérabilités occupe la première place, devant l’usurpation d’identifiants et le phishing. Les CVE réels liés à PHP illustrent clairement ce phénomène : consultez l’article consacré à une vulnérabilité de PHP 7 post-fin de vie PHP 7 (CVE-2023-0568), ainsi que le CVE-2024-4577, une faille d’injection d’argument CGI notée 9,8 selon le CVSS, qui a été intégrée au catalogue des vulnérabilités connues pour être exploitées de la CISA et a durement touché les déploiements PHP sous Windows. Cette tendance générale est abordée dans cet aperçu des vulnérabilités PHP. En l’absence de source permettant un portage en arrière, la mise à niveau est généralement le seul moyen fiable d’éliminer la faille sous-jacente.

Manquement aux obligations de conformité

Les cadres de sécurité et de conformité exigent généralement des organisations qu'elles identifient les vulnérabilités, gèrent les risques et appliquent les mises à jour de sécurité dans un délai défini. La norme PCI DSS définit des exigences explicites en matière d'application des correctifs et de gestion des vulnérabilités, tandis que la loi HIPAA, SOC 2et FedRAMP reposent sur les mêmes principes grâce à l’analyse des risques et à l’évaluation des contrôles. L’utilisation de logiciels qui ne bénéficient plus de correctifs en amont rend ces obligations plus difficiles à respecter, à moins de disposer d’une source documentée de correctifs rétroportés et des preuves permettant de le démontrer.

Selon le rapport 2026 d’IBM sur le coût des fuites de données, le coût moyen mondial d’une violation de données a augmenté de 12 % par rapport à l’année précédente pour atteindre le chiffre record de 4,99 millions de dollars. Une assistance étendue peut fournir les historiques des correctifs et les calendriers de remédiation qui démontrent une processus cohérent d’évaluation et un processus de correction cohérents. Les environnements réglementés s’accompagnent d’obligations supplémentaires, notamment la la conformité FIPS pour les modules cryptographiques validés, par exemple –, mais en ce qui concerne spécifiquement la question des correctifs, il est bien plus facile de présenter un historique irréprochable lorsque les correctifs existent réellement.

Chaîne d'approvisionnement et exposition aux risques de dépendance

PHP fonctionne rarement de manière isolée. Votre application utilise des paquets Composer, des extensions et un système d’exploitation sous-jacent ; une vulnérabilité dans n’importe quelle de ces couches devient alors votre problème. Un environnement d’exécution PHP en fin de vie coexiste souvent avec un système d’exploitation en fin de vie et des dépendances obsolètes, ce qui multiplie la surface d'attaque.

Quelles versions de PHP bénéficient actuellement d'un support prolongé ?

Si vous utilisez PHP 8.1 ou une version antérieure et que vous ne pouvez pas effectuer de mise à jour dans l'immédiat, vous aurez besoin d'une source fiable de correctifs de sécurité rétroportés. À partir de 2026, ces versions ne bénéficieront plus d'aucun correctif de sécurité fourni par la communauté ; par conséquent, les vulnérabilités récemment découvertes qui les affectent ne seront pas corrigées par le projet PHP.

PHP 7.4 est le cas le plus urgent. Cette version a atteint sa fin de vie (EOL) en novembre 2022, et n’a donc plus bénéficié de correctifs de la communauté depuis près de quatre ans. Elle est toujours utilisée dans un grand nombre d’environnements de production, car sa migration peut impliquer un travail considérable en matière de dépendances, de compatibilité et de tests. Il en va de même pour PHP 8.0, qui a atteint sa fin de vie fin 2023, et PHP 8.1 a rejoint cette liste fin 2025.

Les versions PHP 8.2 et 8.3 sont en mode « sécurité uniquement » : elles continuent de bénéficier de correctifs, mais le compte à rebours a commencé. PHP 8.2 arrivera en fin de vie le 31 décembre 2026, et PHP 8.3 suivra un an plus tard. Notez la date de fin de vie de PHP 8.2 dans votre agenda : après le 31 décembre 2026, plus aucun correctif de sécurité ne sera publié par le projet PHP pour cette branche. Pour une analyse complète des risques et des options qui s'offrent à vous, consultez le guide sur la fin de vie de PHP 8.2 traite le sujet en détail.

PHP 8.4 et 8.5 sont les deux branches bénéficiant actuellement d'un support actif, et la version 8.4 passera en mode « sécurité uniquement » à la fin de l'année 2026. Le support étendu s'adresse aux équipes qui ne peuvent pas abandonner les versions 7.4, 8.0 ou 8.1 dans les délais exigés par leurs auditeurs ou leurs équipes chargées de la gestion des risques.

Support étendu PHP ou mise à niveau : comment faire son choix ?

La mise à niveau est la bonne solution à long terme. La prolongation de la prise en charge est la bonne solution à court terme lorsque procéder à une mise à niveau dès maintenant serait imprudent. La décision dépend de l'ampleur du travail de migration qui vous sépare d'une version prise en charge, ainsi que du niveau de risque que vous encourez entre-temps.

Une application bien entretenue peut passer de PHP 8.1 à une version actuellement prise en charge avec un travail limité sur les dépendances et les éléments obsolètes, même si l'effort nécessaire dépend de ses frameworks, de ses extensions et de la couverture des tests. Migrer une application héritée de PHP 7.4, comportant 200 000 lignes de code inchangées et des dépendances abandonnées, vers PHP 8.4 est un véritable projet, et non une simple après-midi de travail. Le coût lié à une sous-estimation de cet écart est bien réel.

Sur le terrain : Une mise à niveau ponctuelle ne résout pas définitivement les risques liés au cycle de vie. Les équipes qui sont passées de la version 7.4 à la version 8.0 il y a quelques années, qui ont considéré que le travail était terminé et qui n’ont jamais planifié la prochaine étape, se retrouvent aujourd’hui sur une autre branche en fin de vie (EOL). « Nous avons déjà effectué une mise à niveau » : voilà comment on se retrouve deux fois en fin de vie.

Sers-t'en pour prendre ta décision :

Scénario	Approche recommandée
Version 8.1 : dépendances modernes, base de code réduite	Passez dès maintenant à une version bénéficiant d'un support actif, de préférence PHP 8.4 ou 8.5
Version 7.4 ou 8.0, application héritée de grande envergure, aucune couverture de test	Prolongation de l'assistance, puis migration par étapes
Date limite d'audit stricte, migration non terminée	Assistance prolongée pour garantir la conformité pendant la migration
Application tierce que le fournisseur n'a pas mise à jour	Prolongation de l'assistance jusqu'à ce que le fournisseur propose un correctif

 

Les 3 meilleurs prestataires de support étendu pour PHP

Une poignée de fournisseurs proposent des correctifs de sécurité rétrocompatibles pour les versions de PHP en fin de vie. Ils se distinguent par les versions couvertes, le mode de distribution des correctifs et la documentation de conformité qu’ils vous fournissent. En voici trois qui méritent d’être comparés. Les listes de couverture ci-dessous reflètent les informations publiées par chaque fournisseur en août 2026 ; veuillez vérifier la portée actuelle auprès du fournisseur avant d’acheter.

de TuxCare

Prise en charge à cycle de vie illimité de PHP par TuxCare couvre les versions de PHP allant de la 5.2 à la 8.4 à partir d’un référentiel unique, avec l’application de correctifs de sécurité ELS à chaque branche dès qu’elle atteint sa fin de vie (EOL) – actuellement de la 5.2 à la 8.1, les versions 8.2, 8.3 et 8.4 devant suivre à mesure que leurs dates de fin de vie arriveront. Les paquets sont compilés par le fournisseur et dotés de correctifs de sécurité pour Windows et les principales distributions Linux ; ils sont soumis à des tests de régression avant leur publication et s'installent via votre gestionnaire de paquets existant, sans nécessiter de changement d'environnement d'exécution ni de recompilation de votre application.

Pour les équipes qui gèrent plusieurs sites PHP via cPanel, la solution PHP ELS de TuxCare s'intègre à PHP Selector dans les environnements cPanel pris en charge, ce qui vous permet de définir les versions PHP site par site depuis l'interface d'administration, sans avoir à passer par la ligne de commande.

Zend par Perforce

Zend assure depuis des années le support commercial de PHP et propose des environnements d'exécution avec support à long terme pour les versions en fin de vie (EOL), avec l'appui d'un éditeur fort d'une longue expérience au sein de l'écosystème PHP. La couverture est ciblée : Zend propose actuellement les versions PHP 7.2, 7.3, 7.4 et 8.1 dans le cadre de son offre PHP LTS. Il s'agit d'une option fiable pour les équipes ayant déjà adopté les outils Zend ou Laminas.

HeroDevs

HeroDevs assure un support à long terme pour PHP grâce à un partenariat avec Zend by Perforce, en associant les environnements d'exécution ZendPHP à son propre abonnement « Never-Ending Support », à des accords de niveau de service (SLA) et à une documentation de conformité. La couverture s'étend aux versions PHP 7.2, 7.3, 7.4, 8.0, 8.1 et 8.2, fournies sous forme de paquets natifs pour les principales distributions Linux et Windows.

Appliquez les correctifs de fin de vie (EOL) de PHP, évitez les risques de sécurité et assurez votre conformité

La fin de vie (EOL) de PHP n'est pas annoncée. Le système continue de traiter le trafic jusqu'à ce qu'un pirate exploite une vulnérabilité documentée publiquement qui n'a jamais fait l'objet d'un correctif dans votre branche. La prise en charge prolongée de PHP comble cette lacune : vous conservez l'environnement d'exécution dont dépend votre application, les vulnérabilités concernées bénéficient de correctifs rétroportés, et vous effectuez la migration lorsque cela peut se faire en toute sécurité, plutôt que lorsque vous y êtes contraint.

Si vous utilisez PHP 7.4, 8.0 ou 8.1 et qu’une mise à niveau immédiate n’est pas envisageable, sécurisez l’environnement d’exécution existant à l’aide de correctifs rétroportés pendant que vous planifiez la migration. Le service Endless Lifecycle Support (ELS) de TuxCare couvre actuellement toutes les branches en fin de vie (EOL), de la version 5.2 à la version 8.1, et s'engage à étendre cette couverture aux versions 8.2, 8.3 et 8.4 à mesure que chacune d'entre elles atteindra sa date de fin de vie.

FAQ