PHP 8.1, 8.0 ou 7.4 : votre site n'a pas de correctif. Comment migrer vers une version supportée

La publication de sécurité PHP du 21 octobre 2026 a une conséquence que beaucoup de propriétaires de sites découvrent aujourd'hui : PHP 8.1 et toutes les versions antérieures ne reçoivent pas de correctif. Les deux failles critiques (CVE-2026-109618 et CVE-2026-109619, expliquées dans notre article dédié) sont présentes dans ces versions depuis des années, et elles y resteront. Si votre site tourne sur 7.4, 8.0 ou 8.1, cet article explique pourquoi attendre n'est pas une option et comment migrer proprement vers 8.3 ou 8.4.

Le calendrier de support de PHP

Chaque branche de PHP reçoit des corrections de bugs pendant deux ans, puis des corrections de sécurité pendant deux ans supplémentaires, avant d'arriver en fin de vie. En octobre 2026, la situation est la suivante :

• PHP 8.5, 8.4 et 8.3 : supportées, correctifs disponibles (8.5.12, 8.4.27, 8.3.36).
• PHP 8.2 : correctifs de sécurité jusqu'au 31 décembre 2026 seulement (8.2.35 est disponible).
• PHP 8.1, 8.0, 7.4 et antérieures : fin de vie, aucun correctif officiel pour les failles du 21 octobre.

L'équipe PHP a tout de même publié des rétroportages minimaux du correctif pour 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP depuis les sources, et certaines distributions Linux ou prestataires de support étendu intègrent la correction dans leurs paquets. Pour un site hébergé classiquement, cela ne change rien : la version que vous utilisez vient de votre hébergeur, et la seule voie sûre est la migration.

Pourquoi « ça marche encore » n'est pas un argument

Un site sur PHP 7.4 fonctionne parfaitement aujourd'hui, comme hier. Le risque n'est pas qu'il s'arrête, c'est qu'il devienne une porte ouverte. Les failles du 21 octobre permettent, dans les conditions démontrées, à une requête non authentifiée d'exécuter du code sur le serveur. Et la CISA, l'agence américaine de cybersécurité, recommande de mettre hors ligne les systèmes sur PHP 8.1 ou antérieur qui ne peuvent pas être mis à niveau. Ce n'est pas une recommandation habituelle : elle traduit la gravité des failles et le fait que les attaquants disposent déjà d'éléments publics pour les reproduire.

Il y a aussi des conséquences indirectes. Un site compromis peut servir à envoyer du spam depuis votre domaine, héberger des pages de phishing, miner de la cryptomonnaie ou servir de relais vers d'autres cibles. Les conséquences vont de la mise sur liste noire de votre domaine à la perte de données clients, avec les obligations légales qui en découlent.

Ce qui change entre 8.1 et 8.4

Une migration de branche n'est pas une mise à jour mineure. Entre PHP 7.4 et 8.4, le langage a retiré des fonctions, rendu certaines erreurs plus strictes (types, propriétés dynamiques, paramètres nuls) et déprécié des usages courants dans le code ancien. Concrètement, les points qui cassent le plus souvent :

• Plugins et thèmes WordPress abandonnés, qui utilisent des fonctions retirées ou des constructions dépréciées.
• Code sur mesure ancien sans tests : erreurs de type qui étaient silencieuses en 7.4 et deviennent fatales en 8.x.
• Extensions PHP (mcrypt, par exemple) qui n'existent plus et qu'il faut remplacer.
• Frameworks obsolètes : Laravel 8 et antérieur, Symfony 4, CodeIgniter 3, qui ne supportent pas officiellement PHP 8.4.
• Bibliothèques Composer figées depuis des années.

La méthode de migration en 6 étapes

1. Inventaire : version actuelle, CMS ou framework, liste des plugins, extensions et bibliothèques, avec leur date de dernière mise à jour.
2. Analyse de compatibilité : des outils comme PHPCompatibility (pour PHP_CodeSniffer) ou Rector repèrent le code incompatible. Sur WordPress, le plugin PHP Compatibility Checker donne une première idée, à confirmer par un test réel.
3. Environnement de test avec la version cible (8.3 ou 8.4), copie des données de production et affichage de toutes les erreurs activé.
4. Corrections : mise à jour des plugins et bibliothèques, remplacement de ceux qui sont abandonnés, correction du code sur mesure.
5. Recette : parcours complet du site, formulaires, paiement, exports, tâches planifiées, envoi d'emails, intégrations tierces.
6. Bascule à une heure creuse avec sauvegarde juste avant, puis surveillance des journaux pendant plusieurs jours.

Que faire en attendant la migration

Si la migration prend plusieurs jours (code sur mesure important, plugins à remplacer), ne laissez pas le site exposé pendant ce temps. Par ordre d'efficacité :

• Vérifier auprès de l'hébergeur ou de la distribution s'il existe un paquet rétroporté pour votre version. Certains fournisseurs de support étendu (pour 7.4, 8.0 et 8.1) l'ont fait.
• Appliquer les mesures temporaires décrites par l'équipe PHP : session.upload_progress.enabled = 0 dans la configuration serveur avec redémarrage des workers, memory_limit géré au niveau du conteneur plutôt que de PHP, post_max_size bas. Elles réduisent l'exposition sans la supprimer.
• Placer un pare-feu applicatif devant le site et, si l'application est interne, restreindre l'accès par adresse IP ou VPN.
• En dernier recours, mettre le site hors ligne ou le remplacer par une page statique temporaire, comme le recommande la CISA pour les systèmes impossibles à corriger. Une page « nous revenons bientôt » coûte moins cher qu'une compromission.

Combien de temps prend une migration ?

Pour un site WordPress bien entretenu, passer de 8.1 à 8.4 se fait souvent en une demi-journée, test compris. Pour un site avec des plugins abandonnés ou un thème ancien, comptez quelques jours, le temps de trouver et de tester des alternatives. Pour une application sur mesure sans tests automatisés, la durée dépend de la taille du code : l'analyse de compatibilité initiale donne une estimation fiable en quelques heures. Dans tous les cas, c'est un investissement qui se refait tous les deux à trois ans ; le planifier évite de le subir un jour d'alerte.

Nous migrons votre site vers une version supportée

La migration de version PHP fait partie de notre maintenance et accompagnement : analyse de compatibilité, corrections, test sur environnement de préproduction et bascule accompagnée. Si vous venez de découvrir que votre site tourne sur 7.4 ou 8.1, contactez-nous : la première étape, l'inventaire, se fait rapidement et vous dira à quoi vous attendre.