Fr
PHP2Shell désigne deux vulnérabilités critiques dans PHP lui-même, CVE-2026-109618 et CVE-2026-109619, toutes deux notées CVSS 9.2. Elles ont été corrigées le 21 octobre 2026 dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 (CrowdSec). Le correctif est une mise à jour de PHP sur le serveur, suivie du redémarrage de tous les processus PHP. Mettre à jour WordPress, PrestaShop, un thème ou un module ne corrige rien (PrestaShop). Pour une agence, le travail se résume ainsi : pour chaque site client, savoir quelle version de PHP sert réellement le site, qui applique le correctif, et obtenir une confirmation écrite. Une dernière partie explique comment gérer les versions PHP de vos sites clients dans la durée, pour que la prochaine alerte PHP ne soit plus qu’une vérification de routine.
Les deux failles sont des erreurs de gestion de la mémoire dans le moteur PHP. Avec des requêtes HTTP spécialement construites, un attaquant pourrait faire planter PHP, exposer des données sensibles ou, dans le pire des cas, exécuter du code sur le serveur sans authentification (centre d’aide PrestaShop). Selon Sansec, les bugs sont présents dans toutes les versions de PHP non corrigées depuis la 5.4.
Trois points comptent pour une agence :
La situation est sérieuse sans être alarmante, et mérite d’être lue avec précision avant d’en parler aux clients :
En résumé : aucune raison de paniquer, aucune raison d’attendre. Le correctif existe ; pour chaque site client, la seule question est de savoir s’il a été appliqué.
Listez chaque site client avec son CMS, son hébergeur et qui gère PHP : l’hébergeur (mutualisé ou infogéré), votre équipe ou la DSI du client. La CISA recommande de commencer par cet inventaire et de corriger en priorité les systèmes exposés sur Internet.
Dans PrestaShop, la version figure dans Paramètres avancés > Informations. Dans WordPress, dans Outils > Santé du site > Infos > Serveur. Le PHP en ligne de commande et celui du serveur web peuvent différer : la valeur qui compte est celle que remonte le site (PrestaShop). Comparez-la avec 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Un numéro inférieur ne signifie pas forcément que le site est vulnérable : les distributions Linux intègrent souvent les correctifs sans changer le numéro de version, d’où l’étape suivante.
Pour les sites hébergés, posez une question précise : le correctif des CVE-2026-109618 et CVE-2026-109619 a-t-il été appliqué à la version de PHP qui fait tourner le site, et quand ? Demandez aussi que tous les processus PHP aient été redémarrés depuis. PrestaShop conseille d’obtenir cette confirmation par écrit (source). Conservez la réponse dans le dossier client.
PHP 8.1 et les versions antérieures ne reçoivent plus de mise à jour officielle régulière. Le projet PHP a publié des correctifs limités, sous forme de code source, pour les versions 7.4 à 8.1, et certains hébergeurs ou distributions fournissent leurs propres paquets corrigés (Search Engine Journal). Le cas est fréquent en e-commerce : PrestaShop 8.0 à 8.2 ne supporte PHP que jusqu’à la version 8.1 (PrestaShop). La CISA conseille de mettre hors ligne les systèmes en PHP 8.1 ou antérieur tant qu’ils ne sont pas corrigés. À noter aussi : le support de sécurité de PHP 8.2 prend fin le 31 décembre 2026 (php.net). Les sites en 8.2 doivent donc de toute façon prévoir une montée de version.
La consigne de Google, relayée par Search Engine Journal, est de renvoyer un code 503 pendant l’interruption, et non une 404 ou une page d’erreur en 200. En pratique :
Un pare-feu applicatif (WAF) filtre les requêtes avant qu’elles n’atteignent PHP et constitue une couche utile, mais les règles par signatures peuvent être contournées et ne remplacent pas la mise à jour (PrestaShop). L’avis de sécurité de PHP liste aussi des mesures de configuration provisoires : elles doivent être testées en préproduction et appliquées par la personne qui gère le serveur.
La CISA recommande de surveiller les processus PHP qui lancent des shells (source). Côté site, PrestaShop liste des signaux simples : fichiers .php inconnus ou récemment modifiés, comptes administrateurs créés par personne, redirections inattendues, contenu altéré ou page de paiement modifiée (source). Au moindre doute, contactez immédiatement l’hébergeur.
Un incident sans lien mérite d’être vérifié pendant la même tournée. Rank Math indique que les copies de Rank Math PRO 3.0.123 téléchargées entre le 15 octobre 2026 à 20h02 UTC et le 16 octobre 2026 à 7h12 UTC contenaient un logiciel malveillant. La version saine est la 3.0.124. Si la version concernée a été installée et activée pendant cette fenêtre, Rank Math demande de considérer le site comme compromis et de suivre sa procédure de remise en état ; la version gratuite de WordPress.org n’est pas concernée (Rank Math).
PHP2Shell sortira de l’actualité, mais la question de fond reviendra chaque année : quelle version de PHP fait tourner chaque site client, et jusqu’à quand recevra-t-elle des correctifs de sécurité ? Une routine courte permet d’y répondre avant la prochaine alerte.
Notre maintenance mensuelle à prix fixe repose sur cette routine. Parlez-nous de vos sites.
Restez factuel : une faille critique a été corrigée dans PHP le 21 octobre ; le correctif est une mise à jour du serveur ; voici la version de PHP de votre site, qui l’a corrigée et quand. Aucune dramatisation n’est utile, et aucune ne serait exacte aujourd’hui. Ce que le client apprécie, c’est la trace écrite que son site a été vérifié.
Nous développons et maintenons des sites WordPress et PrestaShop en marque blanche pour les agences, sous votre marque. Notre maintenance mensuelle est facturée à prix fixe mensuel : mises à jour, contrôles et suivi sont planifiés, plutôt que traités dans l’urgence à chaque vulnérabilité médiatisée. Depuis 2005, nous avons livré plus de 85 000 projets, dont 99 % dans les délais. Découvrez notre sous-traitance WordPress et notre sous-traitance PrestaShop, ou parlez-nous de vos sites via la page contact.
Non. Les failles sont dans PHP : le correctif est une mise à jour de PHP sur le serveur, suivie du redémarrage des processus PHP.
PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou un paquet corrigé fourni par la distribution Linux ou l’hébergeur.
Pas selon les sources disponibles au 27 octobre 2026 : CrowdSec observe des tentatives mais aucune compromission confirmée publiquement, et Sansec indique que les exploits publics ne fonctionnent pas sur une installation PHP par défaut. La mise à jour reste urgente.
Demandez à l’hébergeur si un paquet corrigé est disponible, appliquez les mesures provisoires avec la personne qui gère le serveur et planifiez le passage à une version de PHP maintenue. La CISA conseille de mettre hors ligne les systèmes en PHP 8.1 ou antérieur tant qu’ils ne sont pas corrigés.
Vous avez une idée ou un projet à concrétiser ? Décrivez-nous vos attentes en matière de création web, de design ou de solutions IA, et recevez une proposition personnalisée dédiée à votre croissance.
