En bref : qui exploite encore PHP 8.1 ou antérieur ne reçoit plus de mises à jour de sécurité officielles du projet PHP, pas même pour PHP2Shell. Une mise à niveau de PHP 8.1 vers une version prise en charge n'est donc pas un luxe, mais la véritable solution. Nous vérifions vos applications, testons sur une copie, migrons de façon contrôlée et sécurisons la période d'ici là.
Pourquoi PHP 8.1 et antérieur est désormais un risque aigu
Les failles PHP2Shell CVE-2026-109618 et CVE-2026-109619 permettent l'exécution de code sans authentification. Elles sont corrigées dans PHP 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 mises à jour officielles, seulement des backports 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.
Certaines distributions et certains hébergeurs appliquent leurs propres backports. Savoir si votre système en fait partie doit être confirmé par le fournisseur pour votre état de paquets précis. Sans cette confirmation, vous devriez partir du principe que le serveur est ouvert. Ce que cela signifie en détail, PHP 8.1 et antérieur : ce qui s'applique maintenant le décrit.
Mise à niveau de PHP 8.1 : quelle version cible ?
La cible devrait être une version que le projet PHP prend encore en charge et que votre application autorise. L'état actuel de la prise en charge est publié par php.net sur la page des versions prises en charge. PHP 8.2 s'achève le 31 décembre 2026 ; un passage à 8.2 ne serait donc qu'une étape intermédiaire avec un projet suivant proche.
Quelle version de PHP votre CMS ou système de boutique prend en charge, nous le vérifions d'après les exigences système de l'éditeur, par exemple sur wordpress.org, shopware.com ou typo3.org, et non de mémoire. Souvent, le CMS lui-même doit d'abord être mis à jour. Les anciennes boutiques en sont un cas typique, voir Shopware 5 : anciennes boutiques sur une ancienne version de PHP.
Comment PHP SOS aide-t-il concrètement ?
- Inventaire et sécurisation : nous recensons toutes les applications, leur version de PHP, l'état du CMS, les extensions et le code spécifique. En parallèle, nous mettons en place les mesures transitoires de php.net afin que le risque baisse jusqu'à la migration ; détails sous WAF et correctif virtuel.
- Vérifier la compatibilité : nous comparons les exigences système des éditeurs, vérifions les dépendances avec Composer et recherchons dans le code spécifique des fonctions obsolètes. Ce que cela donne pour les dépendances, Vérifier les failles dans les dépendances Composer le décrit.
- Test sur une copie : l'application fonctionne d'abord dans un environnement de test avec la nouvelle version de PHP. Nous y corrigeons les erreurs ou les documentons pour votre agence.
- Bascule avec retour arrière : la bascule en production a lieu dans une fenêtre de maintenance convenue, avec une sauvegarde récente et un retour arrière défini.
- Contrôle ultérieur : nous vérifions les journaux d'erreurs et les fonctions centrales après la bascule et supprimons l'ancienne version de PHP lorsqu'elle n'est plus nécessaire.
Sur de nombreux systèmes, un coup d'œil sans danger permet de voir quels sites web utilisent quelle version de PHP, via les pools FPM en cours d'exécution :
# afficher les maîtres et pools PHP-FPM en cours d'exécution
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# versions de PHP installées (Debian/Ubuntu)
ls /etc/php/
Une mise à niveau vers une nouvelle version de PHP ne supprime aucun logiciel malveillant introduit auparavant. Si le serveur était exposé sans protection au réseau depuis le 17 octobre 2026, un examen des traces en fait partie.
Pierres d'achoppement typiques de la mise à niveau
La plupart des problèmes lors d'un changement de version de PHP sont prévisibles si l'on sait où chercher :
- Extensions obsolètes : les plugins ou modules qui ne sont plus entretenus ne fonctionnent souvent pas sur les versions de PHP plus récentes. Il faut les remplacer ou les adapter.
- Code spécifique : les fonctions que PHP a entre-temps marquées comme obsolètes ou supprimées provoquent des avertissements ou des arrêts. Des contrôles de types plus stricts révèlent d'anciennes erreurs de programmation.
- Dépendances : les bibliothèques intégrées via Composer exigent parfois elles-mêmes de nouvelles versions et entraînent d'autres modifications.
- Extensions PHP sur le serveur : toutes les extensions installées sous l'ancienne version ne sont pas automatiquement disponibles pour la nouvelle.
- Tâches cron et ligne de commande : le site web fonctionne déjà sur la nouvelle version, mais des tâches planifiées appellent encore l'ancienne version de PHP.
Qui vérifie ces points au préalable raccourcit la bascule et évite les surprises en production.
Ce que vous recevez et ce dont nous avons besoin
Vous recevez un aperçu de toutes les applications avec version de départ et version cible, un plan de migration avec ordre et risques, un procès-verbal de test, la documentation de la bascule et une liste de points que votre agence ou votre développeur doit encore traiter.
De votre part, nous avons besoin de :
- l'accès au serveur ou au panneau d'administration et aux back-offices des CMS
- l'accès au code source et au dépôt pour les développements spécifiques
- un contact avec l'agence ou le développeur qui connaissent l'application
- un environnement de test ou l'autorisation d'en créer un
- des fenêtres de maintenance et un interlocuteur pour la recette
Ce que nous ne promettons pas
Nous ne promettons pas que chaque ancienne application fonctionne sans modifications sur une nouvelle version de PHP. Pour les systèmes qui ne sont plus développés, une refonte plus importante ou un changement peut être nécessaire ; nous le disons ouvertement dès que cela se dessine. Nous fondons les affirmations de compatibilité sur les indications des éditeurs. Et les mesures transitoires ne remplacent pas la migration, elles ne font que combler le temps. Les risques à long terme des versions obsolètes sont décrits dans Fin de vie de PHP : risques des versions obsolètes.
Questions fréquentes
PHP 8.1 est-il concerné par PHP2Shell ?
Selon la presse spécialisée, presque toutes les versions, jusqu'à PHP 5.4, sont concernées. Pour PHP 8.1 et antérieur, le projet PHP ne publie plus de mises à jour officielles, seulement des backports minimaux du code source pour 7.4, 8.0 et 8.1. Certaines distributions appliquent leurs propres backports ; c'est au fournisseur concerné de le confirmer.
Vers quelle version de PHP dois-je migrer ?
Vers une version que le projet PHP prend encore activement en charge et que votre application autorise selon les exigences système de l'éditeur. PHP 8.2 atteint la fin de la prise en charge le 31 décembre 2026 et n'est donc qu'une cible conditionnellement judicieuse.
Ne puis-je pas simplement changer la version de PHP dans le panneau d'hébergement ?
Techniquement, cela se fait souvent en un clic. Savoir si l'application fonctionne encore ensuite dépend de la version du CMS, des extensions et du code spécifique. Sans test, vous risquez des pannes ou des fonctions défectueuses, par exemple à la caisse d'une boutique.
Que faire si mon CMS ne prend pas en charge la nouvelle version de PHP ?
Il faut alors d'abord mettre à jour le CMS, le cas échéant vers une nouvelle version majeure. Pour les systèmes qui ne sont plus développés, un changement peut être nécessaire. D'ici là, nous sécurisons le serveur avec des mesures transitoires.