Faille PHP2Shell : versions touchées et comment protéger son site

L'essentiel en 30 secondes

• Quoi : la faille PHP2Shell désigne en réalité deux vulnérabilités distinctes du moteur PHP lui-même, CVE-2026-109618 et CVE-2026-109619 (une CVE est l'identifiant public d'une faille). Elles peuvent permettre à un attaquant, sans compte ni mot de passe, d'exécuter du code sur le serveur.
• Gravité : 9,2 sur 10 sur l'échelle CVSS v4.0 (la grille de gravité de référence, notée sur 10), selon l'équipe de sécurité de PHP.
• Correctifs : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiés le 21 octobre 2026.
• Qui : tout serveur où PHP produit des pages web, quel que soit le CMS. Les branches 8.1 et antérieures n'ont pas de nouvelle version officielle.
• À faire : vérifier la version qui sert réellement votre site, mettre à jour, redémarrer les services PHP, quitter les branches obsolètes.

Bonne nouvelle : contre la faille PHP2Shell, les correctifs existent et la marche à suivre est connue.

Faille PHP2Shell : de quoi parle-t-on ?

On ne le voit jamais, mais PHP travaille en permanence : c'est lui qui, côté serveur, produit les pages de WordPress, Drupal, Joomla, Magento et d'innombrables applications sur mesure. D'après W3Techs, cité par Frandroid, il fait tourner près de sept sites sur dix parmi ceux dont la technologie serveur est identifiable (69,3 %).

Le surnom vient d'un outil de démonstration aperçu dans une vidéo diffusée avant les correctifs. Il recouvre deux défauts distincts, corrigés ensemble.

CVE-2026-109618 : quand la mémoire vient à manquer

Intitulé officiel : « exécution de code à distance par corruption liée au manque de mémoire » (en anglais « RCE via OOM corruption », RCE désignant l'exécution de code à distance et OOM le manque de mémoire). En clair : si PHP tombe à court de mémoire au mauvais moment, il s'arrête en plein travail ; l'étape de rangement qui suit croit alors manipuler des données en bon état et abîme la mémoire du programme.

CVE-2026-109619 : des restes d'une requête à l'autre

Intitulé officiel : « exécution de code à distance par un état global périmé » (« RCE via stale global state »). PHP réutilise le même processus pour servir des requêtes successives. Certaines informations d'une requête précédente (erreurs, sessions, extensions…) ne sont pas toujours correctement effacées, et la suivante peut tomber dessus alors que la mémoire qui les contenait a déjà été libérée. L'avis officiel cite le suivi de progression des envois de fichiers lié aux sessions et, en PHP 8.5 seulement, les traces détaillées des erreurs fatales.

Pourquoi le sujet est sérieux

Ces failles s'exploitent à distance, sans authentification ni action de la victime. Avec mod_php (PHP intégré directement au serveur web Apache), selon le projet PHP, l'attaque peut survenir avant tout code applicatif : un CMS bien tenu ou une extension de sécurité ne suffisent pas. Sous PHP-FPM (le gestionnaire de processus PHP utilisé par de nombreux serveurs), les scénarios démontrés dépendent davantage de l'application, mais FPM reste exposé. L'avis GitHub de la seconde faille confirme en outre un risque de divulgation de données présentes en mémoire ; selon Sansec, qui associe aussi ce risque à la première faille, une telle fuite peut exposer des mots de passe, jetons ou clés d'autres requêtes.

Le 10/10 qui a circulé pendant la fuite est erroné, selon la PHP Foundation. Pourquoi 9,2 et pas 10 ? Dans la notation publiée par PHP, l'attaque est jugée difficile à réussir et exige des conditions particulières.

Red Hat classe le problème « Important », un cran sous « Critique », jugeant qu'une exploitation fiable exige une manipulation précise de la mémoire et un minutage précis.

Qui est concerné ?

Toutes les façons de faire tourner PHP

Le site php.net ne fait pas d'exception : dès que PHP génère des pages web, quelle que soit la façon dont il est relié au serveur web (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed), il faut corriger. mod_php est la configuration la plus exposée : c'est sur elle que les chercheurs ont fait la démonstration d'une attaque. PHP-FPM n'est pas épargné : la seconde faille a aussi été validée sur FPM.

Les versions : clair pour les branches récentes, flou pour les anciennes

Sur les anciennes branches, les sources se contredisent :

• les fiches CVE du projet PHP ne mentionnent que les branches 8.2 à 8.5 ;
• le CERT-FR déclare affectées toutes les versions 5.x, 7.x, 8.0.x et 8.1.x (et cite une branche 6.x, jamais sortie en version stable) ;
• Wiz et Sansec remontent jusqu'à PHP 5.4 ;
• l'équipe de sécurité de PHP a préparé des correctifs pour 7.4, 8.0 et 8.1, signe que ces branches sont touchées.

Conclusion prudente : toute version 8.1 ou antérieure sans correctif de votre fournisseur est à traiter comme vulnérable. Or PHP 7 faisait encore tourner environ un site PHP sur quatre (27 %) le 20 octobre, et PHP 5 près de 8 % (W3Techs, cité par Frandroid), sans compter les 8.0 et 8.1.

Mutualisé, VPS, dédié : qui doit agir ?

• Hébergement mutualisé : l'hébergeur installe et met à jour PHP. À vous de choisir une branche maintenue et de lui demander où en sont les correctifs.
• VPS ou dédié non infogéré : la mise à jour vous revient, que PHP vienne de la distribution, d'un dépôt tiers, d'une image de conteneur (Docker…) ou d'un panneau d'administration (cPanel, DirectAdmin…).
• Logiciels qui embarquent PHP : boîtiers et équipements, interfaces d'administration… Le NCSC néerlandais (centre national de cybersécurité des Pays-Bas) en tient une liste.

WordPress, Drupal, Joomla ou Magento ne sont pas fautifs : le défaut se situe dans PHP lui-même, sous l'application. Mettre son CMS à jour reste utile, mais ne corrige pas PHP2Shell.

Chronologie d'une divulgation chahutée

• Août-septembre 2026 : signalements de Calif, d'OpenAI et de Wiz. La PHP Foundation admet que la cause de la première faille avait été entrevue dès 2024 et qualifie d'« échec structurel » le retard pris pour la corriger.
• Mardi 20 octobre : les identifiants CVE fuitent avec un score erroné ; le projet avance la publication du 22 au 21 octobre et poste sa pré-annonce. Le soir, une vidéo de l'outil circule : Calif l'a publiée par erreur, selon la PHP Foundation, tandis que la presse la rattachait à un message effacé de Hacker News.
• Mercredi 21 octobre, 9 h 41 (Paris) : Chainguard diffuse ses images de conteneurs déjà corrigées, rompant l'embargo (le silence convenu jusqu'à la publication) plus de six heures avant l'heure prévue, selon la PHP Foundation.
• 21 octobre, vers 15 h 30 : publication des avis et des versions, un peu avant les 16 h annoncées (13 h 34 UTC selon GitHub, 13 h 30 selon le CERT-EU). Le journal des modifications officiel, lui, date ces versions du 22 octobre.
• Même jour : alerte CERT-FR CERTFR-2026-ALE-014, avis CERT-EU 2026-018, règles de filtrage d'urgence chez Cloudflare.
• 31 décembre 2026 : fin de vie de PHP 8.2.

Les failles PHP2Shell sont-elles déjà exploitées ?

Les sources divergent, autant le dire clairement.

• Côté officiel : la PHP Foundation n'avait identifié aucun exploit fonctionnel parmi les preuves de concept (programmes de démonstration d'attaque) apparues après la fuite ; les chercheurs avaient en revanche fait une démonstration sur mod_php. La CISA américaine évaluait l'exploitation à « aucune » (« none ») le 21 octobre, une heure après la publication, et n'avait toujours pas inscrit les CVE à son catalogue des failles exploitées le 22. Le CERT-EU note que des preuves de concept circulent.
• Côté éditeurs de sécurité : Cloudflare a signalé des attaques précoces le 21, avant les correctifs ; watchTowr a vu des tentatives d'exploitation atteindre ses leurres (des serveurs pièges) au moment des correctifs, sans succès constaté, selon SecurityWeek ; Help Net Security rapporte une tentative vue par Amazon dès le 17 octobre. Toujours selon SecurityWeek, la société Hadrian affirme observer une exploitation à grande échelle, une affirmation que nous n'avons pas pu recouper. Huntress, de son côté, n'avait observé aucune attaque chez ses clients le 20 octobre, selon le Journal du Coin.
• Révision : avant le correctif, Sansec s'attendait à des attaques de masse dans le quart d'heure suivant la publication (selon Ars Technica, cité par Frandroid). Le 22 octobre, l'éditeur juge finalement une vague massive moins probable que prévu.

Des tentatives sont donc signalées, mais leur ampleur reste incertaine. La difficulté d'exploitation n'est pas une protection.

Comment vérifier la version de PHP de votre site

Dans l'espace client de votre hébergeur

En mutualisé, la version de PHP s'affiche généralement dans l'espace client, site par site.

Avec phpinfo()

Créez un fichier texte contenant <?php phpinfo(); et donnez-lui un nom difficile à deviner, terminé par .php. Déposez-le à la racine du site (par FTP ou avec le gestionnaire de fichiers de votre hébergeur), puis ouvrez son adresse dans votre navigateur. La page affiche la version qui sert réellement vos pages, ainsi que la ligne « Server API », qui indique la façon dont PHP est relié au serveur web. Supprimez le fichier aussitôt après lecture : il révèle de nombreuses informations sur votre serveur.

En ligne de commande

php -v donne la version du PHP en ligne de commande, pas forcément celle du site : plusieurs versions peuvent cohabiter. Interrogez plutôt le programme qui sert les pages, par exemple php-fpm8.3 -v selon votre distribution.

Le piège des correctifs rétroportés

Les distributions Linux ont reçu les correctifs à l'avance, mais ne les numérotent pas toutes de la même façon. Certaines appliquent le correctif à une ancienne version sans changer son numéro : on parle de correctif rétroporté.

• Debian reprend les versions officielles : 8.2.35-1~deb12u1 (Debian 12), 8.4.27-1~deb13u1 (Debian 13) ;
• Ubuntu garde le numéro d'origine : sur Ubuntu 24.04, PHP affiche toujours 8.3.6, mais le paquet corrigé est 8.3.6-0ubuntu0.24.04.13 ;
• Red Hat publie selon les cas la version officielle (8.3.36 et 8.4.27 sur RHEL 10) ou un correctif rétroporté sur les anciennes branches (PHP 8.0 sur RHEL 9, module 7.4 sur RHEL 8). Certains flux, comme php:8.4 sur RHEL 9, étaient encore en attente le 22 octobre.

Une « 8.3.6 » peut donc être corrigée et, à l'inverse, un paquet corrigé ne protège qu'une fois installé et PHP redémarré. Vérifiez la version complète du paquet installé (dpkg -l | grep php ou rpm -qa | grep php), puis cherchez les deux CVE dans son journal des modifications, par exemple apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]' ou rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]' (le nom du paquet varie selon la distribution et la version de PHP).

Prudence avec les dépôts tiers : selon php.net, le dépôt bénévole rpms.remirepo.net n'avait pas de mise à jour le jour J ; Sansec signale depuis des paquets corrigés pour plusieurs branches. Vérifiez la présence des deux CVE dans le journal des modifications du paquet installé.

Que faire maintenant ?

Les actions prioritaires

1. Inventorier tout ce qui exécute PHP : sites, intranets, outils d'administration, logiciels tiers.
2. Mettre à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou une version plus récente), ou vers le paquet corrigé de votre distribution.
3. Redémarrer PHP-FPM, Apache ou LiteSpeed : tant que les processus ne sont pas relancés, l'ancien code reste en mémoire. Pour les conteneurs, reconstruire les images sur une base corrigée et redéployer.
4. Contrôler avec phpinfo() ou le gestionnaire de paquets, pas seulement avec php -v.
5. Quitter PHP 8.1 et les versions antérieures. Les correctifs minimaux pour 7.4, 8.0 et 8.1 ne remplacent pas une migration. Visez 8.3 ou plus récent : 8.2 ne sera plus maintenu après le 31 décembre 2026.
6. Isoler ce qui ne peut pas être corrigé. Le CERT-FR recommande « d'isoler les équipements affectés puis de procéder à la migration vers une version maintenue ». Si le correctif ne peut pas être appliqué, le CERT-EU invite à envisager d'isoler du réseau public les applications exposées, le temps de l'appliquer.
7. Surveiller et renouveler les secrets. Si un serveur vulnérable est resté exposé, examinez ses journaux et changez les mots de passe, clés d'API et jetons stockés côté serveur : une divulgation de données présentes en mémoire est possible.

Les mesures temporaires et leurs limites

PHP propose des réglages pour gagner du temps, tout en prévenant : « Il n'existe pas de mesure d'atténuation complète : la mise à jour est la seule option sûre » (« There are no complete mitigations, updating is the only safe choice »). Ces réglages concernent les administrateurs de serveurs ; en mutualisé, ils relèvent de l'hébergeur.

• CVE-2026-109619 : session.upload_progress.enabled=0 dans php.ini, le pool FPM ou la configuration serveur (pas via ini_set() ni .user.ini), puis redémarrage de tous les processus PHP ; en PHP 8.5, fatal_error_backtraces=0. Masquer les erreurs ne protège pas. S'il ne sert pas, PHP suggère de laisser ce suivi désactivé même après la mise à jour.
• CVE-2026-109618 : memory_limit=-1 imposé par l'administrateur, post_max_size réduit (8M sans envoi de fichiers, 32M sinon) et limites de taille de requête au serveur web ou au proxy. Ce réglage ne bloque pas tous les cas (php.net), et une requête peut alors accaparer toute la mémoire (Sansec). Il ne s'envisage donc qu'avec une limite mémoire par processus PHP au niveau du cgroup (le mécanisme Linux de limitation des ressources) ou du conteneur, jamais sur un serveur mutualisé sans ce garde-fou, et il faut remettre une limite finie juste après la mise à jour (Sansec). Préférez une limite qui n'arrête que le processus en cause : selon l'avis GitHub, arrêter tout le conteneur peut emporter le processus principal et tous les autres. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA (php.net).
• Filtrage en amont : l'avis GitHub de la CVE-2026-109618 suggère de bloquer les requêtes « multipart » (le format utilisé pour envoyer des fichiers) si le site n'en a pas besoin ; le CERT-FR propose de les bloquer, ou à défaut de les surveiller, au prix des formulaires d'envoi de fichiers. Le CERT-FR précise que ses contournements ne sont pas qualifiés, c'est-à-dire pas validés par ses soins. Quant aux règles d'urgence de Cloudflare, elles ne protègent que les sites dont le trafic transite par ce service.

Selon le CERT-FR, désactiver le suivi de progression ne réduit la surface d'attaque que pour l'une des deux failles, et seulement en partie (php.net : seuls les chemins confirmés liés aux sessions sont bloqués). Ces réglages font gagner du temps, rien de plus.

Et chez EXAGROUP ?

Dans l'espace client EXAGROUP, les versions de PHP que le projet PHP ne corrige plus officiellement, de 5.6 à 8.1, ne sont plus proposées ni acceptées.

Vous pouvez vérifier et changer la version de PHP de votre site depuis votre espace client. Si votre site tourne encore en PHP 8.2, c'est le moment de tester une version plus récente, avant la fin de vie du 31 décembre.

Pour savoir où en est votre service, demandez-nous : notre support répond 24 h/24 et 7 j/7 par ticket. Consultez aussi notre FAQ, nos formules d'hébergement web, notre comparatif d'hébergement web ou notre page contact.

Sources

• php.net : avis de sécurité du 21/10/2026
• php.net : pré-annonce du 20/10/2026
• PHP Foundation : retour sur la publication
• GitHub : GHSA-w8hw-w9fx-j79w
• GitHub : GHSA-6wmf-4rv5-p3rp
• NVD : CVE-2026-109618
• CERT-FR : CERTFR-2026-ALE-014
• CERT-EU : avis 2026-018
• NCSC-NL : logiciels embarquant PHP
• Ubuntu : USN-8948-1
• Debian : suivi de CVE-2026-109618
• Red Hat : RHSB-2026-013
• Sansec : analyse PHP2Shell
• Cloudflare : règles WAF d'urgence
• Help Net Security : PHP2Shell
• SecurityWeek : premières tentatives d'exploitation
• Ars Technica : PHP annonce deux correctifs d'urgence
• Frandroid : failles critiques dans PHP
• Wikipédia : PHP2Shell
• Journal du Coin : PHP2Shell, correctif du 21 octobre

Article rédigé le 22 octobre 2026. La situation évolue : fiez-vous d'abord aux avis de php.net, du CERT-FR et de votre distribution.