En clair, pour un propriétaire de site
WordPress ne fonctionne pas tout seul : il est écrit en PHP, un langage exécuté par votre serveur. Mettre WordPress à jour ne met pas PHP à jour. Ce sont deux étages différents, et seul le premier est visible depuis votre tableau de bord.
Le 21 octobre 2026, l’équipe PHP a publié en urgence des correctifs pour deux failles critiques, notées 9,2 sur 10, surnommées PHP2Shell. Elles permettent, dans certaines configurations, une exécution de code à distance sans authentification. Un site WordPress irréprochable côté extensions peut être touché par l’étage du dessous.
La bonne nouvelle : chez la plupart des hébergeurs mutualisés, la mise à jour de PHP est faite par l’hébergeur, et elle a été déployée dans les jours suivants. La question à se poser n’est donc pas « ai-je mis PHP à jour ? » mais « sur quelle version mon site tourne-t-il aujourd’hui ? »
Détail technique
- CVE-2026-109618 : usage après libération et divulgation de mémoire dans le suivi de progression d’envoi de fichiers.
- CVE-2026-109619 : confusion de types impliquant les traces d’erreur fatale et OPcache, avec un chemin d’attaque confirmé passant par le suivi de progression d’envoi.
Les deux sont notées 9,2 en CVSS v4.0. Des chercheurs ont démontré l’exploitation contre Magento 2.4.9 et une dizaine d’autres applications PHP. La publication a été avancée après une fuite des détails, la veille de la date de divulgation prévue.
Point important sur la mitigation, souvent mal relayé : désactiver session.upload_progress.enabled ne couvre que l’une des deux failles. La CVE-2026-109618 reste exploitable. L’avis officiel est explicite : la mise à jour est le seul correctif complet.
Synthèse
| Composant | PHP (couche serveur sous WordPress) |
| Identifiants | CVE-2026-109618 et CVE-2026-109619, dites « PHP2Shell » |
| Type | Usage après libération, divulgation mémoire, confusion de types |
| Gravité | 9,2 / 10 (CVSS v4.0) — critique |
| Versions corrigées | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| Sans correctif officiel | PHP 8.1 et antérieur |
| Authentification requise | Non |
| Exploitation connue | Premières tentatives rapportées dès le jour de la publication |
| Vérifié le | 22 octobre 2026 |
Le vrai point sensible pour WordPress : les versions anciennes
PHP 8.1 et antérieur ne reçoivent aucune version corrigée officielle. Des rétroportages du code source existent pour 7.4, 8.0 et 8.1, mais ce n’est pas une mise à jour que l’on installe depuis un panneau d’hébergement.
Or une part importante des sites WordPress en production tourne encore sur ces branches, souvent parce qu’une extension ancienne ou un thème sur mesure n’a jamais été testé au-delà. Si votre hébergement est en 7.4, 8.0 ou 8.1, migrer n’est plus une optimisation de performance : c’est devenu le correctif.
Comment vérifier votre version de PHP
Dans l’administration WordPress : Outils → Santé du site → Informations → onglet Serveur. La version de PHP y est affichée telle que le serveur l’exécute.
Si elle commence par 8.2, 8.3, 8.4 ou 8.5, comparez-la au numéro corrigé du tableau ci-dessus — une version 8.3.35, par exemple, est antérieure au correctif. Si elle commence par 7., 8.0 ou 8.1, le sujet n’est plus le correctif mais la migration.
Ce que votre hébergeur a probablement déjà fait
Les grands hébergeurs mutualisés déploient ces correctifs eux-mêmes, sur l’ensemble de leurs parcs, sans intervention de votre part. OVHcloud a ainsi annoncé sur sa page d’état, le 21 octobre 2026, avoir appliqué les correctifs à ses versions PHP de 7.4 à 8.5 sur l’ensemble de ses clusters.
Deux réserves à garder en tête :
- Le correctif s’applique à la version que vous avez choisie. Si votre hébergement est configuré sur une branche ancienne, un correctif déployé sur les branches récentes ne vous concerne pas.
- En cas d’indisponibilité, commencez par la page d’état de votre hébergeur. Les incidents d’infrastructure et les opérations de maintenance y sont publiés, et c’est le premier endroit à consulter avant de conclure à une attaque. Nous n’établissons ici aucun lien entre un incident particulier et ces correctifs : seul l’hébergeur peut déterminer la cause d’une panne.
Comment savoir si votre site a été touché
Ces failles visent le moteur PHP, pas WordPress : les traces ne sont pas dans votre tableau de bord mais côté serveur.
- erreurs fatales PHP répétées et inhabituelles dans les journaux ;
- pics de consommation processeur ou mémoire sans rapport avec votre trafic ;
- requêtes d’envoi de fichiers répétées vers des points d’entrée qui n’acceptent normalement aucun envoi ;
- fichiers PHP apparus hors des emplacements habituels.
L’absence de trace n’est pas une preuve d’absence de problème : sur un hébergement mutualisé, les journaux sont souvent conservés peu de temps.