Faille PHP php2shell (CVE-2026-109618 et CVE-2026-109619) : de quoi s'agit-il et comment la corriger

Ne vérifiez que des systèmes qui vous appartiennent ou dont vous êtes responsable. Cette page et notre vérificateur ne font que comparer des numéros de version que vous saisissez vous-même, dans votre navigateur. Rien ici ne teste, ne sonde et n’analyse un serveur. Site indépendant, sans lien avec le PHP Group ni avec php.net.

Réponse courte

« php2shell » est le surnom donné par Wiz Research à deux failles critiques de PHP : CVE-2026-109618 et CVE-2026-109619. Le PHP Group les a notées toutes deux 9,2 sur 10 (CVSS v4.0, critique) et indique qu’elles peuvent permettre une exécution de code à distance sans authentification : en clair, un inconnu sur Internet pourrait faire exécuter du code sur votre serveur.

Si la version de PHP de votre serveur est antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (selon sa branche), ou si elle appartient à une branche plus ancienne (8.1, 8.0, 7.4…), il faut la mettre à jour, puis redémarrer PHP. Attention : les paquets de distribution gardent un numéro « ancien » même corrigés (voir plus bas). Sur un hébergement mutualisé, c’est à l’hébergeur de corriger : vérifiez son annonce (voir plus bas). Le PHP Group est clair : « There are no complete mitigations, updating is the only safe choice » (en clair : aucune mesure d’atténuation ne suffit, seule la mise à jour corrige la faille).

Ce qu’est php2shell, en mots simples

• Deux failles, un seul correctif. CVE-2026-109618 (« RCE via OOM corruption ») et CVE-2026-109619 (« RCE via stale global state ») sont décrites dans les avis du PHP Group (GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp). Les mêmes versions de PHP corrigent les deux. Nous ne détaillons pas leur fonctionnement : vous n’en avez pas besoin pour corriger.
• Gravité. Score CVSS v4.0 de 9,2 pour chacune, attribué par le PHP Group. Le NVD a depuis ajouté ses propres scores CVSS v3.1 : 9,8 (critique) pour CVE-2026-109618 et, depuis le 22 octobre, 8,1 (élevé) pour CVE-2026-109619 (auparavant 9,8), la note du PHP Group restant affichée comme secondaire.
• D’où vient le nom. « php2shell » n’apparaît ni sur php.net ni dans les fiches CVE : c’est le nom choisi par Wiz Research dans son article, repris par CERT-EU et le NCSC-NL et par le réseau des CSIRT nationaux (ENISA).
• Est-ce déjà exploité ? Les sources ne disent pas la même chose, donc voici qui dit quoi. Le PHP Group juge le risque le plus élevé avec mod_php et parle d’un exploit démontré. CERT-EU indique que des preuves de concept commencent à circuler, ce qui accroît la probabilité que des attaquants exploitent déjà ces failles ; la PHP Foundation écrit que leur circulation a augmenté le 21 octobre, tout en précisant que son équipe sécurité n’avait pas identifié d’exploit fonctionnel au moment de la publication. Le Centre canadien pour la cybersécurité relève lui aussi une preuve de concept signalée dans des sources ouvertes, sans exploitation active identifiée à ce stade. À notre vérification du 22 octobre, les deux CVE ne figuraient toujours pas au catalogue KEV de la CISA, la liste américaine des failles connues comme exploitées (version 2026.10.21 du catalogue, publiée le 21 octobre). Précision de date : l’évaluation SSVC de la CISA enregistrée au NVD (« exploitation : none ») date du 21 octobre à 14 h 34 UTC, jour de la publication ; elle précède les signalements de CERT-EU et de la PHP Foundation sur la circulation de preuves de concept et n’est pas une position plus récente. Traitez le sujet comme urgent dans tous les cas.

Qui est concerné ?

Tout serveur dont PHP répond à des requêtes web. Formulation du PHP Group : « all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed » (annonce php.net). WordPress, Joomla, Drupal, PrestaShop, Laravel, Nextcloud ou un site maison : peu importe l’application, c’est la version de PHP installée sur le serveur qui compte, pas celle de votre CMS.

Mettre à jour WordPress ne corrige donc pas la faille : Wordfence l’écrit noir sur blanc, les mises à jour automatiques de WordPress n’appliquent pas ce correctif. Voir notre guide WordPress.

Versions corrigées

Sources : annonce php.net et versions supportées. Les plages « affected » de l’avis GitHub et de la fiche CVE ne listent que 8.2 à 8.5 (8.2.* avant 8.2.35, 8.3.* avant 8.3.36, 8.4.* avant 8.4.27, 8.5.* avant 8.5.12). La configuration CPE du NVD va plus loin : toute version inférieure à 8.2.35 y est concernée, sans borne basse, donc aussi 8.1 et plus ancien, en plus des plages 8.3, 8.4 et 8.5 ci-dessus. À noter : la branche 8.2 n’a plus qu’un peu plus de deux mois de support de sécurité. Tableau complet, avec les paquets des distributions : versions corrigées.

Les paquets Linux gardent un « vieux » numéro

Debian, Ubuntu, Red Hat et consorts ne passent généralement pas à la nouvelle version amont : ils rétroportent le correctif dans leur version existante. Un numéro qui paraît ancien peut donc être corrigé. Comparez-le au numéro de paquet corrigé de votre éditeur, pas à celui de php.net. Exemples relevés :

Rocky Linux et Oracle Linux ont publié des avis pour certains paquets, avec leurs propres numéros de build, mais avec des trous à notre dernier relevé : Rocky 8 a des avis pour php:7.4 (7.4.33-8.module+el8.10.0+40393+c071e357) et php:8.2 (8.2.35-1.module+el8.10.0+40394+d21b33fb, RLSA-2026:87073) mais aucun pour ses autres flux, et il n’y a aucun avis pour Rocky 9 php:8.4 ; Oracle Linux 8 a des avis pour php:7.4 (7.4.33-8.module+el8.10.0+91080+9785160d, ELSA-2026-87080) et php:8.2 (8.2.35-1.module+el8.10.0+91081+33b5c645, ELSA-2026-87073) mais aucun pour ses autres flux ; Oracle Linux 9 a des avis pour php 8.0, php:8.2 (8.2.35-1.module+el9.8.0+91079+4ad1bd7f, ELSA-2026-87072) et php:8.3 (8.3.36-1.module+el9.8.0+91082+c865dc1a, ELSA-2026-87079), mais aucun pour ses autres flux. Amazon Linux 2023 a des paquets corrigés pour php8.2 à php8.5 (pas pour php8.1 : « No Fix Planned » (aucun correctif prévu)) ; Amazon Linux 2 a un correctif pour le flux d’extras PHP 8.2 ; le php du dépôt principal est marqué « No Fix Planned » (aucun correctif prévu), et les pages d’Amazon ne disent rien des autres flux d’extras. AlmaLinux a publié des avis : AlmaLinux 10 php (8.3) 8.3.36-1.el10_2 (ALSA-2026:87070) et php8.4 8.4.27-1.el10_2 (ALSA-2026:87071), AlmaLinux 9 php:8.3 8.3.36-1.module_el9.8.0+330+fdc30075 (ALSA-2026:87079) et AlmaLinux 8 php:7.4 7.4.33-8.module_el8.10.0+4321+cf5fd4bb (ALSA-2026:87080) ; les autres builds ne sont pas confirmés (sur AlmaLinux 9, l’avis php:8.2 ne liste que des paquets php-pecl). Le détail, version par version, est dans le tableau des versions corrigées ; sinon, consultez l’avis de votre distribution.

Anciennes branches de PHP

Selon php.net, PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour. Pour 7.4, 8.0 et 8.1, l’équipe sécurité a seulement publié des rétroportages minimaux (backports), sous forme de sources (ni archive de version, ni numéro) pour ceux qui compilent eux-mêmes ou n’ont pas de fournisseur LTS. Pour 7.3 et plus ancien, php.net n’annonce rien. Le CERT-FR range toutes les versions 5.x, 6.x, 7.x, 8.0.x et 8.1.x parmi les versions affectées. Le vrai remède est de passer à une branche supportée ; en attendant, demandez à votre éditeur ou à votre hébergeur un paquet corrigé. Les mesures de configuration listées par php.net « reduce exposure to specific attack paths but do not make an installation safe » (elles réduisent l’exposition à certaines voies d’attaque, mais ne remplacent pas la mise à jour) : à utiliser uniquement comme solution provisoire.

Ce que dit le CERT-FR

L’ANSSI a publié l’alerte CERTFR-2026-ALE-014, « Multiples vulnérabilités dans PHP », première version du 21 octobre 2026 (mise à jour depuis). Elle reprend l’avis de PHP : les deux vulnérabilités « permettent à un attaquant de provoquer une exécution de code arbitraire à distance ». Elle liste les versions 8.2 à 8.5 inférieures aux versions corrigées ci-dessus, ainsi que toutes les versions 5.x à 8.1.x. Le CERT-FR précise aussi que les mesures provisoires publiées par PHP ne sont pas qualifiées par lui.

Ailleurs en Europe : CERT-EU 2026-018 et le NCSC britannique ont aussi publié. Le Centre canadien pour la cybersécurité a publié l’alerte AL26-026 le 21 octobre (page en anglais), et le JVN japonais une fiche (JVNVU#99905564) le 22 octobre. Nous n’avons pas vérifié d’avis belge ni suisse. Le contenu technique, lui, ne dépend pas du pays.

Les 3 étapes : vérifier, mettre à jour, contrôler

Faites une sauvegarde ou un instantané avant. C’est surtout important si vous changez de branche de PHP (par exemple 8.1 vers 8.3) plutôt que de prendre une simple mise à jour de correctif dans la même branche.

Étape 1 : vérifier la version

Sur un serveur auquel vous avez accès en SSH :

php -v                                  # PHP en ligne de commande, parfois différent de celui du web
ls /usr/sbin/php-fpm* 2>/dev/null       # binaires FPM, puis par ex. php-fpm8.3 -v
dpkg -l | grep -E '^ii +php'            # Debian / Ubuntu
rpm -qa | grep -i '^php'                # RHEL, Alma, Rocky

Le PHP qui sert votre site n’est pas forcément celui de la ligne de commande : contrôlez bien la version FPM ou Apache.

Sur un hébergement mutualisé, regardez la version choisie dans l’interface de votre hébergeur (l’option « changer la version de PHP » proposée par la plupart des hébergeurs). Attention : choisir « 8.3 » ne prouve pas que le correctif est installé. Demandez à l’hébergeur, ou consultez son état d’avancement.

Saisissez ensuite votre version dans le vérificateur et comparez avec le tableau des versions corrigées. Avec un paquet de distribution, comparez au numéro de paquet corrigé. Pas à pas : comment connaître sa version de PHP.

Étape 2 : mettre à jour par le circuit habituel

Debian / Ubuntu (remplacez 8.3 par votre branche) :

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php8.3*'

Famille RHEL (comparez la version installée avec l’avis de l’éditeur : RHEL 9 php:8.4, Rocky 9 php:8.4, les autres builds d’AlmaLinux, ainsi que les flux de Rocky 8 et d’Oracle Linux 8 autres que php:7.4 et php:8.2, n’avaient pas encore de paquet corrigé ou d’avis à notre relevé) :

sudo dnf check-update 'php*'
sudo dnf upgrade 'php*'

Docker : reconstruire depuis une image de base corrigée, puis recréer le conteneur. Avant cela, vérifiez que l’image officielle de votre branche est bien corrigée : lors de notre dernier relevé (22 octobre), les images officielles php:8.5, php:8.4, php:8.3 et php:8.2 étaient publiées en 8.5.12, 8.4.27, 8.3.36 et 8.2.35 (le 21 octobre vers 16 h 35 UTC, 8.5 et 8.4 n’étaient pas encore publiées). Retéléchargez l’image pour remplacer vos copies locales, et contrôlez avec docker run --rm php:8.4 php -v ou, pour votre propre image, avec docker run --rm monapp:patched php -v.

docker build --pull --no-cache -t monapp:patched .
docker compose up -d --force-recreate

Si vous compilez depuis les sources ou utilisez un dépôt tiers, prenez 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 sur php.net. Le PHP Group avait précisé que le dépôt RPM bénévole de Remi n’aurait pas de mise à jour le jour de la sortie ; Remi propose depuis des builds 8.2 à 8.5 pour Enterprise Linux 8, 9 et 10 datés du 21 octobre (par exemple 8.3.36-1.el9.remi), sans citer les CVE : ce sont les versions amont corrigées.

Si vous utilisez un panneau d’administration, voici ce que nous avons vérifié au 22 octobre : cPanel/EasyApache 4 a publié un correctif (notes de version) ; chez Plesk, les correctifs pour PHP 8.2 à 8.5 sont sortis (Linux et Windows) ; sous Linux, 7.4, 8.0 et 8.1 gardent leur numéro de version et les builds du 21 octobre incluent les correctifs, Plesk demandant de mettre Plesk à jour (article Plesk). Détails : guide hébergement et panneaux.

Étape 3 : redémarrer et contrôler

Une mise à jour ne prend effet qu’après le redémarrage du processus PHP.

sudo systemctl restart php8.3-fpm       # nom de votre unité FPM ; RHEL : php-fpm
sudo systemctl restart apache2          # seulement avec mod_php (RHEL : httpd)
php -v
dpkg -l | grep -E '^ii +php8.3'         # comparer au paquet corrigé de votre éditeur

Contrôlez ensuite trois choses : la version installée correspond bien à la version corrigée de votre éditeur, le service redémarre sans erreur (systemctl status php8.3-fpm) et votre site s’affiche. Avec Docker : docker exec <conteneur> php -v sur le nouveau conteneur. Resaisissez enfin la version dans le vérificateur.

Hébergeurs : où en est-on ?

Voici ce que disent les pages officielles des hébergeurs au 22 octobre 2026. Une protection côté hébergeur (pare-feu, blocage de certains envois de fichiers) ne remplace pas la mise à jour de PHP, sauf si l’hébergeur dit que la mise à jour elle-même est faite.

« Aucune déclaration trouvée » veut seulement dire que nous n’avons rien vu aux endroits indiqués, pas que le service est corrigé. Dans ce cas, posez la question à votre hébergeur par ticket. Le détail à jour est sur la page statut des hébergeurs.

Besoin d’un coup de main pour votre installation ?

Si vous préférez ne pas chercher seul la marche à suivre, nous proposons un plan de correctif personnel à 49 $ US : des étapes écrites pour votre configuration exacte, envoyées par e-mail sous 24 h. Nous ne nous connectons jamais à votre serveur. Détails : plan de correctif.