PHP2Shell : le message à envoyer à votre hébergeur pour savoir si votre site est corrigé
Les correctifs existent. Pour une PME, l’urgence est d’identifier qui les déploie, quel service tourne réellement et quelle preuve conserver après l’intervention.
Les points clés de l’analyse, vérifiés par la rédaction.
Les failles concernent le moteur PHP ; mettre à jour un thème ou une extension ne corrige pas nécessairement cette couche.
La preuve utile identifie le paquet corrigé et le service web qui l’exécute après redémarrage.
La note PHP du 23 octobre ajoute une précaution spécifique ; il faut suivre les avis officiels adaptés à son environnement.
Votre hébergeur affirme que votre site est « à jour ». Parle-t-il de WordPress, des extensions… ou de PHP, le composant concerné par les vulnérabilités PHP2Shell ? La différence peut laisser une PME avec un faux sentiment de sécurité.
Pour une boutique, une école ou une entreprise, la bonne démarche consiste à demander la version PHP réellement utilisée, la correction appliquée, la date de déploiement et les vérifications effectuées. Voici comment obtenir une réponse exploitable sans prétendre réaliser un audit de votre serveur à distance.
Ce que les avis officiels établissent
Le 21 octobre 2026, PHP a annoncé deux vulnérabilités critiques pouvant permettre, dans certaines conditions, une exécution de code à distance sans authentification. Les avis CVE-2026-109618 et CVE-2026-109619 décrivent des problèmes distincts de gestion de mémoire et d’état interne.
Les versions correctives indiquées sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12. L’avis général de PHP appelle les installations servant des requêtes web à se mettre à jour et souligne un risque particulièrement élevé avec Apache mod_php.
Cela ne signifie pas que chaque site a déjà été compromis. Cela justifie une action de correction rapide, adaptée à l’environnement concerné.
Le message qu’un propriétaire peut envoyer
Si un hébergeur ou une agence administre le site, vous pouvez demander cette confirmation :
« Bonjour, notre site [domaine] utilise-t-il un environnement concerné par CVE-2026-109618 et CVE-2026-109619 ? Merci de confirmer le service PHP qui traite ses requêtes web, la version complète du paquet ou de l’image corrigée, l’avis fournisseur applicable, la date du déploiement et le redémarrage des processus concernés. Merci également de préciser les vérifications fonctionnelles effectuées et si des indices nécessitent une investigation. »
Il s’agit d’un modèle proposé par Insight. Il n’a pas été envoyé pour cet article. Son intérêt est de relier une réponse à un site et à une intervention identifiables.
Une réponse générale de type « nos serveurs sont sécurisés » ne documente pas ces éléments. Demandez les précisions manquantes plutôt qu’une assurance plus emphatique.
Pour l’équipe technique, suivre le service qui répond réellement
L’inventaire doit relier chaque application au serveur, au conteneur ou au service managé qui l’exécute. Les environnements moins visibles, comme une préproduction encore exposée, méritent aussi d’être recensés.
Une vérification en ligne de commande peut aider, mais php -v renseigne sur le binaire appelé dans ce contexte. Le serveur web peut en utiliser un autre. Il faut donc suivre la configuration qui traite effectivement les requêtes, puis confirmer que les processus ont été renouvelés après la mise à jour.
Évitez de créer une page publique de diagnostic contenant toute la configuration du serveur. Les informations nécessaires peuvent être contrôlées dans l’administration et conservées dans un compte rendu d’intervention.
Le numéro court n’est pas toujours toute la preuve
Un fournisseur peut intégrer une correction dans un paquet sans adopter exactement le numéro amont attendu. Il faut alors vérifier sa documentation, la version complète et, lorsque cela s’applique, la date de construction.
Plesk fournit un exemple concret : pour certaines anciennes branches Linux, son tableau distingue les constructions corrigées tout en conservant le même numéro PHP. Ce mécanisme doit être établi pour le fournisseur concerné ; il ne permet pas de présumer qu’une ancienne installation est protégée.
La bonne preuve associe donc le paquet réellement installé à un avis de correction applicable. Un nom de version isolé peut laisser une partie de la question ouverte.
Elle précise une combinaison particulière de configuration et de changement du gestionnaire de sérialisation à l’exécution. L’équipe technique doit lire cette note et vérifier son cas. Cette précaution vient s’ajouter au suivi des avis ; elle ne remplace pas les correctifs du 21 octobre.
Après la correction, vérifier le service et les traces
Le parcours de paiement, la connexion utilisateur et les formulaires importants doivent continuer à fonctionner après intervention. Les responsables devraient conserver les informations du déploiement et examiner les journaux pertinents selon leur procédure de sécurité.
Corriger une version et déterminer si une compromission a eu lieu sont deux travaux différents. Une vulnérabilité présente ne démontre pas une intrusion ; une absence d’alerte ne clôt pas automatiquement l’analyse.
Pour le dirigeant, le livrable attendu peut tenir dans un compte rendu court : périmètre examiné, correction appliquée, service redémarré, fonctions contrôlées et éventuelles suites. Cette trace transforme une inquiétude générale en responsabilité suivie.
Guide documentaire vérifié le 24 octobre 2026 à partir des avis PHP, des deux fiches de vulnérabilité et de Plesk. Aucun serveur tiers n’a été testé ; ce guide ne certifie aucun hébergement.
Questions fréquentes
Mon site est-il piraté s’il utilise une version vulnérable ?
Une vulnérabilité indique une exposition, pas la preuve d’une compromission. Il faut corriger et déterminer, avec les responsables techniques, si des indices imposent une investigation.
La commande php -v suffit-elle à vérifier la correction ?
Elle renseigne sur l’interpréteur appelé en ligne de commande. Le service web peut utiliser un autre binaire, un autre paquet ou un autre conteneur. Il faut vérifier le chemin qui sert réellement les requêtes.
Quelles versions sont corrigées pour les deux failles du 21 octobre ?
Les avis indiquent PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Certains fournisseurs appliquent des correctifs rétroportés : leur avis et la version complète du paquet sont alors nécessaires.
Sources et méthode
Les faits susceptibles d'évoluer ont été revérifiés dans les sources ci-dessous. Les observations et interprétations sont présentées comme telles dans l'article.
