Les correctifs PHP sont disponibles. Au 21 octobre 2026, les versions publi\u00e9es 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\u00e9 est de faire v\u00e9rifier et corriger le moteur PHP par l\u2019h\u00e9bergeur ou le mainteneur, puis de tester les fonctions qui font tourner l\u2019activit\u00e9.<\/strong><\/p>\n Le bouton \u00ab Mettre \u00e0 jour \u00bb du CMS peut donner une fausse impression de s\u00e9curit\u00e9. WordPress, les modules PrestaShop et le moteur qui les ex\u00e9cute ne sont pas la m\u00eame couche. Une boutique peut avoir tous ses modules \u00e0 jour et fonctionner sur un PHP encore vuln\u00e9rable.<\/p>\n Point de situation v\u00e9rifi\u00e9 le 21 octobre 2026 apr\u00e8s 15 h 41 UTC, soit 17 h 41 \u00e0 Paris. Les informations ci-dessous d\u00e9crivent les annonces officielles alors disponibles, pas l\u2019\u00e9tat individuel de votre h\u00e9bergement.<\/em><\/p>\n L\u2019annonce initiale fixait une publication au mercredi 21 octobre 2026 \u00e0 14 h UTC, soit 16 h \u00e0 Paris (UTC+2). Cette \u00e9ch\u00e9ance est pass\u00e9e : l\u2019avis de s\u00e9curit\u00e9 officiel PHP<\/a> annonce d\u00e9sormais les correctifs et recommande une mise \u00e0 jour imm\u00e9diate. Il ne faut donc plus attendre une divulgation \u00e0 venir pour organiser l\u2019intervention.<\/p>\n Les deux vuln\u00e9rabilit\u00e9s peuvent permettre une ex\u00e9cution de code \u00e0 distance sans authentification : un attaquant pourrait faire ex\u00e9cuter du code par le serveur sans disposer d\u2019un compte. Les avis officiels leur attribuent un score CVSS v4.0 de 9,2 sur 10. Ce score exprime une gravit\u00e9 technique, pas la probabilit\u00e9 que votre boutique ait d\u00e9j\u00e0 \u00e9t\u00e9 attaqu\u00e9e.<\/p>\n PHP d\u00e9crit un risque pour les installations servant des requ\u00eates web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L\u2019\u00e9quipe consid\u00e8re le risque le plus \u00e9lev\u00e9 avec mod_php, pour lequel elle rapporte un exploit d\u00e9montr\u00e9 avant l\u2019ex\u00e9cution du code applicatif. L\u2019appartenance \u00e0 une famille de CMS ne suffit donc pas \u00e0 d\u00e9terminer l\u2019exposition exacte : le moteur, sa version et son mode d\u2019ex\u00e9cution comptent.<\/p>\n Dans les branches maintenues, les versions correctrices annonc\u00e9es 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<\/strong>. Les versions ant\u00e9rieures de chacune de ces branches sont concern\u00e9es selon les avis. Un fournisseur peut aussi distribuer un paquet avec correctif r\u00e9troport\u00e9 : il faut alors obtenir sa r\u00e9f\u00e9rence de paquet et son avis de s\u00e9curit\u00e9, plut\u00f4t que conclure sur le seul num\u00e9ro affich\u00e9.<\/p>\n Demandez une confirmation pour le PHP qui sert r\u00e9ellement le site, pas uniquement pour celui utilis\u00e9 en ligne de commande. Plusieurs versions peuvent cohabiter sur un serveur. Une capture de 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\u00e9e. Cela ne r\u00e9tablit pas le support normal de ces branches. Si vous \u00eates dans ce cas, faites confirmer la couverture effective par votre fournisseur et planifiez la migration vers une branche compatible et maintenue.<\/p>\n PHP 8.2 arrive lui-m\u00eame en fin de support de s\u00e9curit\u00e9 le 31 d\u00e9cembre 2026, selon le calendrier officiel de maintenance<\/a>. Appliquer le correctif urgent et pr\u00e9parer la migration sont deux travaux distincts ; le second ne doit pas retarder inutilement le premier.<\/p>\n Imaginons une boutique PrestaShop dont le paiement fonctionne avant intervention mais dont le module bancaire \u00e9choue ensuite. Ce sc\u00e9nario illustratif montre pourquoi \u00ab le serveur r\u00e9pond \u00bb ne suffit pas \u00e0 r\u00e9ceptionner la maintenance. Il faut aussi v\u00e9rifier qu\u2019une commande peut aller au bout.<\/p>\n Si les acc\u00e8s, d\u00e9pendances ou sauvegardes sont mal connus, le probl\u00e8me d\u00e9passe cette seule version. Notre m\u00e9thode pour reprendre une application existante sans modifier \u00e0 l\u2019aveugle<\/a> sert \u00e0 r\u00e9tablir cette ma\u00eetrise avant les prochaines interventions.<\/p>\n Non. PHP pr\u00e9cise qu\u2019il n\u2019existe pas de mesure de contournement compl\u00e8te et que la mise \u00e0 jour est la seule solution s\u00fbre. Les mesures temporaires d\u00e9crites par l\u2019\u00e9quipe r\u00e9duisent certaines voies d\u2019attaque sans rendre l\u2019installation s\u00fbre. Leur application doit \u00eatre arbitr\u00e9e par l\u2019exploitant ; copier des r\u00e9glages trouv\u00e9s en ligne peut introduire un autre risque de disponibilit\u00e9.<\/p>\n Un plugin de s\u00e9curit\u00e9 WordPress ne met pas \u00e0 jour le moteur PHP. Un site qui s\u2019affiche normalement n\u2019est pas une preuve d\u2019absence de vuln\u00e9rabilit\u00e9. \u00c0 l\u2019inverse, utiliser une version vuln\u00e9rable ne d\u00e9montre pas qu\u2019une intrusion a eu lieu : exposition, exploitation et compromission sont trois constats diff\u00e9rents.<\/p>\n Pour le dirigeant, le livrable utile tient en quelques \u00e9l\u00e9ments : sites et environnements trait\u00e9s, version ou paquet corrig\u00e9 r\u00e9ellement utilis\u00e9 par le web, heure d\u2019application, processus relanc\u00e9s, r\u00e9sultats des tests m\u00e9tier et responsable de la surveillance. \u00ab Nous avons mis \u00e0 jour le site \u00bb reste trop vague pour fermer cette alerte.<\/p>\n Chez Say Digital, le d\u00e9ploiement contr\u00f4l\u00e9 consiste ici \u00e0 relier le signal de s\u00e9curit\u00e9 \u00e0 une preuve de correction et \u00e0 une v\u00e9rification m\u00e9tier. Votre h\u00e9bergeur et votre prestataire se renvoient la responsabilit\u00e9 ?<\/strong> Contactez Say Digital<\/a> pour cadrer la maintenance de votre WordPress, PrestaShop ou application PHP : p\u00e9rim\u00e8tre, acc\u00e8s, tests et responsabilit\u00e9s avant intervention.<\/p>\n PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 corrigent deux failles critiques. Comment faire v\u00e9rifier votre h\u00e9bergement et tester vos parcours m\u00e9tier.<\/p>\n","protected":false},"author":2,"featured_media":14622,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_mi_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0},"categories":[158],"tags":[],"yoast_head":"\nQue reste-t-il de l\u2019alerte \u00ab ce mercredi \u00e0 16 heures \u00bb ?<\/h2>\n
\n
Quelle version PHP faut-il demander \u00e0 son h\u00e9bergeur ?<\/h2>\n
php -v<\/code> ne prouve pas, \u00e0 elle seule, que le processus web de la boutique a \u00e9t\u00e9 corrig\u00e9 et red\u00e9marr\u00e9.<\/p>\nComment corriger vite sans casser le paiement ou les commandes ?<\/h2>\n
\n
Un pare-feu ou un plugin de s\u00e9curit\u00e9 peuvent-ils remplacer le correctif ?<\/h2>\n
Que doit contenir la preuve de cl\u00f4ture ?<\/h2>\n
Sources officielles<\/h2>\n
\n