Deux vulnérabilités critiques corrigées
Le projet PHP a publié le 21 octobre 2026 les versions de sécurité PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent CVE-2026-109618 et CVE-2026-109619, que l’équipe PHP décrit comme pouvant permettre une exécution de code à distance sans authentification. En termes simples, une requête réseau pourrait amener un serveur à exécuter du code sans qu’un compte valide soit nécessaire. Le projet qualifie ces failles de critiques et recommande une mise à jour.
L’avis décrit deux conditions internes différentes. Nous ne reproduisons aucun détail d’exploitation. Le point opérationnel est que le runtime PHP traite des requêtes avant que les protections de l’application puissent forcément intervenir : un pare-feu de plugin ou le masquage des erreurs ne remplace pas un runtime corrigé. PHP indique qu’il n’existe pas de mesure d’atténuation complète et que la mise à jour est le choix sûr.
Vérifiez le runtime qui sert le site
Un site WordPress, WooCommerce ou sur mesure n’est pas automatiquement vulnérable simplement parce qu’il utilise PHP. L’exposition dépend de la compilation PHP, de l’interface serveur, de la configuration, des correctifs du fournisseur et de l’état de l’hébergement. PHP cite les installations web utilisant PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed, et considère mod_php comme le cas le plus risqué. Les distributions Linux et fournisseurs LTS peuvent rétroporter les correctifs sous leurs propres numéros de paquet.
Identifiez la version PHP réellement utilisée par le site en production, et non seulement celle de la ligne de commande sur le poste d’un développeur. Les hébergeurs WordPress gérés affichent souvent cette information dans un panneau ou via leur assistance. Les clients d’hébergement mutualisé peuvent demander quel paquet est actif et si le runtime a été redémarré. Un correctif rétroporté peut être présent sans changement du numéro de version en amont.
Mettre à jour avec des tests ciblés
Sur un environnement que vous gérez, créez une sauvegarde récente et vérifiez qu’elle peut être restaurée. Installez le paquet corrigé en préproduction si possible, puis testez les parcours essentiels : connexion, formulaires, tâches planifiées, médias, paiement, intégrations et administration. Consultez les journaux et les traitements en arrière-plan. Si le site dépend d’extensions personnalisées ou anciennes, testez-les avec le nouveau runtime avant le changement en production.
L’hébergeur peut appliquer la mise à jour de manière centralisée, mais le client devrait confirmer que le runtime de production est couvert et que le site fonctionne ensuite. Ne différez pas longtemps un correctif de sécurité pour attendre une refonte. Si une incompatibilité bloque la mise à jour, demandez au fournisseur ou au développeur une remédiation précise et datée ; une mesure au niveau applicatif ne neutralise pas nécessairement une faille du runtime.
Préparer aussi la suite
Selon le projet PHP, PHP 8.2 arrive en fin de vie le 31 décembre 2026. La version 8.2.35 corrige l’avis actuel, mais ne prolonge pas la période de maintenance de la branche. Les équipes encore sous 8.2 devraient planifier des tests de compatibilité et migrer vers une branche prise en charge avant la fin des correctifs de sécurité. PHP 8.1 et versions antérieures ne reçoivent plus de correctifs du projet ; certains fournisseurs LTS peuvent en rétroporter, ce qu’il faut vérifier.
Tenez un inventaire simple des sites, versions PHP, responsables et canaux de mise à jour. La prochaine alerte sera ainsi plus facile à traiter. Il faut vérifier le runtime en production auprès de son opérateur, puis tester le site. L’avis ne prouve pas qu’un système a été compromis, et l’usage de WordPress ne suffit pas à conclure qu’il est vulnérable ou protégé.
Sources et références
Une erreur factuelle à signaler ou une source à suggérer ? Contacter la rédaction.
