Deux failles critiques ont été corrigées dans PHP le 21 octobre 2026 : CVE-2026-109618 et CVE-2026-109619, surnommées php2shell et notées 9,2 sur 10. Elles permettent d'exécuter du code à distance sur un serveur web, sans compte ni mot de passe. Pour s'en protéger, il faut passer en PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon votre branche : d'après l'équipe de PHP, aucun réglage ne remplace la mise à jour.
L'équipe de PHP avait prévenu la veille qu'une publication de sécurité critique arrivait, et des tentatives d'exploitation ont été observées dès le jour de la sortie des correctifs. Si vous administrez un site, une boutique ou un panel en PHP, la mise à jour est à faire sans attendre.
Qui est concerné ?
Toute installation de PHP qui répond à des requêtes web : PHP-FPM derrière Nginx, Apache avec mod_php, php-cgi, LiteSpeed ou FrankenPHP. L'équipe de PHP juge le risque le plus élevé avec Apache et mod_php.
La faille se trouve dans PHP lui-même, pas dans le code du site. Un WordPress, un Laravel ou un panel Pterodactyl parfaitement à jour reste exposé tant que PHP ne l'est pas.
Un serveur de jeu n'est pas concerné en tant que tel : un serveur Minecraft ou un serveur FiveM ne fait pas tourner PHP. Ce qui l'entoure l'est souvent : le site de la communauté, la boutique ou le phpMyAdmin qui sert à gérer la base de données.
Les versions corrigées
Les correctifs sont sortis le 21 octobre 2026 pour les quatre branches encore maintenues :
- PHP 8.5 : version 8.5.12
- PHP 8.4 : version 8.4.27
- PHP 8.3 : version 8.3.36
- PHP 8.2 : version 8.2.35
Toute version antérieure de ces branches est vulnérable. PHP 8.1, 8.0, 7.4 et les versions plus anciennes le sont aussi, et ne recevront pas de correctif.
Pour aller à la source : l'annonce officielle sur php.net, les avis de sécurité de CVE-2026-109618 et de CVE-2026-109619, et en français l'alerte du CERT-FR.
Vérifier la version de PHP de votre site
Le plus fiable est de demander au site lui-même. Déposez à sa racine un fichier info.php qui contient <?php phpinfo(); et ouvrez-le dans le navigateur : la version s'affiche en haut de la page. Supprimez-le juste après, il montre toute la configuration du serveur. Sous WordPress, la même information se trouve dans Outils, Santé du site, onglet Infos, rubrique Serveur.
En ligne de commande, php -v donne la version du terminal. Ce n'est pas toujours celle qui sert le site, surtout quand plusieurs versions sont installées sur la machine.
Avec Plesk ou cPanel, la version de chaque site est indiquée dans la gestion PHP du panel. Ces panels livrent leurs propres paquets PHP et la mise à jour passe par eux : Plesk a publié sa marche à suivre.
Mettre à jour PHP
Sur Debian ou Ubuntu
PHP se met à jour avec le reste du système :
sudo apt update
sudo apt upgradeLes paquets fournis par la distribution gardent leur numéro de version et reçoivent le correctif en interne. C'est donc le suivi de sécurité de Debian ou la page d'Ubuntu qui indique si votre paquet est corrigé, pas le numéro affiché.
Si vous utilisez le dépôt d'Ondřej Surý, très répandu pour installer plusieurs versions de PHP côte à côte, les numéros suivent ceux de php.net : le serveur est corrigé quand la version affichée est celle de la liste plus haut. Ce dépôt publie parfois quelques heures après l'annonce.
Relancez ensuite le service PHP, sinon l'ancienne version continue de tourner en mémoire : sudo systemctl restart php8.3-fpm en adaptant le numéro, ou sudo systemctl restart apache2 avec mod_php.
Avec Docker
Redémarrer un conteneur ne change pas sa version de PHP. Il faut récupérer l'image corrigée puis recréer le conteneur, ou reconstruire votre image si elle part d'une image php :
docker compose pull
docker compose build --pull
docker compose up -dContrôlez ensuite la version dans le conteneur avec docker compose exec <service> php -v.
Sur un hébergement mutualisé
C'est l'hébergeur qui met PHP à jour. Vérifiez la version vue par votre site avec la méthode plus haut : si elle n'a pas changé d'ici un ou deux jours, posez la question à son support.
Encore en PHP 7 ou 8.1
L'équipe de PHP ne maintient plus ces versions : aucun correctif ne sortira pour PHP 8.1, 8.0, 7.4 ni les branches plus anciennes. La seule solution durable est de changer de branche. Visez PHP 8.4 ou 8.5, maintenues jusqu'à fin 2028 et fin 2029 : la 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026.
Certaines distributions maintiennent toutefois leur propre paquet PHP pendant toute leur durée de support, comme Ubuntu 22.04 avec PHP 8.1. Leur page de suivi de la faille dit si un correctif est disponible.
Un changement de branche demande de vérifier la compatibilité du site (version du CMS, extensions, modules). Si la migration prend du temps, limitez en attendant à vos seules adresses IP l'accès aux pages qui n'ont pas besoin d'être publiques, comme phpMyAdmin ou l'administration du site. Cela réduit l'exposition, sans corriger la faille.
Après la mise à jour
Les premières tentatives d'exploitation ont eu lieu le 21 octobre, avant que tous les serveurs soient corrigés. Si le vôtre est resté exposé, vérifiez au moins ces trois points :
- des fichiers PHP inconnus, ou modifiés depuis le 20 octobre, dans le dossier du site (
find /var/www -name "*.php" -newermt 2026-10-20les liste) ; - des comptes administrateurs que vous n'avez pas créés, dans le CMS comme sur le serveur ;
- des tâches planifiées ajoutées dans la crontab.
Au moindre doute, restaurez une sauvegarde antérieure au 20 octobre, puis changez les mots de passe et les clés enregistrés sur le serveur : base de données, API, accès FTP et SSH.
Questions fréquentes
Qu'est-ce que php2shell ?
C'est le surnom donné par des chercheurs en sécurité aux failles CVE-2026-109618 et CVE-2026-109619. Toutes deux permettent d'exécuter du code à distance sur un serveur qui fait tourner PHP, sans être connecté.
Quelles versions de PHP sont vulnérables ?
Toutes les versions antérieures à 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ainsi que les anciennes branches PHP 8.1, 8.0, 7 et 5, qui ne seront pas corrigées.
Mon site WordPress est-il concerné ?
Oui, comme tout site en PHP, quelles que soient les versions de WordPress et de ses extensions. Mettre à jour WordPress ne suffit pas : c'est PHP qu'il faut mettre à jour, vous-même sur un serveur que vous administrez, votre hébergeur sur un hébergement mutualisé.
PHP 7.4 ou 8.1 recevra-t-il un correctif ?
Pas de la part de l'équipe de PHP, ces branches sont en fin de vie. Seules certaines distributions corrigent encore leur propre paquet pendant leur durée de support. Dans tous les autres cas, il faut passer en PHP 8.3, 8.4 ou 8.5.
Un réglage dans php.ini suffit-il en attendant ?
Non. Des contournements circulent depuis l'annonce, mais l'équipe de PHP précise qu'aucun ne protège complètement : la mise à jour est la seule solution sûre.
Faut-il redémarrer le serveur après la mise à jour ?
Pas forcément la machine, mais le service PHP : PHP-FPM, ou Apache s'il utilise mod_php. Tant qu'il n'a pas redémarré, l'ancienne version reste en mémoire.
Mon hébergeur s'occupe-t-il de la mise à jour ?
Sur un hébergement mutualisé, oui. Sur un VPS Linux ou un serveur dédié, c'est vous qui administrez le système, sauf offre infogérée : la mise à jour de PHP vous revient, comme celle des autres paquets.
Quelle version de PHP choisir pour migrer ?
La plus récente que votre CMS et ses extensions prennent officiellement en charge. PHP 8.4 est maintenue jusqu'à fin 2028 et PHP 8.5 jusqu'à fin 2029. La 8.2 s'arrête le 31 décembre 2026 : ce n'est plus un bon choix pour une migration.
