php2shell: ce que c'est et comment corriger PHP

Le 21 octobre 2026, le projet PHP a publié des correctifs d’urgence pour deux failles critiques d’exécution de code à distance sans authentification, suivies sous CVE-2026-109618 et CVE-2026-109619 et largement appelées php2shell. Le risque ne dépend ni d’un plugin fragile ni d’un thème mal écrit. Il se situe dans le runtime qui traite la requête HTTP, ce qui change la priorité de réponse pour quiconque opère un site, une API ou une plateforme d’hébergement.

Si vous maintenez WordPress, Laravel, Drupal, un panneau de contrôle, un conteneur avec l’image officielle du PHP ou toute application derrière PHP-FPM ou Apache avec mod_php, le premier geste consiste à inventorier la version qui sert réellement le trafic et à planifier la mise à jour. Ce guide reste du côté de la défense et de l’exploitation. Il explique ce que les sources ouvertes confirment, où elles divergent, comment mesurer l’exposition, comment appliquer une correction PHP RCE et ce qu’il faut réduire tant que le correctif n’est pas en place.

Le texte n’enseigne pas l’exploitation. Il sert à décider ce qu’il faut faire demain dans l’inventaire, le pipeline et la fenêtre de maintenance, avec les risques et les limites à côté de chaque recommandation.

Qu’est-ce que le php2shell et pourquoi cela compte maintenant#

Le php2shell est le nom informel du duo formé par CVE-2026-109618 et CVE-2026-109619, deux vulnérabilités de sécurité mémoire dans le noyau du PHP qui, dans les bonnes conditions, permettent à un attaquant sans session d’exécuter du code avec les privilèges du worker web. L’avis de sécurité dans les archives de php.net décrit la première comme une corruption liée au traitement d’un manque de mémoire, et la seconde comme la réutilisation d’un état global périmé entre requêtes dans le même worker. La PHP Foundation souligne le même jour que les deux touchent la gestion mémoire et le traitement d’erreur, des chemins presque inévitables à chaque requête.

La note officielle et les alertes sanitaires ou gouvernementales qui la reprennent attribuent un score CVSS v4.0 de 9,2 à chaque CVE. Avant l’annonce complète, une note 10,0 a circulé. Traitez 9,2 comme la référence publiée par le projet et par les organismes qui citent l’avis du CNA, et traitez la note gonflée comme une rumeur jusqu’à un enregistrement officiel qui la soutienne.

L’impact pratique est large parce que l’attaque vise l’interpréteur, et non la logique de votre application. Sous Apache avec mod_php, l’équipe PHP et la Foundation rapportent une exploitation démontrée où la requête déclenche le chemin vulnérable avant tout code applicatif. Sous PHP-FPM, le RCE a aussi été confirmé par des chemins au niveau de l’application. La divulgation de mémoire sensible du processus apparaît également dans les descriptions techniques, ce qui peut exposer des secrets d’autres requêtes du même worker.

Sur l’exploitation réelle, les sources ne parlent pas d’une seule voix. L’alerte de la CISA du 21 octobre 2026 indique qu’au moment de la publication, l’agence n’observait pas d’exploitation de son côté. Des capteurs commerciaux et des reportages du même jour décrivent pourtant du trafic d’attaque et des tentatives après une fuite préalable de détails. La lecture responsable est la suivante. Des tentatives existent selon plusieurs capteurs. Un compromis réussi à grande échelle n’est pas un fait uniforme confirmé par toutes les autorités au même instant. Le risque opérationnel, en revanche, n’attend pas le consensus.

En pratique, ce que je vois le plus souvent, c’est une équipe qui traite le dossier comme un bug du CMS, alors que le problème est dans le binaire PHP sous le CMS. Qui tarde à séparer runtime et application perd la fenêtre où le correctif reste encore peu coûteux.

Qui est concerné par les failles du PHP#

Selon l’avis officiel, toute installation de PHP qui sert des requêtes web est en risque, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé plus élevé sous mod_php, car une démonstration de déclenchement sans authentification avant le code applicatif y existe. Cela couvre une grande part de l’hébergement mutualisé classique et beaucoup de stacks hérités.

Les versions corrigées publiées le 21 octobre 2026 sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les lignes antérieures à ces jalons, dans chaque branche supportée, figurent comme affectées dans les avis GHSA de php-src. Le projet PHP précise que 8.1 et plus ancien ne reçoivent plus de mises à jour officielles de la ligne principale. Des distributions et des fournisseurs LTS peuvent publier un backport. Pour qui compile depuis les sources sans LTS, l’équipe sécurité a publié des backports sources minimaux pour 7.4, 8.0 et 8.1.

Il existe une divergence importante sur le « depuis quand ». Des rapports de chercheurs et de Cloudflare affirment un impact depuis PHP 5.4, soit une décennie ou plus de versions. L’avis officiel de php.net, dans la forme lue pour cette session, n’emploie pas cette phrase comme confirmation unique. Il se concentre sur les lignes avec correctif publié, sur le statut de fin de vie de 8.1 et sur les backports. Dans un texte éditorial responsable, dites que Cloudflare et les groupes de recherche cités dans la divulgation affirment une couverture depuis 5.4, et que ce que le fournisseur confirme de façon opérationnelle, c’est la nécessité de mettre à jour PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou d’obtenir un paquet backporté chez votre éditeur.

Entrant aussi dans l’inventaire les produits qui embarquent PHP sans que vous le voyiez, les panneaux, les appliances, les images Docker anciennes et les environnements gérés. Le NCSC de la Suisse et la CISA demandent un inventaire au-delà du site visible. Un hébergement géré peut sembler hors de votre main, mais la responsabilité reste la vôtre jusqu’à confirmation du paquet corrigé par le prestataire. Sous Linux, le NCSC suisse alerte encore qu’une même version majeure ne prouve pas l’absence de correctif, car le backport peut garder le numéro apparent et changer le contenu du paquet.

L’erreur qui coûte le plus cher ici, c’est d’inventorier seulement le WordPress de la vitrine et d’oublier le second PHP du panneau interne, du cron web ou du conteneur de staging exposé. L’attaquant ne respecte pas l’organigramme de l’équipe.

Comment savoir si votre PHP est vulnérable#

Vous mesurez l’exposition en croisant la version du runtime qui sert HTTP, l’origine du paquet et le SAPI utilisé. Lancer php -v dans un shell aide, mais cela ne suffit pas si le site utilise un autre binaire via FPM ou le module Apache. Vérifiez la version rapportée par l’application elle-même en environnement contrôlé, la sortie de phpinfo() uniquement sur un réseau administratif, le paquet de la distribution et le tag de l’image du conteneur.

Ordre pratique suggéré.

1. Listez les hôtes et services qui répondent du contenu dynamique en PHP, publics et internes.
2. Identifiez le SAPI, mod_php, PHP-FPM, cgi, FrankenPHP ou LiteSpeed, car la priorité de correctif monte avec un mod_php exposé.
3. Notez la version exacte et le paquet. Sous Debian et Ubuntu, le numéro de paquet et le changelog de sécurité importent autant que PHP_VERSION. Sous RHEL et clones, l’avis du vendor prime.
4. En conteneur, lisez l’image en cours d’exécution et la date du build. Une image php:8.4 tirée il y a des semaines peut encore être sous PHP 8.4.27.
5. En hébergement géré, demandez une confirmation écrite de la version corrigée ou du ticket de sécurité. Tant qu’il n’y a pas de confirmation, traitez comme vulnérable.
6. Si vous êtes en 8.1 ou moins sans backport du vendor, considérez l’installation vulnérable et sans chemin officiel du projet PHP, sauf backport source minimal ou migration.

Si la version est inférieure à 8.5.12 sur la ligne 8.5, à 8.4.27 sur la 8.4, à 8.3.36 sur la 8.3 ou à 8.2.35 sur la 8.2, et qu’il n’existe aucune preuve de backport, vous êtes en zone de correction immédiate. Pour 8.1 et antérieur, la question n’est plus quel correctif de php.net, mais quel paquet du vendor ou quelle date de migration.

Beaucoup de gens se fient seulement au php -v du SSH et se trompent presque toujours, parce que le worker du site peut être un autre fichier. Confirmez le binaire du pool FPM ou du module Apache avant de marquer l’élément comme résolu.

Comment corriger, avec versions officielles et backports#

La seule remédiation complète, selon les mots du projet PHP et repris par la CISA, le NCSC du Royaume-Uni et des CERT européens, consiste à actualiser le runtime. Cible officielle au 21 octobre 2026.

L’ordre de priorité que la plupart des opérations devraient suivre place d’abord les services exposés à Internet avec mod_php, puis les exposés avec PHP-FPM, ensuite les systèmes internes à données sensibles, et enfin le reste de l’inventaire. Après installation du paquet, redémarrez Apache, PHP-FPM ou l’équivalent, et confirmez la version dans le processus qui sert réellement. Un conteneur exige rebuild et redéploiement de l’image, pas seulement un restart de l’ancien tag. L’avis GHSA de la CVE-2026-109618 indique clairement que seul le release avec le correctif constitue une mitigation complète.

Si vous dépendez de rpms.remirepo.net, l’avis de php.net à cette date a demandé une migration vers les paquets de la distribution ou une compilation depuis les sources, car ce dépôt volontaire n’aurait pas d’updates le jour même. Qui reste en 7.4, 8.0 ou 8.1 sans LTS doit choisir entre backport source minimal, paquet du vendor ou saut vers une ligne supportée. Aucune de ces options n’est gratuite en régression. Testez l’application, surtout les extensions natives et pecl.

Corriger le runtime ne nettoie pas un compromis antérieur. S’il existe un indice de shell, de téléchargement étrange depuis le worker ou d’altération de fichiers, ouvrez le playbook de réponse à incident et traitez comme un incident, pas comme un simple correctif. Un programme de gestion des vulnérabilités aide à ne pas revivre la même surprise à la prochaine CVE du runtime.

Qui laisse le patch pour le sprint suivant découvre souvent que la régression de la montée de version coûtait moins cher que d’isoler le site en pleine journée. Planifiez la fenêtre courte et mesurez ensuite.

Que faire tant que la mise à jour n’est pas encore possible#

Tant que le correctif n’entre pas, réduisez la surface et acceptez qu’aucune mitigation partielle ne rend l’installation sûre. Le NCSC du Royaume-Uni a demandé de se préparer à une mise à jour immédiate et, si la remédiation n’est pas viable, d’envisager de retirer le système du réseau jusqu’à une mitigation réelle. La CISA reprend la logique d’isolement pour qui n’actualise pas et utilise encore 8.1 ou antérieur sans correction.

Les mesures transitoires décrites par l’avis de php.net et par l’avis GHSA pour CVE-2026-109618 comprennent le forçage de memory_limit=-1 de façon administrative, par exemple avec php_admin_value dans le pool FPM ou sous Apache, de sorte que l’application ne réintroduise pas une limite finie. Elles recommandent aussi un post_max_size bas, 8M sans upload ou 32M quand l’upload est nécessaire, avec upload_max_filesize sous ce plafond, et des limites proxy sur la taille décodée, les champs, les parties multipart et la profondeur, y compris sans Content-Length utile. Une limite cgroup ou conteneur peut servir de frontière de disponibilité si elle tue seulement le worker touché. N’utilisez pas RLIMIT_AS ni RLIMIT_DATA à la place, car cela peut provoquer l’échec d’allocation sur le chemin vulnérable.

Pour CVE-2026-109619, l’avis demande session.upload_progress.enabled=0 dans une configuration appliquée avant le parse de la requête, avec redémarrage de tous les workers, sans dépendre de ini_set() ni de .user.ini. Sous PHP 8.5, aussi fatal_error_backtraces=0 avec redémarrage. Retirez les réglages invalides ou dépréciés qui émettent un diagnostic trop tôt. Masquer l’erreur avec display_errors ne résout rien.

Un WAF aide comme couche supplémentaire. Cloudflare a annoncé des protections WAF déployées avant la divulgation publique et a demandé le correctif malgré tout. La CISA et le NCSC suisse disent la même chose. Un WAF seul ne suffit pas. Restreindre l’accès par VPN ou liste blanche, couper Internet sur les systèmes qui n’en ont pas besoin et isoler les uploads sont des contrôles de confinement, pas une guérison.

Le coût caché de ces mitigations, c’est la casse d’upload, de grand formulaire et de progression de session. Mesurez l’effet en staging. Si le métier ne tolère pas l’effet de bord et que le correctif tarde, l’alternative honnête du NCSC demeure. Retirer du réseau ce qui ne peut pas être corrigé.

Qui n’applique qu’une règle WAF et ferme le ticket échange un risque technique contre un risque de fausse sécurité. Utilisez les mitigations pour gagner des heures, pas des semaines.

Durcissement qui réduit le rayon d’explosion après le correctif#

Après la mise à jour, durcissez l’environnement pour qu’une prochaine faille de worker ne transforme pas tout le domaine en compromis. L’isolation par pool FPM et par site, un utilisateur Linux distinct, un système de fichiers de code aussi en lecture seule que possible et des secrets hors du document root restent valides. Les limites de corps au proxy et au PHP réduisent la pression mémoire même après le correctif. Le CERT-EU et la CISA demandent de surveiller les redémarrages anormaux de worker, les pics multipart et les processus enfants inattendus du PHP, y compris les workers qui lancent un shell ou un téléchargement.

L’observabilité ne remplace pas le correctif, mais elle évite de découvrir l’incident seulement par un défaçage. Envoyez les journaux d’accès, d’erreur FPM et d’audit hôte vers la même piste utilisée pour l’analyse en réponse à incident. Si vous soupçonnez un accès préalable, la chasse à la persistance devient une étape propre, car actualiser le PHP n’efface pas un webshell déjà écrit.

La limite est claire. Le durcissement réduit le rayon et accélère la réponse. Il n’annule pas une CVE critique du runtime tant qu’une version vulnérable sert encore Internet.

Au quotidien, ce qui sépare un correctif appliqué d’un environnement sous contrôle, c’est de vérifier le processus vivant et le comportement après redémarrage, et non seulement le paquet dans dpkg. Sans ce contrôle, l’inventaire ment avec élégance.

Checklist pour les développeurs#

1. Découvrez quelle version de PHP chaque environnement de build, CI, staging et production utilise vraiment sur le SAPI web, pas seulement en CLI.
2. Actualisez les images de base, le Dockerfile et le verrou de runtime pour 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon la ligne que le projet supporte, afin de mettre à jour PHP 8.5.12 ou l’équivalent de votre branche.
3. Exécutez la suite de tests et un smoke d’upload, de session et de formulaire multipart, car les mitigations transitoires et les changements de limite cassent un flux légitime.
4. Retirez la dépendance à session.upload_progress si elle existe encore dans l’UX, puisque le chemin est cité dans les mitigations de CVE-2026-109619.
5. Traitez l’erreur fatale et le délai d’attente atteignables par une entrée utilisateur comme une dette de sécurité, pas seulement d’UX, car l’avis relie un état résiduel à des erreurs fatales mal nettoyées.
6. Ne publiez ni exploit, ni preuve de concept fonctionnelle, ni charge utile. Le rôle de l’équipe produit est de fermer l’exposition et de documenter la version corrigée dans le runbook du service.
7. Demandez à l’équipe plateforme la confirmation du paquet en hébergement géré avant de marquer l’histoire comme prête.

Le développeur qui ne fait monter que l’image locale et oublie le worker de production laisse le risque exactement là où l’attaquant regarde en premier. Fermez la boucle avec une preuve de version sur le processus distant.

Checklist pour les opérations et l’hébergement#

1. Inventoriez tout PHP qui sert HTTP, y compris appliance, panneau, conteneur et SaaS autogéré.
2. Priorisez l’exposition Internet et mod_php, puis le FPM public, puis le reste.
3. Appliquez le paquet du vendor ou le release officiel, redémarrez les workers et validez la version dans le processus actif.
4. Si vous ne pouvez pas corriger tout de suite, évaluez la mise hors ligne selon le NCSC et la CISA, appliquez les mitigations partielles de l’avis php.net et gardez le WAF à jour sans traiter cela comme une clôture.
5. Surveillez les workers qui lancent un shell, curl ou un téléchargement, les crashes en série et les uploads multipart anormaux.
6. Exigez du prestataire d’hébergement la version corrigée par écrit et la date d’application.
7. Après le correctif, revoyez les indicateurs d’un compromis préalable avant de déclarer la victoire.

L’ops qui ferme le ticket sur le paquet installé sans valider le binaire du pool rouvre souvent le même ticket sous un autre nom. La preuve, c’est la version du processus qui répond sur le port 443.

Questions fréquentes sur php2shell#

Avant de choisir un correctif ou une fenêtre de maintenance, beaucoup d’équipes butent sur les mêmes questions pratiques, surtout quand WordPress, un hébergeur géré et plusieurs versions de PHP coexistent dans le même compte. Les réponses ci-dessous reprennent seulement ce que les avis ouverts confirment, sans élargir le périmètre vers des recettes d’attaque, afin de trancher vite entre runtime, CMS et couche réseau.

Le php2shell est-il une faille de WordPress ou du PHP?#

C’est une faille du runtime PHP. WordPress, Drupal, Joomla et d’autres entrent dans le périmètre parce qu’ils s’exécutent sur ce runtime. Une application bien écrite n’immunise pas si la version du PHP reste vulnérable, car le chemin touché peut se déclencher avant le code métier. Traitez donc l’inventaire du binaire et du SAPI comme la priorité, et non seulement le numéro de version du CMS.

Mettre à jour le CMS suffit-il sans toucher au PHP?#

Non. Vous avez besoin de la version corrigée de l’interpréteur ou d’un backport équivalent du fournisseur. Actualiser seulement les plugins et le cœur du CMS ne ferme ni CVE-2026-109618 ni CVE-2026-109619. Tant que le worker qui sert HTTP n’affiche pas 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou un paquet vendor prouvé, le risque runtime demeure, même si le tableau de bord du CMS affiche tout à jour.

Un WAF seul me protège-t-il?#

Pas de façon complète. Cloudflare, la CISA et le NCSC suisse traitent le WAF comme une couche temporaire. L’avis du PHP affirme que seule la mise à jour est une solution complète. Gardez le WAF actif et priorisez le correctif, car une règle réseau n’efface ni un état mémoire corrompu ni un webshell déjà posé. Utilisez le WAF pour gagner du temps de déploiement, pas pour fermer le ticket.

PHP 7.4 ou 8.1 a-t-il une correction officielle de php.net?#

Le projet ne maintient plus de releases officiels sur ces lignes. Il existe une mention de backports sources minimaux pour 7.4, 8.0 et 8.1, et une correction possible via une distribution LTS. Sans l’un de ces chemins, la sortie consiste à migrer vers une ligne supportée déjà corrigée, avec tests de régression sur les extensions. Comptez le délai de migration dans le plan de risque, et non seulement le temps d’installation du paquet.

Comment savoir si mon hébergeur a déjà appliqué le correctif?#

Demandez la version exacte du PHP sur le SAPI web et la référence du paquet ou de l’avis du prestataire. Si la réponse reste vague, traitez comme non corrigé jusqu’à preuve. Une phrase marketing sur « infrastructure sécurisée » ne remplace ni le numéro de build ni la date d’application. Exigez un écrit que vous pouvez joindre au ticket de conformité.

Faut-il retirer le site du réseau?#

Seulement si vous ne pouvez pas appliquer le correctif dans un délai court et que l’exposition à Internet est inacceptable pour votre risque. C’est exactement le scénario où le NCSC et la CISA demandent d’envisager la mise hors ligne. Faites l’évaluation avec le propriétaire du service et la sécurité, pas dans le noir, et documentez le critère de retour en ligne une fois le runtime validé.

Conclusion#

Le php2shell, au sens opérationnel du 21 octobre 2026, est un événement de runtime. Qui opère du PHP doit traiter inventaire, correctif et validation du processus vivant comme une seule chaîne. La majorité des équipes devrait actualiser dès maintenant vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou vers le paquet backporté du vendor, en commençant par ce qui est sur Internet et surtout par mod_php.

La réponse change lorsque vous êtes bloqué sur une ligne morte sans LTS, lorsque le fournisseur embarque PHP sans transparence, ou lorsqu’il existe déjà un indice de compromis. Dans ces cas, l’ordre devient confinement, preuve, puis seulement retour. Le premier pas concret consiste à lister chaque SAPI et chaque version qui sert HTTP aujourd’hui, puis à marquer une date et un responsable pour le correctif.

Ce contenu a un caractère informatif et éducatif sur le php2shell ainsi que sur CVE-2026-109618 et CVE-2026-109619. Il ne remplace ni l’évaluation de votre hébergeur, ni celle de votre équipe de sécurité, ni l’avis d’un professionnel responsable de l’environnement concerné.