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

TL;DRLe 21 octobre 2026, PHP a corrigé en urgence deux failles critiques, notées 9.2 sur 10, qui permettent d'exécuter du code à distance sur un serveur sans être authentifié. La première, CVE-2026-109618, fait partie du duo surnommé « php2shell ». Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, et des tentatives d'exploitation sont déjà signalées. Voici ce qui est confirmé, quelles versions installer et que faire si vous ne pouvez pas mettre à jour tout de suite.

Mise à jour du 22 octobre 2026. PHP a publié les correctifs le 21 octobre 2026 à 14:00 UTC (16:00 à Paris) : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. L'avis officiel confirme les numéros CVE-2026-109618 et CVE-2026-109619 et décrit les deux failles. Des tentatives d'exploitation sont signalées par plusieurs éditeurs de sécurité. Cet article, publié le 21 au matin avant l'annonce, a été mis à jour avec ces informations : la seule protection complète est désormais d'installer la version corrigée.

📌 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.

Le 21 octobre 2026 à 14:00 UTC, PHP a publié comme prévu ses correctifs, accompagnés d'un avis de sécurité titré « vulnérabilités critiques d'exécution de code à distance, mettez à jour maintenant ». Les distributions Linux et les fournisseurs de versions à support étendu avaient reçu les correctifs à l'avance. Amazon indique avoir observé une première tentative d'exploitation dès le 17 octobre, quatre jours avant l'annonce, et plusieurs programmes d'attaque publiés dans les heures qui ont suivi la levée de l'embargo.

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

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

L'avis officiel de PHP la décrit ainsi : lorsqu'une erreur de dépassement de mémoire (« out of memory ») survient, PHP peut être interrompu alors que certaines données internes de la requête ne sont que partiellement initialisées. Le nettoyage de fin de requête peut ensuite traiter ces données invalides comme valides, ce qui ouvre la voie à l'exécution de code. La seconde faille repose sur un autre mécanisme : un état interne qui survit d'une requête à l'autre dans un même processus PHP.

📌 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, et PHP précise que toutes les installations qui servent des pages web sont concernées.
• Les attaquants ont pris de l'avance. Des programmes d'attaque circulent depuis le 21 octobre, et Amazon qualifie l'exploitation de « large » dès le jour de la publication.

Bon à savoir. Amazon recommande de chercher des traces d'attaque à partir du 17 octobre, et non de la date de l'annonce. Un serveur mis à jour aujourd'hui a pu être visé avant.

🎯 Quelles versions de PHP sont concernées ?#

Toutes les versions de PHP qui servent des pages web sont concernées jusqu'aux versions corrigées ci-dessous. Si vous utilisez les paquets de votre distribution, la version affichée peut rester la même (par exemple 8.2.x) : c'est alors la date ou le numéro de révision du paquet qui indique qu'il est corrigé.

📌 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.
2. Installez la version corrigée, avec une sauvegarde récente, puis redémarrez PHP-FPM ou Apache : tant que les processus PHP n'ont pas redémarré, l'ancienne version reste en mémoire.
3. Vérifiez la version réellement en service (voir ci-dessus), pour chaque version de PHP installée sur le serveur.
4. Cherchez des traces d'attaque depuis le 17 octobre : requêtes POST d'envoi de formulaire contenant PHP_SESSION_UPLOAD_PROGRESS, processus PHP qui lancent des commandes, fichiers PHP récents dans les dossiers d'envoi. Les commandes sont détaillées dans notre article sur CVE-2026-109619.
5. Si vous ne pouvez pas mettre à jour tout de suite, appliquez les mesures temporaires listées par PHP (ci-dessous) et restreignez l'accès aux applications concernées.

# 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

Avec les paquets de votre distribution ou d'un dépôt comme celui de Debian/Ubuntu maintenu par Ondřej Surý, les correctifs ont été publiés le 21 octobre, y compris pour plusieurs anciennes versions. Avec Docker, reconstruisez vos images à partir d'une image PHP mise à jour, puis redéployez les conteneurs.

📌 Mesures temporaires contre CVE-2026-109618#

PHP les présente comme des réductions d'exposition qui ne rendent pas une installation sûre :

• régler memory_limit=-1, de préférence avec php_admin_value dans le pool PHP-FPM ou la configuration Apache, pour que les applications ne puissent pas remettre une limite ;
• abaisser post_max_size : 8M pour les sites sans envoi de fichiers, 32M sinon, avec upload_max_filesize en dessous ;
• limiter la taille et la complexité des requêtes au niveau du serveur web ou du proxy, et borner la mémoire avec une limite de conteneur ou de cgroup (pas avec RLIMIT_AS ou RLIMIT_DATA, qui peuvent au contraire déclencher la faille).

Les mesures propres à la seconde faille, dont la désactivation de session.upload_progress, sont détaillées dans notre article sur CVE-2026-109619.

📌 Faut-il couper son site ?#

Pour un site dont la version de PHP est corrigée, non. La question se pose pour une application exposée sur internet qui tourne sur une version de PHP sans correctif disponible, surtout si elle manipule des données sensibles : restreindre l'accès (VPN, liste d'adresses IP, pare-feu applicatif), voire la mettre hors ligne le temps de la montée de version, est alors une décision raisonnable vu les tentatives d'exploitation en cours.

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

Nous avons installé les versions corrigées de PHP sur nos serveurs le 21 octobre 2026 en début de soirée, pour toutes les versions de PHP que nous hébergeons, y compris les plus anciennes grâce aux correctifs rétroportés, puis redémarré les services. Le matin même, nous avions déjà désactivé session.upload_progress sur tous nos serveurs. Vous n'avez rien à faire.

Si votre site tourne encore sur une version de PHP en fin de vie, nous vous conseillons tout de même de passer à une version maintenue de PHP 8 : écrivez-nous, nous vous accompagnons. Hébergé ailleurs, sur un serveur dédié ou un VPS ? Nous pouvons aussi vérifier et mettre à jour votre serveur ou votre CMS. 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.

📌 Le correctif est-il disponible ?#

Oui, depuis le 21 octobre 2026 à 14:00 UTC : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les distributions Linux publient leurs paquets corrigés de leur côté.

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

PHP ne publie plus de version 7.4, mais a fourni un correctif en code source. Vérifiez auprès de votre hébergeur ou de votre fournisseur de paquets si une version corrigée est installée, et planifiez rapidement le passage à une version maintenue de PHP 8.

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

Des tentatives d'exploitation sont signalées par Amazon et watchTowr, dès le 17 octobre selon Amazon. Au 22 octobre, aucune intrusion réussie n'était confirmée publiquement, mais il faut considérer que les serveurs non corrigés sont activement visés.

📌 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.