PHP corrige deux failles critiques d’exécution de code à distance

Le projet PHP a publié le 21 octobre 2026 un correctif hors cycle pour deux vulnérabilités
critiques d’exécution de code à distance non authentifiée, répertoriées CVE-2026-109618 et
CVE-2026-109619 et notées 9,2 sur l’échelle CVSS v4.0. Les chercheurs à l’origine de la
découverte les ont surnommées « PHP2Shell ». Les versions corrigées, 8.5.12, 8.4.27, 8.3.36
et 8.2.35, sont disponibles depuis le 22 octobre.

#Deux failles non authentifiées, déjà exploitées

Les deux vulnérabilités touchent le traitement de requêtes par les installations PHP
exposées sur le web, sans condition d’authentification préalable. Cloudflare et la société
watchTowr rapportent des tentatives d’exploitation actives dès les heures suivant la
divulgation, ce qui a conduit l’agence américaine CISA à publier une alerte dès le 21 octobre
recommandant une mise à jour immédiate. Un éditeur de sécurité évalue à près de deux millions
le nombre de serveurs PHP potentiellement exposés.

#Aucun contournement de configuration

Le projet PHP précise qu’aucun réglage de configuration ne neutralise entièrement les deux
failles : la mise à jour binaire reste la seule protection complète. Un redémarrage des
processus PHP-FPM ou du serveur applicatif est nécessaire après l’installation du correctif,
faute de quoi l’ancien code vulnérable continue de tourner en mémoire.

#Mettre à jour un serveur en production

Sur une distribution Debian ou Ubuntu avec les dépôts officiels PHP, la procédure se résume
à une mise à jour de paquet suivie d’un redémarrage des services concernés :

php -v
sudo apt update
sudo apt install --only-upgrade php8.4 php8.4-fpm
sudo systemctl restart php8.4-fpm nginx

Les hébergeurs mutualisés et les panneaux comme Plesk ont publié leurs propres builds
corrigées ; les équipes qui gèrent un serveur auto-hébergé
doivent vérifier la version exposée par php -v avant de considérer l’incident clos, y compris
sur les instances où PHP tourne en arrière-plan d’un CMS.

Aucun contournement de configuration ne neutralise complètement les deux failles : seule la mise à jour binaire, suivie d’un redémarrage des processus PHP, ferme la fenêtre d’exposition.

#Un scénario déjà vu sur l’écosystème WordPress

La vitesse de l’exploitation rappelle un schéma déjà documenté sur cette rubrique : une
faille critique WordPress activement attaquée cinq jours après son correctif.
Les sites dont le socle PHP n’est pas durci restent les premières cibles une fois l’exploit
public, quel que soit le CMS installé par-dessus ; les bases d’un hardening WordPress minimal
réduisent la surface d’attaque mais ne remplacent pas la mise à jour de l’interpréteur lui-même.

#Ce qu’il faut retenir

Deux vulnérabilités critiques, exploitables sans authentification et déjà activement
attaquées, touchent l’ensemble des branches PHP maintenues. La correction passe par une mise
à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon la branche utilisée, suivie d’un redémarrage
des processus PHP. Les versions antérieures à 8.2, en fin de vie, n’ont pas de correctif officiel
et doivent être considérées comme à migrer en priorité.

Pour aller plus loin : le changelog officiel PHP 8.x.