Chez Say Digital, le serveur est pr\u00eat pour la mise \u00e0 jour PHP. Le point \u00e0 traiter pour les sites concern\u00e9s est la compatibilit\u00e9 du logiciel : WordPress ou PrestaShop, leurs extensions, modules et th\u00e8mes doivent \u00eatre \u00e0 jour pour permettre la bascule dans de bonnes conditions. Cette intervention peut entra\u00eener des co\u00fbts de prestation et, selon les composants install\u00e9s, de renouvellement ou d\u2019achat de licences. Pour obtenir un devis, contactez votre chef de projet Say Digital ou notre support.<\/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 Pour les sites accompagn\u00e9s par Say Digital, la pr\u00e9paration du serveur n\u2019est pas le point bloquant. Une ancienne version de WordPress ou de PrestaShop, un module de paiement vieillissant ou un th\u00e8me non maintenu peuvent en revanche emp\u00eacher le passage \u00e0 une version PHP maintenue et corrig\u00e9e. Nous devons donc v\u00e9rifier la compatibilit\u00e9 du site et mettre \u00e0 niveau les composants qui l\u2019exigent avant de valider la bascule.<\/p>\n Serveur pr\u00eat ne signifie pas mise \u00e0 jour d\u00e9j\u00e0 appliqu\u00e9e \u00e0 chaque site.<\/strong> La mise \u00e0 jour du logiciel et celle du moteur PHP restent deux op\u00e9rations distinctes : mettre WordPress ou PrestaShop \u00e0 jour ne corrige pas, \u00e0 lui seul, une faille PHP. L\u2019objectif est de pouvoir appliquer la correction c\u00f4t\u00e9 h\u00e9bergement tout en conservant un site fonctionnel.<\/p>\n WordPress et PrestaShop sont des logiciels libres ; le devis ne correspond pas n\u00e9cessairement \u00e0 une licence du CMS. Le co\u00fbt peut porter sur l\u2019intervention technique, les adaptations, les tests et, si n\u00e9cessaire, l\u2019achat ou le renouvellement de licences de modules, d\u2019extensions ou de th\u00e8mes. Une licence expir\u00e9e peut notamment emp\u00eacher l\u2019acc\u00e8s \u00e0 une version compatible. Ces frais \u00e9ventuels d\u00e9pendent de votre site : ils ne sont ni syst\u00e9matiques ni identiques pour tous les clients.<\/p>\n Demandez votre devis \u00e0 votre chef de projet Say Digital ou au support.<\/strong> Nous pr\u00e9cisons les composants \u00e0 mettre \u00e0 jour, les \u00e9ventuelles licences \u00e0 pr\u00e9voir et les tests n\u00e9cessaires. Le p\u00e9rim\u00e8tre et le budget sont \u00e0 valider avant l\u2019intervention ; la mise \u00e0 niveau est ensuite planifi\u00e9e avec vous.<\/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 Les besoins de mise \u00e0 niveau d\u00e9pendent de la version de WordPress ou de PrestaShop, des modules install\u00e9s et de leur compatibilit\u00e9. La pr\u00e9paration c\u00f4t\u00e9 h\u00e9bergement ne vaut pas validation de l\u2019ensemble de ces composants.<\/p>\n Pour \u00e9tudier les mises \u00e0 jour \u00e0 pr\u00e9voir, rapprochez-vous de votre chef de projet Say Digital ou du support afin de demander un devis<\/strong>. Le p\u00e9rim\u00e8tre de l\u2019intervention, les \u00e9ventuels co\u00fbts de licences et les modalit\u00e9s de r\u00e9alisation seront pr\u00e9cis\u00e9s dans la proposition, selon la situation de votre site et les prestations convenues. Si vous n\u2019avez pas encore d\u2019interlocuteur, vous pouvez contacter Say Digital<\/a>.<\/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":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[158],"tags":[],"class_list":["post-14626","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-developpement-web"],"yoast_head":"\nQue reste-t-il de l\u2019alerte \u00ab ce mercredi \u00e0 16 heures \u00bb ?<\/h2>\n
\n
Quels correctifs PHP sont disponibles ?<\/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>\nLe serveur est pr\u00eat : pourquoi faut-il aussi mettre WordPress ou PrestaShop \u00e0 jour ?<\/h2>\n
Pourquoi cette mise \u00e0 niveau peut-elle n\u00e9cessiter un budget ?<\/h3>\n
Comment 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
Faire le point sur la mise \u00e0 jour de votre site<\/h2>\n
Sources officielles<\/h2>\n
\n