Failles critiques PHP : corriger WordPress et PrestaShop sans perdre le contrôle
Failles critiques PHP : corriger WordPress et PrestaShop sans perdre le contrôle
Les correctifs PHP sont disponibles. Au 21 octobre 2026, les versions publiées pour corriger CVE-2026-109618 et CVE-2026-109619 sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour un site WordPress ou PrestaShop, la priorité est de faire vérifier et corriger le moteur PHP par l’hébergeur ou le mainteneur, puis de tester les fonctions qui font tourner l’activité.
Le bouton « Mettre à jour » du CMS peut donner une fausse impression de sécurité. WordPress, les modules PrestaShop et le moteur qui les exécute ne sont pas la même couche. Une boutique peut avoir tous ses modules à jour et fonctionner sur un PHP encore vulnérable.
Point de situation vérifié le 21 octobre 2026 après 15 h 41 UTC, soit 17 h 41 à Paris. Les informations ci-dessous décrivent les annonces officielles alors disponibles, pas l’état individuel de votre hébergement.
Que reste-t-il de l’alerte « ce mercredi à 16 heures » ?
L’annonce initiale fixait une publication au mercredi 21 octobre 2026 à 14 h UTC, soit 16 h à Paris (UTC+2). Cette échéance est passée : l’avis de sécurité officiel PHP annonce désormais les correctifs et recommande une mise à jour immédiate. Il ne faut donc plus attendre une divulgation à venir pour organiser l’intervention.
Les deux vulnérabilités peuvent permettre une exécution de code à distance sans authentification : un attaquant pourrait faire exécuter du code par le serveur sans disposer d’un compte. Les avis officiels leur attribuent un score CVSS v4.0 de 9,2 sur 10. Ce score exprime une gravité technique, pas la probabilité que votre boutique ait déjà été attaquée.
- CVE-2026-109618 : corruption liée au traitement d’une situation de mémoire insuffisante.
- CVE-2026-109619 : réutilisation d’un état interne devenu invalide entre des requêtes.
PHP décrit un risque pour les installations servant des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L’équipe considère le risque le plus élevé avec mod_php, pour lequel elle rapporte un exploit démontré avant l’exécution du code applicatif. L’appartenance à une famille de CMS ne suffit donc pas à déterminer l’exposition exacte : le moteur, sa version et son mode d’exécution comptent.
Quelle version PHP faut-il demander à son hébergeur ?
Dans les branches maintenues, les versions correctrices annoncées sont 8.2.35 pour PHP 8.2, 8.3.36 pour PHP 8.3, 8.4.27 pour PHP 8.4 et 8.5.12 pour PHP 8.5. Les versions antérieures de chacune de ces branches sont concernées selon les avis. Un fournisseur peut aussi distribuer un paquet avec correctif rétroporté : il faut alors obtenir sa référence de paquet et son avis de sécurité, plutôt que conclure sur le seul numéro affiché.
Demandez une confirmation pour le PHP qui sert réellement le site, pas uniquement pour celui utilisé en ligne de commande. Plusieurs versions peuvent cohabiter sur un serveur. Une capture de php -v ne prouve pas, à elle seule, que le processus web de la boutique a été corrigé et redémarré.
Pour PHP 8.1 et les versions plus anciennes, le projet ne fournit plus de maintenance courante. PHP signale toutefois des correctifs source minimaux pour 7.4, 8.0 et 8.1, ainsi que des correctifs possibles chez des fournisseurs de support longue durée. Cela ne rétablit pas le support normal de ces branches. Si vous êtes dans ce cas, faites confirmer la couverture effective par votre fournisseur et planifiez la migration vers une branche compatible et maintenue.
PHP 8.2 arrive lui-même en fin de support de sécurité le 31 décembre 2026, selon le calendrier officiel de maintenance. Appliquer le correctif urgent et préparer la migration sont deux travaux distincts ; le second ne doit pas retarder inutilement le premier.
Comment corriger vite sans casser le paiement ou les commandes ?
Imaginons une boutique PrestaShop dont le paiement fonctionne avant intervention mais dont le module bancaire échoue ensuite. Ce scénario illustratif montre pourquoi « le serveur répond » ne suffit pas à réceptionner la maintenance. Il faut aussi vérifier qu’une commande peut aller au bout.
- Attribuer l’intervention. L’hébergeur corrige-t-il PHP, ou cette responsabilité revient-elle au mainteneur ? Demandez un responsable, une échéance et une confirmation écrite. En mutualisé, ne supposez pas que le correctif est déjà appliqué.
- Préparer une reprise courte. Vérifiez une sauvegarde récente des fichiers et de la base, sa restauration possible, ainsi que le traitement des commandes reçues pendant l’intervention. Le retour arrière doit préserver les commandes et ne pas laisser durablement un moteur vulnérable exposé. Une copie sans test ne garantit pas la reprise ; notre guide sur le test de restauration et la reprise d’activité explique cette distinction, valable aussi pour un site marchand.
- Déployer le correctif compatible. Privilégiez le correctif de sécurité de la branche en place lorsqu’elle est maintenue et compatible avec l’application. Une alerte urgente n’est pas le bon moment pour cumuler migration majeure, changement de thème et remplacement de modules.
- Valider les parcours décisifs. Testez connexion, formulaire, panier, paiement avec le dispositif de test prévu et confirmation de commande. Vérifiez aussi les tâches planifiées et les échanges avec l’ERP ou la logistique, lorsqu’ils existent.
- Surveiller après remise en service. Contrôlez erreurs PHP, échecs de paiement, commandes manquantes et journaux de sécurité. Si des indices d’intrusion apparaissent, ouvrez une investigation : le patch ne supprime pas les effets d’une compromission antérieure.
Si les accès, dépendances ou sauvegardes sont mal connus, le problème dépasse cette seule version. Notre méthode pour reprendre une application existante sans modifier à l’aveugle sert à rétablir cette maîtrise avant les prochaines interventions.
Un pare-feu ou un plugin de sécurité peuvent-ils remplacer le correctif ?
Non. PHP précise qu’il n’existe pas de mesure de contournement complète et que la mise à jour est la seule solution sûre. Les mesures temporaires décrites par l’équipe réduisent certaines voies d’attaque sans rendre l’installation sûre. Leur application doit être arbitrée par l’exploitant ; copier des réglages trouvés en ligne peut introduire un autre risque de disponibilité.
Un plugin de sécurité WordPress ne met pas à jour le moteur PHP. Un site qui s’affiche normalement n’est pas une preuve d’absence de vulnérabilité. À l’inverse, utiliser une version vulnérable ne démontre pas qu’une intrusion a eu lieu : exposition, exploitation et compromission sont trois constats différents.
Que doit contenir la preuve de clôture ?
Pour le dirigeant, le livrable utile tient en quelques éléments : sites et environnements traités, version ou paquet corrigé réellement utilisé par le web, heure d’application, processus relancés, résultats des tests métier et responsable de la surveillance. « Nous avons mis à jour le site » reste trop vague pour fermer cette alerte.
Chez Say Digital, le déploiement contrôlé consiste ici à relier le signal de sécurité à une preuve de correction et à une vérification métier. Votre hébergeur et votre prestataire se renvoient la responsabilité ? Contactez Say Digital pour cadrer la maintenance de votre WordPress, PrestaShop ou application PHP : périmètre, accès, tests et responsabilités avant intervention.
