Failles PHP2Shell : votre site WordPress est-il à jour ?
Deux failles critiques de PHP, corrigées le 21 octobre 2026, touchent WordPress et tous les sites PHP. Versions sûres, vérifications, alerte de la DGSSI.
Votre site WordPress est à jour seulement s’il tourne sous PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou une version plus récente, et si ses services PHP ont été redémarrés depuis. Le 21 octobre 2026, l’équipe de PHP a corrigé deux failles critiques, surnommées « PHP2Shell », qui permettent de prendre le contrôle d’un serveur à distance sans mot de passe. La DGSSI a classé le risque « critique » le jour même. Voici ce qui s’est passé, comment vérifier votre site en deux minutes et quoi demander à votre hébergeur.
Ce qui s’est passé du 20 au 26 octobre
Le 20 octobre, l’équipe de sécurité de PHP a annoncé une mise à jour pour le lendemain, contre deux failles notées 9,2 sur 10 (CVSS v4.0). Le 21 octobre, elle a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, avec un message sans ambiguïté : tous les utilisateurs doivent mettre à jour « immédiatement », et il n’existe pas de parade complète en dehors de la mise à jour.
Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619. Selon l’avis de sécurité de PHP, toutes les installations qui servent des pages web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé avec mod_php : l’équipe de PHP y a démontré une attaque qui part d’une simple requête, sans connexion, avant même que le code du site ne s’exécute. Une extension de sécurité WordPress n’a donc aucune prise sur ce cas.
Au Maroc, la Direction générale de la sécurité des systèmes d’information (DGSSI) a publié le 21 octobre le bulletin 69782110/26, avec un risque et un impact « critiques ». Elle précise qu’un code d’exploitation est disponible, ce qui augmente le risque de compromission.
L’exploitation, elle, a évolué en quelques jours. Dans son alerte mise à jour le 23 octobre, le Centre canadien pour la cybersécurité écrivait n’avoir observé aucune exploitation active. Le 26 octobre, l’agence américaine de cybersécurité (CISA) a ajouté les deux failles à son catalogue des vulnérabilités exploitées, qui ne recense que des failles dont l’exploitation est avérée, et a fixé au 29 octobre la date limite de correction pour les administrations fédérales américaines.
Votre site est-il concerné ?
Oui si votre site ou votre application tourne avec PHP. C’est le cas de WordPress et WooCommerce, mais aussi de PrestaShop, Joomla, Drupal, Magento et des applications sur mesure écrites avec Laravel ou Symfony.
Les failles sont dans PHP, pas dans WordPress : mettre à jour WordPress, son thème ou ses extensions ne corrige rien. Seule la version de PHP du serveur compte.
À l’inverse, un logiciel qui n’utilise pas PHP n’est pas visé. Odoo, par exemple, est écrit en Python. Un site statique, qui sert des fichiers déjà générés, n’exécute pas PHP non plus. Vérifiez quand même qu’aucun autre site en PHP ne tourne sur le même serveur.
Les versions corrigées
| Branche de PHP | Version corrigée | Situation au 27 octobre 2026 |
|---|---|---|
| 8.5 | 8.5.12 | maintenue |
| 8.4 | 8.4.27 | maintenue |
| 8.3 | 8.3.36 | maintenue |
| 8.2 | 8.2.35 | plus de correctif de sécurité après le 31 décembre 2026 |
| 8.1 et plus ancien | aucune version officielle | correctif seulement via l’hébergeur, la distribution Linux ou un fournisseur de support |
Pour PHP 8.1 et les versions plus anciennes, le projet PHP ne publie plus de mise à jour. Vu la gravité des failles, son équipe a tout de même mis à disposition des correctifs minimaux en code source pour PHP 7.4, 8.0 et 8.1. Ils servent aux administrateurs qui compilent PHP eux-mêmes : pour un site en hébergement mutualisé, c’est à l’hébergeur de les appliquer, ou de vous faire passer à une branche maintenue.
Un tiers des sites WordPress sur une version non maintenue
Les statistiques publiques de WordPress, consultées le 27 octobre 2026, montrent que 33,6 % des sites WordPress déclarent tourner sur PHP 8.1 ou une version plus ancienne. PHP 7.4, à lui seul, représente 15,1 % des sites. Ces chiffres sont mondiaux : nous n’avons trouvé aucune donnée publiée pour le Maroc.
WordPress recommande PHP 8.3 ou plus récent. Il fonctionne encore avec PHP 7.4, mais sa propre page de prérequis rappelle que ces anciennes versions sont en fin de vie et peuvent exposer le site à des failles. PHP2Shell en est l’illustration.
Ce que vous devez faire cette semaine
- Lire la version de PHP de votre site. Dans WordPress, ouvrez Outils, puis Santé du site, onglet Infos, rubrique Serveur. Notez la version exacte, par exemple 8.3.36, et pas seulement 8.3.
- En hébergement mutualisé, écrire à l’hébergeur. C’est lui qui met PHP à jour. Demandez-lui la version exacte installée et la confirmation que les services PHP ont été redémarrés après la mise à jour.
- Sur un serveur dédié ou un VPS, mettre à jour puis redémarrer. La DGSSI le souligne dans son bulletin 69832210/26 : installer le paquet ne suffit pas, il faut redémarrer PHP-FPM ou Apache, et recréer les conteneurs Docker à partir de la nouvelle image. Sinon, l’ancien moteur vulnérable continue de répondre.
- Ne pas confondre parade temporaire et correctif. Les réglages proposés en attendant, comme
session.upload_progress.enabled=0ou un filtrage par un pare-feu applicatif, réduisent l’exposition mais ne protègent pas complètement. PHP et la DGSSI le disent tous les deux. - Si vous êtes en PHP 8.1 ou plus ancien, planifier la migration. Sauvegarde complète, test sur une copie du site, vérification du thème et des extensions, puis passage à PHP 8.3 ou 8.4. Une version récente de PHP rend aussi souvent le site plus rapide : c’est l’une des corrections de notre article sur les sites WordPress lents.
Une troisième faille, moins probable
Le 23 octobre, PHP a signalé une autre faille possible, CVE-2026-115560. Elle ne se déclenche qu’avec une combinaison inhabituelle de réglages et de code, et les versions du 21 octobre ne la corrigent pas. En attendant la prochaine version régulière, PHP conseille le réglage session.upload_progress.enabled=0. Si votre hébergeur l’a déjà appliqué pour PHP2Shell, il n’y a rien de plus à faire.
La DGSSI demande de vérifier toute la chaîne
Le 22 octobre, la DGSSI a complété son alerte par le bulletin 69872210/26. Elle invite les organisations à prévenir leurs prestataires d’hébergement, de développement, d’intégration et de maintenance, à vérifier les API et les échanges de données avec leurs partenaires, et à renforcer la surveillance pour repérer une tentative d’intrusion.
Pour une PME, cela tient en une liste : votre site vitrine, votre boutique en ligne, votre extranet ou votre application métier, et le nom de la personne qui s’occupe de chacun. Si personne n’est chargé des mises à jour, c’est le moment d’y remédier, avec un contrat de maintenance ou en interne. Pour une boutique en ligne, les enjeux sont plus lourds : commandes, comptes clients et données personnelles passent par le même serveur.
Si vous ne savez pas qui gère votre serveur, ou si votre site tourne encore en PHP 7.4, écrivez-nous : nous vérifions la version, l’hébergement et la marche à suivre avec vous.
Sources
- PHP, avis de sécurité « Critical remote code execution vulnerabilities, update now », 21 octobre 2026, et annonce préalable, 20 octobre 2026.
- PHP, annonce de PHP 8.2.35 (fin des correctifs de sécurité de PHP 8.2 au 31 décembre 2026), 21 octobre 2026, et avis sur CVE-2026-115560, 23 octobre 2026.
- DGSSI, bulletins 69782110/26 du 21 octobre 2026, 69872210/26 et 69832210/26 du 22 octobre 2026.
- CISA, catalogue des vulnérabilités exploitées, ajout du 26 octobre 2026.
- Centre canadien pour la cybersécurité, alerte AL26-026, 21 octobre 2026, mise à jour du 23 octobre 2026.
- WordPress.org, statistiques des versions de PHP et prérequis, consultés le 27 octobre 2026.
Article à jour au 27 octobre 2026.
