PHP2Shell : les correctifs sont disponibles, comment vérifier et protéger son site WordPress
Mise à jour du 21 octobre 2026, à 21 h 10, heure de Paris (UTC+2).
Les correctifs PHP sont disponibles depuis le 21 octobre. Pour les responsables de sites WordPress, la priorité consiste maintenant à vérifier leur installation effective chez l’hébergeur. OVHcloud annonce avoir corrigé les versions PHP 7.4 à 8.5 sur l’ensemble des clusters de son offre Web Hosting. De son côté, o2switch indique que le déploiement des versions corrigées est en cours sur son infrastructure. Le contrôle de chaque environnement permet de passer d’une annonce générale à une protection vérifiée.
Les versions corrigées sont désormais connues
L’équipe PHP a publié les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12 pour traiter les vulnérabilités CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell. La correction porte sur le moteur PHP exécuté par le serveur. Sur un hébergement mutualisé, son déploiement relève de l’hébergeur ; sur un serveur administré par l’organisation, il relève de l’équipe chargée du système.
La branche et le numéro complet apportent deux informations différentes. L’affichage « PHP 8.4 » désigne une famille de versions. Pour cette alerte, le repère de correction publié par PHP est 8.4.27. Les distributeurs peuvent également intégrer les corrections dans leurs propres paquets, par rétroportage : leur confirmation technique devient alors déterminante. Une migration vers une branche maintenue reste à organiser, notamment pour PHP 8.2 dont le support de sécurité prend fin le 31 décembre 2026. Avis officiel PHP.
Ce que l’attaque pourrait permettre
Les failles concernent la gestion interne de la mémoire et des requêtes par PHP. Selon la configuration, une requête malveillante peut conduire à l’exécution de code à distance avant l’ouverture d’une session utilisateur. L’équipe PHP signale un risque particulièrement élevé avec Apache et mod_php, où une exploitation a été démontrée avant même l’exécution du code de l’application. Avis technique sur la corruption mémoire.
En pratique, les conséquences possibles dépendent des droits du processus compromis. Un attaquant pourrait accéder aux fichiers et aux données accessibles à PHP, récupérer des secrets de configuration, modifier le site ou y déposer du code malveillant. Une compromission peut aussi perturber le service et faciliter des accès ultérieurs. Le relevé d’une version ancienne appelle une vérification des correctifs appliqués, notamment par rétroportage ; l’existence d’une intrusion se détermine par l’examen des journaux, des fichiers et des autres traces techniques. Avis technique sur l’état global résiduel.
o2switch : un déploiement en cours, à confirmer sur chaque hébergement
Dans une réponse de son support communiquée à DPO PARTAGE le 21 octobre, o2switch indique que les versions corrigées sont en cours de déploiement sur son infrastructure. Cette information décrit l’avancement général. La confirmation pour un site donné repose sur la version effectivement exécutée ou sur une réponse du support précisant les correctifs appliqués au serveur concerné.
Pour les utilisateurs de PHP 8.1 ou d’une branche antérieure, le support évoque également la désactivation de l’extension uploadprogress dans cPanel, depuis « Sélectionner une version de PHP ». Il recommande de privilégier PHP 8.2 ou une branche supérieure, avec une sauvegarde préalable et un contrôle de compatibilité des applications, thèmes et extensions. Cette consigne porte sur l’extension désignée par l’hébergeur. Le paramètre interne session.upload_progress.enabled décrit dans l’avis PHP constitue un réglage distinct, à faire qualifier par l’administrateur. Ces mesures d’attente accompagnent l’installation du correctif, qui reste la solution complète. Documentation o2switch sur le choix de PHP.
OVHcloud : des protections temporaires puis une annonce de correction
La chronologie publiée par OVHcloud permet de distinguer les étapes. L’hébergeur indique avoir appliqué une mesure de contournement le 21 octobre à 8 h UTC, soit 10 h à Paris. À 14 h 50 UTC, soit 16 h 50 à Paris, il annonce des règles de filtrage WAF sur tous les clusters et un déploiement des correctifs en cours.
À 17 h 53 UTC, soit 19 h 53 à Paris, OVHcloud déclare que les versions PHP 7.4 à 8.5 ont été corrigées sur l’ensemble des clusters. Ses équipes poursuivent alors le travail sur les versions antérieures. Cette annonce concerne l’offre Web Hosting et les clusters identifiés dans la maintenance. Pour les VPS, serveurs dédiés ou autres environnements, la vérification suit le périmètre propre au service et à son contrat d’administration. La fin de maintenance affichée au 22 octobre à 11 h 18 UTC reste un calendrier global ; l’annonce de 17 h 53 constitue le point d’avancement précis sur les branches déjà corrigées. Suivi officiel OVHcloud.
WordPress : retrouver la version réellement utilisée
Dans l’administration WordPress, le chemin « Outils », « Santé du site », « Informations », puis « Serveur » permet de consulter la version PHP complète. Ce relevé apporte une information plus précise que le simple choix d’une branche dans le panneau d’hébergement. Une capture datée et la confirmation du prestataire constituent des éléments utiles pour le suivi de l’intervention. Documentation WordPress.
La mise à jour du moteur PHP et celle de WordPress interviennent à deux niveaux différents. L’hébergeur traite le moteur ; le mainteneur du site contrôle WordPress, son thème, ses extensions et les fonctions métier après l’intervention. Les formulaires, la connexion, les achats et les envois de messages méritent notamment un test. Une sauvegarde vérifiée et un retour arrière préparé sécurisent les changements de branche.
Protéger le site pendant l’attente du correctif
Lorsque l’installation du correctif demande encore du temps, la mesure la plus prudente consiste à faire isoler l’application PHP du réseau public. Le CERT-EU recommande d’envisager cette isolation pour les applications exposées dont la correction immédiate reste à réaliser. Une interruption temporaire du service peut ainsi être décidée avec l’hébergeur, en tenant compte des besoins de l’activité. Recommandation du CERT-EU.
Notre lecture pratique de cette recommandation consiste à demander un blocage en amont du moteur PHP, au niveau du serveur web, du mandataire inverse ou du réseau, ou une suspension de son exécution pour le site concerné. Une page d’information statique peut être servie séparément. Le prestataire doit couvrir les différents noms de domaine, les accès directs à l’origine, les interfaces et les chemins secondaires. Un accès limité aux seules adresses autorisées peut convenir à certains besoins internes, sous réserve d’une mise en œuvre et d’un contrôle effectifs.
Le mode maintenance d’une extension WordPress s’exécute généralement dans l’application PHP. Pour cette raison, son rôle reste l’affichage d’un message aux visiteurs ; la protection contre une attaque déclenchée avant le code applicatif se place en amont. Les règles WAF et les réglages d’atténuation réduisent certaines possibilités d’attaque pendant cette période. Leur portée dépend de la configuration et des variantes d’exploitation, tandis que la correction du moteur traite les vulnérabilités à leur source. Les paramètres techniques proposés dans l’avis PHP demandent une intervention maîtrisée de l’administrateur, avec contrôle de leurs effets sur la mémoire, les téléchargements et la disponibilité. Mesures techniques et limites de la correction mémoire et de la gestion d’état.
Le vérificateur publié par OpenAI : un premier contrôle à interpréter
OpenAI propose sur GitHub un outil nommé PHP Version Checker. Il s’utilise en ligne de commande ou au travers de deux compétences pour Codex, l’une orientée vers une adresse web, l’autre vers un environnement serveur. Le contrôle distant compare la version annoncée dans les en-têtes HTTP aux seuils de correction intégrés à l’outil. Le mode local examine la version d’un exécutable PHP.
Le résultat « OK » correspond à une comparaison favorable de version. « VULNERABLE » signale une version située dans la plage considérée comme vulnérable. « UNKNOWN » signifie que le contrôle reste indéterminé, notamment lorsque le serveur masque sa version. Les en-têtes peuvent être modifiés et les correctifs rétroportés conserver un numéro antérieur. La conclusion doit donc être rapprochée des informations du fournisseur et du moteur réellement utilisé par le site. Le PHP de la ligne de commande peut également différer de celui qui sert les pages web.
Cet outil aide à orienter les vérifications. La preuve de correction et l’évaluation d’une éventuelle compromission relèvent d’un contrôle complémentaire par l’hébergeur ou l’administrateur. Dépôt officiel et limites du vérificateur OpenAI.
Pour le DPO : documenter la protection et qualifier les incidents
Le responsable du site doit pouvoir identifier le prestataire chargé de PHP, le périmètre concerné, la version corrigée ou le paquet rétroporté et la date de mise en service. La confirmation du prestataire, les contrôles effectués et les éventuelles mesures d’isolation alimentent le dossier de sécurité. Après une suspicion d’attaque, la conservation des journaux et l’analyse des traces permettent de déterminer l’étendue de l’incident et les données concernées.
Lorsqu’une violation de données personnelles est établie, le responsable de traitement documente les faits et évalue le risque pour les personnes. Une violation présentant un risque appelle une notification à la CNIL dans les meilleurs délais et, si possible, dans les 72 heures suivant sa prise de connaissance. En présence d’un risque élevé, l’information des personnes s’apprécie selon les conditions de l’article 34 du RGPD. La correction technique, l’investigation et les obligations de protection des données avancent ainsi de façon coordonnée. Règles de notification de la CNIL.
Deux failles critiques dans PHP : correctif d’urgence et appel à isoler les sites non corrigés- PHP2Shell
Le 20 octobre, l’équipe de sécurité de PHP a publié sur php.net un avis préalable inhabituel. Il annonce une version de sécurité pour le mercredi 21 octobre à 14 h UTC, corrigeant deux failles critiques, et invite tous les utilisateurs à se préparer. L’équipe se réserve le droit d’avancer la publication si des détails deviennent publics ou si une exploitation est constatée. Elle précise que les détails techniques, les versions touchées et les versions corrigées seront publiés avec la mise à jour.
Cette communication fait suite à une fuite. Selon BleepingComputer, un message publié puis supprimé sur le forum Hacker News annonçait deux failles d’exécution de code à distance dans PHP, une divulgation prévue le 22 octobre et une note de 10 sur 10. La société watchTowr a confirmé que les vulnérabilités étaient réelles et dit en avoir reproduit une. Les failles portent les identifiants CVE-2026-109618 et CVE-2026-109619 et circulent sous le surnom de « PHP2Shell ».
La note officielle retenue par l’équipe PHP reste 9,2 en CVSS v4.0. Le chiffre de 10 provient des messages issus de la fuite et n’a pas été confirmé.
Ce qui est confirmé, ce qui ne l’est pas
L’équipe PHP confirme deux vulnérabilités critiques, leur note de 9,2 et la date de publication du correctif. Les autres éléments viennent de chercheurs, d’hébergeurs ou d’agences, et non de l’éditeur.
Le CERT-EU, qui protège les institutions de l’Union européenne, estime qu’une note de 9,2 indique un risque d’exécution de code à distance sans authentification. Avec l’Australian Cyber Security Centre (ACSC), il considère que toutes les versions de PHP depuis la version 5 pourraient être concernées. watchTowr évoque les branches 5, 6, 7 et 8. Le chercheur Kevin Beaumont avance les numéros des futures versions corrigées, 8.5.12, 8.4.27, 8.3.36 et 8.2.35, sans confirmation officielle. Au moment où cet article est rédigé, la page d’actualités de php.net ne mentionne que l’avis préalable : les dernières versions publiées restent celles du 24 septembre 2026.
Les failles se situent dans l’interpréteur PHP lui-même. Tout site qui tourne sur une version vulnérable est donc exposé, quelle que soit l’application : WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel, panneaux d’administration d’hébergement et nombreux logiciels qui embarquent PHP sans l’afficher.
Des risques de vol de données et de prise de contrôle
L’hébergeur GoDaddy indique que ces failles pourraient permettre à un attaquant d’exécuter du code sur un serveur via Internet, avec pour conséquences possibles le vol de données, la défiguration de sites ou la compromission complète du système. GoDaddy rappelle qu’il s’agit d’un problème du langage, qui touche tous les hébergeurs. Il conseille aux propriétaires de sites de se considérer comme concernés tant qu’ils n’ont pas installé la version corrigée.
Les versions 8.1 et antérieures ne sont plus maintenues et ne recevront pas de correctif officiel, selon GoDaddy. PHP ne prend actuellement en charge que les branches 8.2 à 8.5, et le support de sécurité de la 8.2 s’achève le 31 décembre 2026. Les serveurs encore en PHP 7 ou en PHP 5 resteront vulnérables sans migration.
Exploitation : des signaux contradictoires
Les sources divergent sur l’existence d’attaques. L’ACSC indiquait ne pas avoir connaissance d’une exploitation active, et watchTowr disait ne pas en avoir observé malgré la fuite. À l’inverse, la société Patchstack affirme avoir reçu de plusieurs hébergeurs partenaires des signalements d’exploitation, et l’éditeur Aikido rapporte que Cloudflare observe des premières tentatives. Aucune de ces affirmations n’a été confirmée par l’équipe PHP. La fenêtre de risque se situe entre la fuite du 20 octobre et l’application effective du correctif sur chaque serveur.
Les recommandations des agences et des hébergeurs
Le CERT-EU demande aux organisations d’identifier leurs applications fondées sur PHP et de se préparer à les corriger dès la publication des versions corrigées. Lorsque la correction immédiate est impossible, il recommande d’envisager d’isoler des réseaux publics les applications exposées sur Internet jusqu’à l’application du correctif, ce que plusieurs médias ont traduit par une mise hors ligne des sites. L’ACSC donne des consignes proches et ajoute la surveillance des applications pour détecter toute activité malveillante.
L’éditeur de sécurité Wordfence rappelle que les mises à jour automatiques de WordPress n’installent pas le correctif : la version de PHP relève de l’hébergeur ou de l’administrateur du serveur. Les propriétaires de sites doivent donc savoir qui gère cette mise à jour. Un développeur du cœur de PHP a indiqué que seule la mise à jour de PHP protège réellement, et Aikido signale que les réglages de configuration présentés comme contournements ne sont pas fiables. Les règles de pare-feu applicatif proposées par certains acteurs restent une mesure d’attente.
Pour les responsables de traitement
Un site ou une application métier en PHP traite souvent des données personnelles : comptes clients, formulaires de contact, espaces adhérents, prises de rendez-vous. L’article 32 du RGPD impose des mesures de sécurité adaptées au risque. Dans ce contexte, les organisations ont intérêt à recenser sans attendre leurs sites et outils fondés sur PHP, à obtenir de leurs hébergeurs et prestataires la date d’application du correctif, à planifier la migration des versions qui ne seront plus corrigées et à conserver la trace de ces démarches. Si une intrusion venait à être détectée sur un système contenant des données personnelles, l’analyse au titre des articles 33 et 34 du RGPD devrait être menée sans délai, la notification à la CNIL devant intervenir dans les 72 heures lorsque la violation présente un risque pour les personnes.
