Retour à la liste des articles

PHP2Shell : correctifs PHP disponibles pour deux failles RCE critiques

Publié le 2026-10-21 Écrit par Équipe GLOV

Mise à jour du 22 octobre 2026 — Les correctifs PHP sont disponibles depuis le 21 octobre. Les vulnérabilités CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom « PHP2Shell », sont toutes deux classées critiques (CVSS v4.0 : 9,2/10). L'équipe PHP confirme qu'elles peuvent permettre une exécution de code à distance sans authentification sur des installations exposées. L'alerte préventive que nous avions publiée le 21 octobre est donc remplacée par des informations confirmées et un plan d'action opérationnel.

À retenir : mettre à jour immédiatement PHP vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon la branche utilisée, ou appliquer le paquet corrigé fourni par la distribution. Aucune mesure de configuration ou règle WAF ne remplace entièrement le correctif. Les systèmes accessibles depuis Internet sont prioritaires.

Ce que l'éditeur a confirmé le 21 octobre

Dans son avis officiel du 21 octobre 2026, le projet PHP décrit deux vulnérabilités distinctes, leurs mécanismes et quatre versions corrigées :

  • PHP 8.5 : 8.5.12 (et versions ultérieures corrigées).
  • PHP 8.4 : 8.4.27 (et versions ultérieures corrigées).
  • PHP 8.3 : 8.3.36 (et versions ultérieures corrigées).
  • PHP 8.2 : 8.2.35 (et versions ultérieures corrigées).

L'équipe PHP attribue à chacune une sévérité de 9,2/10 selon CVSS v4.0. Le CERT-FR (ANSSI), dans l'avis CERTFR-2026-AVI-1359, confirme un risque d'exécution de code arbitraire à distance et recense également les anciennes branches non corrigées.

Il s'agit d'un défaut du moteur PHP, et non d'une vulnérabilité propre à WordPress, PrestaShop, Dolibarr ou un autre CMS. Mettre à jour uniquement l'application ou ses extensions ne corrige donc pas le moteur PHP vulnérable.

Deux failles, deux mécanismes techniques

CVE-2026-109618 : corruption lors d'un manque de mémoire

L'avis GHSA-w8hw-w9fx-j79w décrit un défaut de gestion des erreurs d'épuisement mémoire (out of memory, OOM). Une interruption pendant l'initialisation de données internes d'une requête peut laisser ces données dans un état incohérent ; leur nettoyage ultérieur peut entraîner une corruption mémoire et une exécution de code.

Selon PHP, une exécution de code à distance sans authentification a été validée via HTTP avec Apache mod_php, y compris dans des configurations usuelles à plusieurs processus. Les conditions et la fiabilité d'exploitation varient néanmoins selon les compilations, extensions, allocateurs mémoire et frontaux web.

CVE-2026-109619 : état interne périmé entre deux requêtes

L'avis GHSA-6wmf-4rv5-p3rp concerne un état interne lié à une requête qui persiste après libération de sa mémoire. Si un même processus traite ensuite une autre requête, l'utilisation de cet état périmé peut entraîner un accès mémoire invalide (use-after-free), une divulgation d'informations ou une exécution de code.

Les chemins confirmés incluent notamment des traitements liés au suivi de progression des téléversements de session. Cette précision est importante pour comprendre les mesures temporaires, mais elle ne permet pas de conclure qu'une application sans téléversement est nécessairement à l'abri.

Quels serveurs et applications sont exposés ?

Le projet PHP considère toutes les installations PHP qui traitent des requêtes web comme à risque, notamment :

  • PHP-FPM derrière Nginx ou Apache ;
  • Apache avec mod_php, configuration jugée particulièrement préoccupante par l'éditeur ;
  • php-cgi, FrankenPHP et LiteSpeed ;
  • les conteneurs, images applicatives, appliances et interfaces d'administration intégrant PHP.

Des démonstrations techniques existent sur plusieurs CMS, mais présence de PHP ne signifie pas compromission constatée : l'exploitation dépend de la version, du mode d'exécution et de l'environnement.

Les branches PHP 8.1 et antérieures sont hors maintenance officielle du projet PHP. Certains distributeurs ou fournisseurs LTS proposent des correctifs rétroportés. À titre exceptionnel, l'équipe PHP a aussi fourni des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1, destinés notamment aux exploitants qui compilent PHP eux-mêmes : il ne s'agit pas d'un retour de ces branches en maintenance normale. PHP 8.2 atteindra sa fin de vie le 31 décembre 2026.

Y a-t-il des attaques en cours ?

Le suivi de watchTowr, mis à jour le 22 octobre, fait état d'une activité d'exploitation observée le 21 octobre sur son réseau de capteurs. En parallèle, Huntress indiquait ne pas avoir observé d'exploitation sur les systèmes de ses partenaires lors de son point du 21 octobre en fin de journée (heure américaine).

Ces observations portent sur des périmètres de surveillance différents et ne sont pas contradictoires. Elles justifient d'accélérer les corrections, sans affirmer qu'une campagne massive ou des compromissions généralisées seraient démontrées. La détection de tentatives, une preuve de concept et la confirmation d'une compromission sont trois niveaux de preuve distincts.

Plan d'action pour corriger sans interrompre la production

1. Inventorier les moteurs PHP réellement exécutés

Répertorier les applications, les hôtes et conteneurs, leurs versions, leurs modes d'exécution et leur exposition réseau. La commande php -v renseigne la version en ligne de commande, qui peut différer de celle chargée par PHP-FPM ou le serveur web. Vérifier aussi les pools multiples, les images Docker, les tâches planifiées et les logiciels tiers qui embarquent PHP.

2. Déployer la bonne correction

Installer la version corrigée dans la branche maintenue utilisée, ou un paquet de sécurité rétroporté par la distribution. Avec Debian, Ubuntu ou un fournisseur LTS, consulter le bulletin du mainteneur et la révision exacte du paquet : un numéro de version amont ancien n'implique pas toujours que le correctif manque. Pour les conteneurs, reconstruire ou mettre à jour l'image applicative puis redéployer ; une mise à jour de l'hôte n'actualise pas le binaire PHP dans un conteneur.

3. Vérifier les applications et le moteur actif

Avant le changement, disposer d'une sauvegarde restaurable des fichiers, configurations et bases de données. Redémarrer ou recharger de manière adaptée les processus PHP concernés pour qu'ils prennent en compte les binaires corrigés. Vérifier la version réellement utilisée par le service web, puis tester connexion, commandes, paiements, traitements asynchrones, imports, tâches planifiées et journaux d'erreur selon le contexte.

4. Traiter les environnements non corrigeables

Restreindre temporairement les services exposés, notamment via VPN, segmentation ou filtrage des accès, selon une analyse de risque. Prévoir une migration des branches en fin de vie et vérifier les avis des éditeurs pour les appliances et produits intégrant PHP.

Mesures temporaires : réduction du risque, pas correction

L'avis officiel PHP fournit des recommandations pour les installations qui ne peuvent pas être mises à jour immédiatement :

  • Désactiver session.upload_progress.enabled dans une configuration chargée avant l'analyse des requêtes, puis redémarrer tous les processus PHP ; cela bloque certains chemins confirmés de la CVE-2026-109619, pas tous les scénarios.
  • Sous PHP 8.5, désactiver fatal_error_backtraces et redémarrer les processus pour réduire l'exposition d'un autre chemin connu.
  • Réexaminer les limites de requêtes, les traitements multipart et les réglages mémoire en suivant les précautions détaillées par PHP. Certaines mesures — notamment modifier memory_limit — peuvent affecter la disponibilité et exigent une validation spécifique.

Ne pas considérer un WAF comme un correctif garanti, même si des protections réseau peuvent atténuer certaines tentatives. Une mise à jour reste la seule solution complète annoncée par PHP.

En cas de suspicion : préserver les traces avant de conclure

Sur un système dont l'investigation est autorisée, conserver les journaux HTTP, reverse proxy, PHP-FPM, système et sécurité, ainsi que les horodatages et empreintes des fichiers utiles. Rechercher les processus anormaux lancés par le service web, les changements non autorisés, les connexions inhabituelles, les tâches planifiées ou les mouvements de secrets.

Ces indices sont des signaux de triage, pas des indicateurs attribuables à eux seuls à PHP2Shell. Corréler les événements à l'exposition réelle et à la chronologie ; préserver les preuves avant toute réinstallation. Si une compromission est confirmée, combiner confinement, renouvellement ciblé des secrets et restauration vérifiée.

Ce que cet épisode rappelle pour GLOV Solutions

Pour GLOV Consulting, cette alerte souligne l'utilité d'un inventaire des dépendances, de procédures de gestion des vulnérabilités et de plans de continuité testés. Elle est distincte de notre article sur l'incident Rank Math PRO, où le risque provenait d'une mise à jour logicielle piégée.

Dans l'exploitation d'infrastructures blockchain comme Snow-Fall, la même vigilance concerne les consoles, services web annexes et outils d'administration : l'inventaire et la correction doivent préserver à la fois la sécurité et la disponibilité.

État des informations au 22 octobre 2026. Les versions corrigées et les mécanismes principaux sont confirmés ; la fiabilité d'exploitation de chaque combinaison système/extension et l'étendue réelle des compromissions observées ne peuvent pas être généralisées. Aucun incident concernant les systèmes GLOV n'est allégué.

Sources officielles et analyses techniques

Articles liés

Retour à la liste des articles