Actualité sécurité · Analyse du 24 octobre 2026
Votre site internet fonctionne, les formulaires arrivent et WordPress affiche ses mises à jour. Cela ne répond pourtant pas à une question essentielle cette semaine : le moteur PHP qui exécute votre site a reçu son correctif ? Deux vulnérabilités critiques, regroupées sous le nom PHP2Shell, ont conduit le projet PHP à publier des versions de sécurité le 21 octobre 2026.
La priorité : obtenir de votre hébergeur la preuve de correction du PHP utilisé par chaque site, puis faire tester les parcours qui génèrent vos demandes commerciales.
Pourquoi un site internet à jour peut rester concerné
Un site repose sur plusieurs couches. Le CMS organise ses contenus. Les extensions ajoutent des fonctions. Le moteur PHP exécute du code sur le serveur. Une mise à jour de WordPress ne démontre donc pas que toutes ces couches ont été corrigées.
Le bulletin officiel PHP décrit deux défauts du moteur : une corruption mémoire lors du traitement d’un manque de mémoire et la réutilisation d’un état interne devenu invalide entre des requêtes. Une exploitation peut permettre une exécution de code sans authentification. Le projet considère le risque particulièrement élevé avec le module PHP d’Apache.
Ces défauts portent les références CVE 2026 109618 et CVE 2026 109619. Leurs identifiants exacts figurent dans les avis liés.
Pour une entreprise, le problème dépasse l’affichage d’une page. Un site peut recevoir des demandes de devis, échanger avec un CRM ou accéder à une base de données. L’inventaire doit suivre ces usages réels. Ne limitez pas la vérification à la page d’accueil ou au seul nom de domaine principal.
Une version vulnérable indique une exposition. Elle ne prouve pas qu’un attaquant est entré. Inversement, un site qui répond normalement ne prouve pas l’absence d’incident. Faites traiter séparément la correction et l’examen des traces.
Quelles versions PHP corrigent PHP2Shell ?
Voici les versions annoncées le 21 octobre pour les branches maintenues. Le fournisseur de votre système peut aussi distribuer un paquet corrigé avec sa propre numérotation.
| Branche | Version corrective |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Pour PHP 8.1 et les branches antérieures, demandez une attestation du fournisseur ou un plan de migration. Les adaptations exceptionnelles du correctif pour certaines anciennes branches ne rétablissent pas leur maintenance générale.
La précision publiée le 23 octobre
PHP recommande aussi de désactiver le suivi de progression des envois avec session.upload_progress.enabled=0 jusqu’à la prochaine correction régulière. L’avis du 23 octobre décrit une combinaison inhabituelle de configuration et de code applicatif liée à un changement de gestionnaire de sérialisation des sessions. Transmettez cet avis à l’administrateur pour qu’il vérifie votre situation. Cette consigne complémentaire ne remplace pas les correctifs du 21 octobre.
Le plan de contrôle à confier à votre équipe IT
1. Retrouver chaque environnement qui sert le site
Listez le site vitrine, les boutiques, les applications métier, les espaces clients et les environnements de recette accessibles. Pour chacun, consignez le responsable, l’hébergement et le rôle commercial. Un ancien formulaire de campagne mérite aussi un propriétaire identifié.
Demandez un relevé du moteur exécuté par le service web. Une version consultée dans une console peut correspondre à un autre environnement. La réponse attendue doit relier un site précis à un service précis.
2. Préparer une reprise vérifiable
Avant l’intervention, faites préciser la sauvegarde disponible, son périmètre et la méthode de restauration. Pour une boutique ou une application qui reçoit des écritures, définissez comment préserver les données créées pendant l’opération. Une sauvegarde déclarée disponible reste insuffisante si personne ne sait la restaurer.
La sauvegarde proposée par DIB France peut entrer dans cette réflexion. Le périmètre adapté à votre application doit être défini avant de considérer la reprise comme acquise.
3. Corriger puis confirmer le service réellement actif
L’administrateur doit fournir la référence du paquet ou de l’image corrigée, la date de déploiement et le résultat de sa vérification. Dans une architecture avec plusieurs serveurs, demandez une réponse couvrant chaque instance. Ne clôturez pas l’intervention sur la seule confirmation du téléchargement du correctif.
4. Examiner les anomalies sans effacer les preuves
Si l’équipe relève des fichiers inattendus, des accès inhabituels ou des comportements inexpliqués, organisez une analyse avec les personnes compétentes. Préservez les éléments disponibles et adaptez l’intervention au contexte. Le nettoyage précipité d’un serveur peut compliquer la compréhension de ce qui s’est passé.
5. Fermer les exceptions
Pour chaque environnement non corrigé, notez le blocage, le responsable et la prochaine décision. Une application incompatible doit déclencher un arbitrage concret sur sa migration, sa restriction d’accès ou sa suspension. Évitez qu’une mesure temporaire devienne un oubli durable.
Après la correction, vérifier que le site produit toujours des demandes
La validation technique et la validation commerciale doivent se rejoindre. Choisissez les parcours indispensables avant l’intervention : demande de devis, réservation, connexion, téléchargement ou paiement selon votre activité. Refaites ces parcours après la correction et contrôlez aussi leur réception dans les outils concernés.
Pour un formulaire, afficher un message de succès ne suffit pas. Vérifiez que la demande arrive au bon destinataire, que les champs utiles sont conservés et que l’équipe commerciale peut la traiter. Consignez le résultat, l’heure et la personne qui l’a contrôlé.
Cette coordination concerne l’hébergeur, l’équipe IT et le prestataire du site. Pour les entreprises qui souhaitent revoir leurs pages et leurs parcours de demande, ForgeOne accompagne la création et l’optimisation des sites internet. Le rôle du prestataire web consiste ici à vérifier le fonctionnement du parcours, en complément du travail de correction de l’infrastructure.
Chez DIB France, les offres Cyber One et Cloud in One permettent d’ouvrir la discussion sur votre sécurité et votre hébergement. Faites préciser les responsabilités de chacun dans le périmètre retenu.
Questions fréquentes sur PHP2Shell
La mise à jour de WordPress suffit ?
Non. Demandez une confirmation distincte pour le moteur PHP de l’hébergement. Les mises à jour du CMS et de ses extensions restent nécessaires, mais elles ne constituent pas cette preuve.
Un hébergeur qui dit avoir corrigé tous ses serveurs suffit ?
Demandez que la confirmation couvre votre offre et les environnements utilisés. Conservez son avis de sécurité, sa date et la référence du correctif. Faites ensuite vérifier les fonctions du site par son gestionnaire.
Faut il changer immédiatement tous les accès ?
La décision doit suivre le périmètre d’exposition et les constats de l’analyse. Faites définir les accès concernés et l’ordre des opérations par le responsable de la réponse à incident. Une rotation mal coordonnée peut interrompre une intégration utile.
Quelle preuve garder pour le suivi ?
Un compte rendu qui relie chaque site à son correctif, sa date d’application, son responsable et ses tests. Ajoutez les exceptions restantes et leur prochaine échéance pour éviter une clôture incomplète.