Faille de sécurité PHP CVE-2026-109618 : php2shell, ce que l'on sait et quelles versions mettre à jour

TL;DRLe 20 octobre 2026, l'équipe de sécurité de PHP a annoncé en urgence deux failles critiques, corrigées le 21 octobre à 14:00 UTC. La première, référencée CVE-2026-109618 et surnommée « php2shell », pourrait permettre d'exécuter du code à distance sur un serveur. Voici ce qui est confirmé, ce qui ne l'est pas encore, et ce que vous devez faire selon votre version de PHP.

Article publié le 21 octobre 2026 au matin, avant la publication officielle. PHP a promis de publier « les détails complets, les versions concernées et les versions corrigées » avec ses correctifs, prévus le 21 octobre 2026 à 14:00 UTC (16:00 à Paris). Ce qui suit distingue ce que PHP a confirmé de ce qui circule encore à l'état de fuite. Vérifiez toujours l'annonce sur php.net avant d'agir.

📌 Que s'est-il passé ?#

Le 20 octobre 2026, l'équipe de sécurité de PHP a publié sur php.net un message inhabituel : un préavis de publication de sécurité. Le texte est court. Il annonce une publication « le mercredi 21 octobre 2026 à 14:00 UTC », qui « corrige deux vulnérabilités critiques, toutes deux notées CVSS v4.0 9.2 », et encourage « tous les utilisateurs de PHP à se préparer dès maintenant afin de mettre à jour dès que la publication sera disponible ».

PHP précise aussi qu'il se réserve le droit de publier plus tôt « si les détails de l'une ou l'autre vulnérabilité devenaient publics, ou si des preuves d'exploitation active apparaissaient ». Ce préavis a été donné parce que des informations avaient déjà fuité : des messages sur les réseaux sociaux évoquaient une faille d'exécution de code à distance dans le cœur de PHP, avec une note de 10, avant que PHP ne la ramène officiellement à 9.2.

📌 Qu'est-ce que CVE-2026-109618 ?#

CVE-2026-109618 est l'identifiant attribué à la première des deux failles, la seconde étant CVE-2026-109619, à laquelle nous consacrons un article séparé. Les chercheurs ont surnommé l'ensemble php2shell, en référence à ce que permettrait une attaque réussie : obtenir un accès de type « shell », c'est-à-dire exécuter ses propres commandes sur le serveur.

Il faut être précis sur l'origine de chaque information :

Tenable décrit la faille comme un défaut qui, enchaîné avec une autre vulnérabilité de PHP, permettrait l'exécution de code à distance. Sansec et watchTowr parlent de deux failles d'exécution de code à distance. PHP, de son côté, ne détaille ni le composant concerné ni le type de bug : ces informations sont attendues avec le correctif.

📌 Pourquoi c'est sérieux#

Une note de 9.2 sur 10 place ces failles dans la catégorie « critique ». Trois éléments rendent la situation particulière :

• La faille est dans PHP, pas dans une extension ou un CMS. Mettre à jour WordPress, PrestaShop ou Drupal ne suffit pas : c'est l'interpréteur PHP du serveur qu'il faut mettre à jour.
• PHP est partout. Une large part des sites web tourne avec PHP, des petits sites vitrines aux boutiques en ligne.
• Les détails techniques ont en partie fuité. Sansec s'attend à des attaques massives dans les quinze minutes suivant la publication, le temps pour des attaquants de comparer le code corrigé à l'ancien.

Bon à savoir. « Pas d'exploitation signalée » ne veut pas dire « pas de risque ». Quand un correctif est publié, il révèle où se trouvait le bug. Les serveurs qui ne sont pas mis à jour dans les heures qui suivent sont les premières cibles des robots d'attaque.

🎯 Quelles versions de PHP sont concernées ?#

PHP n'a pas encore publié la liste officielle. Les rapports de chercheurs évoquent toutes les versions depuis PHP 5 (Sansec parle de PHP 5.4 et suivantes), mais ce n'est pas confirmé. Ce qui est plus sûr, c'est la politique de maintenance de PHP : seules les branches encore prises en charge reçoivent des correctifs de sécurité.

Des numéros de versions corrigées circulent déjà (8.5.12, 8.4.27, 8.3.36 et 8.2.35), mais il s'agit de déductions de chercheurs à partir de la numérotation habituelle. Fiez-vous uniquement à l'annonce officielle de php.net.

📌 Comment connaître votre version de PHP#

Sur un serveur auquel vous avez accès en SSH, attention : la version de PHP en ligne de commande n'est pas forcément celle qui sert votre site. Vérifiez les deux.

# Version de PHP en ligne de commande
php -v
# Versions de PHP-FPM installées et actives (Debian / Ubuntu)
ls /etc/php/
systemctl list-units 'php*-fpm*' --no-pager

Pour connaître la version qui exécute réellement votre site, créez temporairement un fichier contenant <?php echo PHP_VERSION; à la racine du site, ouvrez-le dans le navigateur, puis supprimez-le immédiatement. Sur un hébergement mutualisé, la version apparaît en général dans le panneau de gestion de l'hébergeur. Dans WordPress, elle figure dans Outils > Santé du site > Informations > Serveur.

📌 Que faire maintenant, étape par étape#

1. Faites l'inventaire. Listez tous vos sites et serveurs PHP, y compris les outils internes, les anciens sites oubliés et les logiciels qui embarquent leur propre PHP. Huntress insiste sur ce point : on ne protège pas ce qu'on ignore.
2. Appliquez la mesure temporaire. Désactivez session.upload_progress.enabled, une fonction rarement utilisée. Nous détaillons la méthode, ses limites et les contrôles à faire dans notre article sur CVE-2026-109619.
3. Préparez la mise à jour. Prévoyez une fenêtre d'intervention ce mercredi après 16:00 (heure de Paris), avec une sauvegarde récente.
4. Installez la version corrigée dès sa publication, puis redémarrez PHP-FPM ou Apache : tant que les processus PHP n'ont pas redémarré, l'ancienne version reste en mémoire.
5. Pour PHP 8.1 et antérieur, restreignez l'accès aux applications concernées (VPN, liste d'adresses IP, pare-feu applicatif) et lancez la montée de version.

# Debian / Ubuntu : après publication des paquets corrigés
sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt upgrade
# Redémarrer PHP-FPM (adaptez le numéro de version)
sudo systemctl restart php8.4-fpm
# Vérifier la version en service
php -v

Si vous utilisez les paquets de votre distribution, le correctif arrive par ses mises à jour de sécurité, parfois avec un décalage de quelques heures ou jours par rapport à php.net. Avec Docker, il faudra reconstruire vos images à partir d'une image PHP mise à jour, puis redéployer les conteneurs.

📌 Faut-il couper son site ?#

Certains messages alarmistes conseillent de couper toutes les applications PHP. Pour un site sur une branche maintenue, ce n'est pas nécessaire : appliquez la mesure temporaire, puis mettez à jour dès la publication. La question se pose en revanche pour une application exposée sur internet, sur une version de PHP qui ne sera pas corrigée et qui manipule des données sensibles. Dans ce cas, restreindre l'accès, voire mettre l'application hors ligne le temps de la montée de version, est une décision raisonnable.

📌 Vous êtes hébergé chez Websource ?#

Websource héberge un grand nombre de sites PHP (WordPress, PrestaShop, Symfony, Drupal, Joomla…) et suit cette publication de sécurité. Si votre site tourne sur une ancienne version de PHP, ou si vous voulez savoir où en est votre hébergement, écrivez-nous : nous vous aidons à évaluer votre exposition et à préparer la montée de version, que vous soyez hébergé chez nous ou ailleurs. Pour un nouveau projet, nos offres d'hébergement web incluent des versions de PHP maintenues.

❓ Questions fréquentes#

🛒 CVE-2026-109618 concerne-t-elle WordPress ou PrestaShop ?#

Elle concerne PHP lui-même, donc tout site qui fonctionne avec PHP, quel que soit le CMS ou le framework. Mettre à jour le CMS ne corrige pas la faille : c'est la version de PHP du serveur qu'il faut mettre à jour.

📌 Quand le correctif est-il disponible ?#

PHP a annoncé sa publication pour le mercredi 21 octobre 2026 à 14:00 UTC, soit 16:00 à Paris, en se réservant le droit de l'avancer si la faille était exploitée.

📌 Mon site est en PHP 7.4, que faire ?#

PHP 7.4 n'est plus maintenu et ne devrait pas recevoir de correctif. Appliquez la mesure temporaire, limitez l'accès à l'application si elle est sensible et planifiez rapidement le passage à une version maintenue de PHP 8.

🔒 La faille est-elle déjà exploitée ?#

Au matin du 21 octobre 2026, watchTowr et Huntress ne signalaient aucune exploitation active. Des attaques automatisées sont toutefois attendues peu après la publication du correctif.

📌 Pourquoi la note est-elle de 9.2 et pas de 10 ?#

La note de 10 circulait dans la fuite initiale. L'équipe de sécurité de PHP a officiellement attribué la note de 9.2 selon la méthode CVSS v4.0, ce qui reste une gravité critique.

Article publié le 21/10/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.