En bref : la fin de vie de PHP signifie que le projet PHP ne fournit plus de mises à jour de sécurité pour cette branche. PHP2Shell en montre clairement les conséquences, car il n'existe aucun correctif officiel pour PHP 8.1 et antérieur, et PHP 8.2 s'achève le 31 décembre 2026. Qui tourne aujourd'hui sur une ancienne branche devrait planifier le passage dès maintenant, et non lors de la prochaine urgence.
Ce que signifie la fin de vie de PHP
Chaque branche de PHP, par exemple 8.2 ou 8.3, n'est maintenue par le projet PHP que pendant une durée limitée. D'abord viennent des corrections de bogues et des mises à jour de sécurité, puis seulement des mises à jour de sécurité. Ensuite, le support s'arrête complètement. php.net publie les périodes actuelles sur sa page des versions prises en charge.
Après la fin du support, le logiciel continue certes de fonctionner. Mais si une nouvelle faille est connue, le projet PHP ne fournit plus de correctif. Le serveur reste vulnérable jusqu'à ce que quelqu'un d'autre apporte des corrections ou que vous passiez à une branche prise en charge.
Pour la direction et la responsabilité informatique, c'est avant tout une question de planification. Une migration peut se préparer sereinement. Sous la pression du temps après une alerte critique, elle devient coûteuse et risquée.
Ce que PHP2Shell montre sur les versions obsolètes
Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques, CVE-2026-109618 et CVE-2026-109619. Toutes deux permettent l'exécution de code malveillant à distance sans authentification et sont évaluées à 9.2 selon CVSS v4.0. Selon la presse spécialisée, presque toutes les versions jusqu'à PHP 5.4 sont concernées.
| Branche | Statut selon le projet PHP | Correctif PHP2Shell |
|---|---|---|
| PHP 8.5 | prise en charge | 8.5.12 |
| PHP 8.4 | prise en charge | 8.4.27 |
| PHP 8.3 | prise en charge | 8.3.36 |
| PHP 8.2 | prise en charge jusqu'au 31 décembre 2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | aucune mise à jour officielle | seulement des backports minimaux du code source |
| PHP 7.3 et antérieur | aucune mise à jour officielle | aucun backport du projet PHP |
Pour 8.1 et antérieur, il ne reste donc que la voie des backports de distributions ou d'hébergeurs. Ceux-ci affichent souvent toujours l'ancien numéro de version alors qu'ils sont corrigés. Seul le fournisseur peut confirmer de façon fiable qu'un backport est installé. Les détails figurent sur la page PHP 8.1 et antérieur : ce qui s'applique maintenant, la vue d'ensemble complète sous Quelles versions de PHP sont concernées ?.
PHP 8.2 a encore reçu le correctif PHP2Shell, mais atteint la fin du support le 31 décembre 2026. Qui migre maintenant depuis 8.1 devrait viser directement une branche plus récente.
Les risques des versions de PHP obsolètes en un coup d'œil
Le risque de sécurité est au premier plan, mais il n'est pas le seul. Les versions de PHP obsolètes entraînent d'autres problèmes :
- Aucun correctif pour les nouvelles failles : chaque faille future reste ouverte ou dépend de backports de tiers.
- Bibliothèques obsolètes : les paquets actuels exigent des branches PHP plus récentes. Les correctifs de sécurité dans les bibliothèques ne peuvent alors plus être installés, comme le montre le guide composer audit.
- Dépendance vis-à-vis du fournisseur : les hébergeurs facturent parfois des suppléments pour les anciennes versions ou arrêtent l'exploitation. Le délai est alors fixé par le fournisseur, pas par vous.
- Problèmes de justification : face aux assureurs, aux donneurs d'ordre ou lors d'audits, une version non prise en charge est difficile à justifier. Les conséquences contractuelles ou juridiques éventuelles sont à clarifier avec l'assureur ou un avocat.
- Effort de migration croissant : plus l'écart avec la version actuelle est grand, plus il faut adapter de code.
Sont particulièrement souvent concernés les anciens systèmes de boutique et les développements sur mesure laissés longtemps sans intervention. Un exemple typique est Shopware 5, qui tourne souvent encore sur d'anciennes branches de PHP.
État des lieux : quelles versions de PHP tournent chez vous ?
La première étape est une image complète. Sur de nombreux serveurs, plusieurs versions de PHP tournent en parallèle, par exemple pour un ancien site que plus personne n'a en tête. Ces commandes ne font que lire :
# Version de la ligne de commande
php -v
# Versions installées sous Debian/Ubuntu
ls /etc/php/
# Versions installées dans Plesk
ls /opt/plesk/php/ 2>/dev/null
# Processus PHP en cours avec la version dans le nom
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
Consignez pour chaque site : domaine, version de PHP, mode d'exécution, CMS avec version, personne responsable. Cette liste est en même temps la base de votre plan d'urgence. Sur un hébergement mutualisé, vous trouvez généralement les versions dans l'espace client de l'hébergeur.
Planifier la migration : comment procéder
Une migration vers une branche prise en charge suit en général les mêmes étapes, quel que soit le système :
- Définir la cible : choisir une branche qui, selon php.net, reste prise en charge le plus longtemps possible et qui, selon la configuration requise de l'éditeur, convient à votre CMS.
- Vérifier la compatibilité : CMS, extensions, thèmes et code propre. Les informations figurent sur la page officielle de l'éditeur concerné.
- Mettre en place la préproduction : une copie du site avec la nouvelle version de PHP, base de données comprise.
- Tester : tous les processus importants, du formulaire de contact au processus de commande, ainsi que le journal d'erreurs à la recherche d'avertissements.
- Basculer et redémarrer : changer de version, redémarrer tous les processus PHP, vérifier le fonctionnement et le journal d'erreurs.
Planifiez de façon réaliste. Un petit site avec un CMS à jour est souvent rapidement basculé. Une boutique développée au fil des années, avec de nombreuses extensions et du code propre, peut en revanche exiger une adaptation du code et des extensions, jusqu'au passage à une nouvelle version majeure du système de boutique. Clarifiez tôt qui décide en interne, de quel budget vous disposez et s'il faut associer des développeurs externes.
Définissez en outre comment vous suivrez à l'avenir les fins de support. Une date fixe dans l'année, à laquelle vous comparez la liste de vos sites avec les indications de php.net, évite que le même goulot d'étranglement ne réapparaisse dans deux ans.
D'ici la bascule, utilisez les mesures transitoires de php.net, par exemple session.upload_progress.enabled=0 dans la configuration du serveur. Elles ne constituent pas une protection complète, mais réduisent le risque.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons toutes les versions de PHP, tous les modes d'exécution et toutes les applications sur vos serveurs.
- Nous évaluons le risque par site et définissons avec vous l'ordre et la version cible.
- Nous mettons en œuvre des mesures transitoires jusqu'à la migration et obtenons auprès du fournisseur des confirmations sur les backports.
- Nous migrons via un environnement de préproduction et documentons le test et la bascule.
Le déroulement est décrit par la prestation PHP 8.1 et antérieur : migration vers une version prise en charge.
Questions fréquentes
Quand le support de PHP 8.2 prend-il fin ?
PHP 8.2 atteint le 31 décembre 2026 la fin du support par le projet PHP. La branche a encore reçu le correctif PHP2Shell avec la version 8.2.35 ; pour des failles ultérieures, aucune mise à jour officielle n'est ensuite à attendre.
PHP 8.1 reçoit-il un correctif contre PHP2Shell ?
Le projet PHP ne fournit plus de mises à jour officielles pour 8.1 et antérieur. Il n'existe que des backports minimaux du code source pour 7.4, 8.0 et 8.1. Vous devez demander à votre fournisseur si et comment votre hébergeur ou votre distribution les installe.
Une ancienne version de PHP avec des backports de l'hébergeur est-elle sûre ?
Les backports peuvent combler des failles précises, mais ne remplacent pas une branche prise en charge. Ils dépendent du fournisseur, arrivent souvent plus tard et ne couvrent pas toutes les failles. Ils ne conviennent donc pas comme solution durable.
Comment savoir si mon CMS fonctionne avec une nouvelle version de PHP ?
Consultez la configuration requise sur la page officielle de l'éditeur et testez dans un environnement de préproduction. Il en va de même pour les extensions et les thèmes, car ils constituent souvent le véritable goulot d'étranglement.