Le 21 octobre 2026, le projet PHP a publié en urgence les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux failles d’exécution de code à distance, CVE-2026-109618 et CVE-2026-109619, surnommées « PHP2Shell ». Elles sont notées 9,2 sur 10 (CVSS v4) et peuvent être déclenchées sans compte. Elles se trouvent dans le moteur PHP lui-même : aucune mise à jour de WordPress, d’extension ou de thème ne les corrige.
Cet article résume ce que les sources publiques établissent, explique comment vérifier votre propre version sans vous laisser piéger par les numéros, et rapporte ce que nous avons mesuré sur ce blog, qui tourne en PHP 8.2.35 depuis le 21 octobre à 15 h 56 UTC.
Ce qui a été corrigé, et dans quelles versions
| Branche PHP | Version corrigée | Statut |
|---|---|---|
| 8.5 | 8.5.12 | Maintenue |
| 8.4 | 8.4.27 | Maintenue |
| 8.3 | 8.3.36 | Maintenue |
| 8.2 | 8.2.35 | Correctifs de sécurité jusqu’au 31 décembre 2026 |
| 8.1 et antérieures | Aucune version officielle | Correctifs de code source publiés, rétroportés par certaines distributions |
D’après l’analyse de Sansec, il s’agit de deux erreurs de « use-after-free » (réutilisation de mémoire déjà libérée). La première (CVE-2026-109618) touche le décodage de la progression d’envoi de fichiers ; la seconde (CVE-2026-109619) touche la trace d’une erreur fatale, combinée à un défaut de typage dans OPcache. Le point de départ est une erreur fatale en cours de requête, le plus souvent un dépassement de memory_limit. Tous les déclencheurs connus sont des requêtes multipart/form-data, que PHP analyse avant d’exécuter le code de l’application. Le code concerné existe depuis PHP 5.4.0.
Chronologie et état de l’exploitation
- 20 octobre : les détails fuitent sur les réseaux sociaux, avant la divulgation prévue le 22 ;
- 21 octobre, 07 h 43 UTC : Cloudflare signale les premières attaques ;
- 21 octobre, 14 h 00 UTC : PHP publie les versions corrigées ;
- 22 octobre : Sansec estime l’exploitation de masse moins probable qu’annoncé, car les preuves de concept publiques ne fonctionnent pas sur une installation par défaut et exigent le plus souvent une autre faille dans l’application, comme une inclusion locale de fichier.
Les sources ne s’accordent pas sur l’ampleur réelle : watchTowr rapporte des tentatives d’exploitation actives, tandis que la CISA indiquait n’en avoir observé aucune à la publication de son alerte. Même nuancé, le risque justifie de mettre à jour le jour même : le code vulnérable date de PHP 5.4 et les détails sont publics.
Pourquoi WordPress ne publie pas de mise à jour
Selon le point fait par Codeable, WordPress.org indique qu’aucune mise à jour de WordPress n’est requise ni prévue : le correctif est celui de PHP, appliqué par votre hébergeur ou par vous si vous administrez le serveur. Sur un hébergement mutualisé ou géré, surveillez l’avis de votre hébergeur et demandez-lui confirmation. Sur un VPS, c’est à vous d’agir.
Vérifier sa version sans se faire piéger
- Version affichée : dans WordPress, Outils → Santé du site → Info → Serveur, ou
php -ven ligne de commande. Une version 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 est corrigée. - Rétroportages : une distribution peut corriger la faille sans changer le numéro. Sur Debian ou Ubuntu, cherchez l’identifiant dans le journal des changements du paquet (adaptez le nom à votre branche) :
zgrep CVE-2026-109618 /usr/share/doc/php8.2-common/changelog.Debian.gzSi la commande renvoie une ligne, le correctif est présent. Un PHP compilé depuis les sources officielles, comme le nôtre, n’a pas de journal de paquet : seul son numéro de version fait foi.
Redémarrez PHP-FPM. Tant que le service n’est pas redémarré, les processus déjà lancés gardent l’ancien code en mémoire. Vérifiez ensuite quel binaire tourne réellement :
systemctl restart php8.2-fpm
ls -l /proc/$(systemctl show -p MainPID --value php8.2-fpm)/exeCe que nous avons constaté sur wpmoderne.fr
- Version : PHP 8.2.13 jusqu’au 21 octobre, puis 8.2.35 à 15 h 56 UTC, soit moins de deux heures après la publication des correctifs. Aucun paquet à jour n’existait pour notre distribution : nous avons compilé PHP 8.2.35 à partir des sources officielles, avec les mêmes extensions. Le processus maître de PHP-FPM, démarré à cette heure-là, pointe bien vers ce binaire.
- Requêtes POST avant la bascule (20 octobre 00 h 00 → 21 octobre 15 h 56 UTC) : 45 au total, toutes vers des points d’entrée WordPress connus (
admin-ajax.php,wp-comments-post.php, l’API REST, la page d’accueil). Les POST vers/index.phpet versbatch/v1ont tous reçu un refus 401. Aucun ne visait un fichier PHP inattendu. - Intégrité :
wp core verify-checksumsne signale aucun écart ; aucun fichier.phpdansuploads; aucun fichier PHP modifié depuis le 20 octobre en dehors des extensions que nous avons nous-mêmes mises à jour ; - Journaux : aucun « Allowed memory size exhausted » ni « Out of memory » dans les journaux PHP et nginx du site, et aucun processus PHP-FPM du pool tué par un signal de plantage.
La limite de ce contrôle : notre journal nginx n’enregistre pas l’en-tête Content-Type. Nous ne pouvons donc pas isoler les requêtes multipart/form-data, qui sont le déclencheur connu, et nous ne pouvons pas prouver l’absence de tentatives, seulement l’absence de trace d’une compromission. Ajouter $content_type au log_format de nginx permet de disposer de cette information la prochaine fois.
Si vous ne pouvez pas mettre à jour tout de suite
Ces mesures, relevées par Sansec, réduisent l’exposition sans la supprimer, et nous ne les avons pas testées : la mise à jour a suffi. Elles ne remplacent pas le correctif.
- désactiver la progression d’envoi de PHP :
session.upload_progress.enabled = 0(WordPress ne l’utilise pas, d’après Codeable ; la valeur par défaut est activée, comme nous l’avons vérifié) ; - bloquer temporairement les requêtes
multipart/form-dataau niveau du serveur web, ce qui coupe aussi l’envoi de médias dans l’administration ; - activer les règles WAF de votre fournisseur. Cloudflare en a déployé sur tous les plans, mais un attaquant qui atteint directement votre serveur les contourne.
Sansec cite aussi la suppression de memory_limit comme contre-mesure partielle. Nous la déconseillons sans surveillance de la mémoire du serveur : elle ouvre un autre risque.
Si vous êtes en PHP 8.1 ou plus ancien
Le projet PHP ne publie plus de version pour ces branches. Des correctifs de code source existent pour 7.4, 8.0 et 8.1, que certaines distributions ont rétroportés. Sans paquet corrigé, la seule solution durable est de passer en 8.2 ou plus récent, après une copie de sauvegarde et un test des extensions et du thème sur une copie du site. La CISA recommande, à défaut, de mettre hors ligne les systèmes PHP qui ne peuvent pas être corrigés.
À retenir
- Deux failles critiques du moteur PHP, corrigées le 21 octobre 2026 dans les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
- WordPress, les extensions et les thèmes n’y sont pour rien : seul le correctif de PHP, appliqué sur le serveur, protège.
- Vérifiez le numéro de version et le redémarrage de PHP-FPM, car un rétroportage peut conserver l’ancien numéro.
- Après correction, contrôlez les fichiers PHP récents, l’intégrité du cœur et les journaux : l’exploitation a pu précéder le correctif.
Sources : annonce PHP 8.2.35, Sansec, CISA, Codeable, The Hacker News.
Méthode : article rédigé le 22 octobre 2026 à partir des sources ci-dessus et de contrôles réalisés le même jour sur ce serveur, avec l’aide d’un assistant IA pour la recherche et la rédaction. Les chiffres de la section « Ce que nous avons constaté » proviennent de nos propres journaux et commandes. Les informations sur l’exploitation évoluent vite : consultez l’avis officiel de PHP pour l’état le plus récent.
