PHP2Shell : ce que font CVE-2026-109618 et CVE-2026-109619, et les attaques déjà observées

Deux failles du moteur PHP, avec des conditions d’exploitation différentes

Point technique arrêté au 21 octobre 2026 : les deux vulnérabilités PHP2Shell sont classées critiques, avec un score CVSS v4.0 de 9,2. Les avis PHP les décrivent comme pouvant conduire à une exécution de code à distance sans authentification. Leur exploitabilité dépend du mode d’exécution et des chemins de traitement atteignables.

L’avis de publication vise les installations PHP servant des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Un contrôle effectué uniquement sur le binaire PHP en ligne de commande ne suffit pas à caractériser le service HTTP réellement exécuté.

Je distingue ici le mécanisme documenté, les conséquences possibles et les observations d’attaque. Un démonstrateur de recherche prouve une possibilité d’exploitation dans son contexte ; il ne prouve pas à lui seul qu’un serveur de production a été compromis.

CVE-2026-109618 : une interruption OOM laisse des données incomplètes

Selon GHSA-w8hw-w9fx-j79w, PHP peut utiliser longjmp() pour interrompre une requête lors d’un manque de mémoire, ou OOM. Si cette sortie intervient pendant une initialisation inachevée, la procédure de fin de requête peut ensuite utiliser des données internes invalides. Une organisation contrôlée de la mémoire peut transformer ce défaut en RCE.

L’avis décrit notamment des chemins liés à l’analyse multipart et à la consommation mémoire. Une limite apparente sur la taille de la requête ne garantit donc pas que toutes les allocations restent sûres. Avec Apache mod_php, l’exploitation démontrée peut se produire avant l’exécution du code applicatif.

PHP-FPM termine son processus enfant si le démarrage de la requête échoue. Ce comportement bloque ce chemin précis, mais l’avis considère FPM susceptible à d’autres chemins après initialisation ; il ne présente pas d’exploitation FPM complète démontrée. Passer à FPM ne constitue donc pas un correctif.

Le correctif remplace l’interruption OOM immédiate par une gestion différée à un point sûr de la machine virtuelle, avec arrêt immédiat du processus au-delà d’un second seuil. Il vise à éviter que le nettoyage rencontre ces données incomplètes.

CVE-2026-109619 : un état global survit à la mémoire d’une requête

L’avis GHSA-6wmf-4rv5-p3rp décrit un use-after-free entre requêtes. Un processus de travail conserve une référence globale vers une mémoire appartenant à une requête terminée. Si cette référence n’est pas remise à zéro, une requête suivante du même processus peut l’utiliser après libération de la mémoire.

L’exploitation demande un producteur qui laisse cet état périmé et un consommateur qui le consulte avant sa réinitialisation normale. Une erreur fatale peut interrompre la remise à zéro ; certains diagnostics pendant la fin de requête peuvent aussi recréer cet état.

Les consommateurs confirmés incluent des diagnostics de configuration avant initialisation et des chemins de session liés au suivi des téléversements. Masquer les messages d’erreur ne supprime pas leur exécution interne. Les versions et conditions précises varient selon le chemin décrit dans l’avis.

Vol de données, webshell, rançongiciel : quels liens peut-on établir ?

Wiz, qui a participé à la recherche, documente des possibilités de divulgation mémoire et d’exécution de code. Une fuite mémoire peut exposer des informations présentes dans le processus. Une RCE permet de faire exécuter des instructions avec les droits du processus PHP ; l’impact dépend alors de ses permissions et des ressources accessibles.

Comme scénarios de risque, je retiens la lecture de secrets applicatifs, l’altération de pages ou l’installation d’une porte dérobée de type webshell. Un mineur de cryptomonnaie ou un rançongiciel pourrait aussi constituer une étape ultérieure si les accès obtenus le permettent. Ces exemples décrivent des conséquences possibles, sans attribuer de campagne à PHP2Shell.

Une exécution de code dans PHP ne donne pas automatiquement les droits administrateur du système. La séparation des services et la restriction des droits peuvent limiter l’impact. Elles ne corrigent pas la vulnérabilité.

Y a-t-il déjà eu des attaques au 21 octobre 2026 ?

Oui : dans son billet du 21 octobre, Cloudflare dit avoir observé du trafic d’attaque visant ses clients et des modifications des charges envoyées pour tenter de contourner ses protections. Il s’agit d’une observation de tentatives d’exploitation rapportée par cet opérateur.

Le CERT-EU signale également la circulation de premières preuves de concept et estime que cela augmente la probabilité d’une exploitation en cours. Cette appréciation du risque n’est pas une liste de victimes confirmées.

Les sources citées ici ne permettent pas d’établir un bilan de compromissions réussies ni de relier ces failles à un groupe ou à un rançongiciel précis. Pour un incident donné, il faut rapprocher les requêtes reçues des événements du serveur et des traces après exploitation. Un événement WAF bloqué ne prouve ni une compromission réussie ni l’absence d’autres chemins d’accès.

Corriger le runtime et contrôler chaque processus en service

Les versions publiées par PHP pour corriger les deux failles sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Vérifier aussi les bulletins du fournisseur : Ubuntu distribue des correctifs rétroportés avec ses propres versions de paquets, notamment pour PHP 8.1. Une version courte affichée par PHP ne permet pas, seule, de conclure.

1. Inventorier les processus HTTP PHP, leurs modules, les images et les paquets réellement déployés, puis vérifier l’avis correspondant à chaque fournisseur.
2. Isoler les services vulnérables exposés lorsque la correction immédiate est impossible. Un filtrage applicatif reste une mesure complémentaire.
3. Installer le correctif sur toutes les instances et remplacer les anciens processus. Contrôler ensuite le runtime du service web et les parcours applicatifs essentiels.
4. Conserver les journaux et examiner les anomalies : erreurs mémoire, arrêts de processus, fichiers ou comptes inattendus. Ces indices demandent une investigation et ne sont pas spécifiques à ces deux CVE.

PHP précise que les atténuations de configuration ne couvrent pas tous les chemins. Désactiver session.upload_progress.enabled et redémarrer les workers réduit certains chemins confirmés de la seconde faille. Cela ne rend pas l’installation sûre.

Je déconseille d’appliquer memory_limit=-1 isolément comme recette d’urgence : supprimer cette limite impose de maîtriser la consommation mémoire autrement et ne couvre pas tous les échecs d’allocation. Se reporter à l’avis PHP actualisé pour les atténuations complètes et leurs limites, tout en donnant la priorité au correctif.

Sources et liens utiles

• PHP : avis et versions du 21 octobre 2026
• Avis PHP CVE-2026-109618 : RCE via OOM corruption, 21 octobre 2026
• Avis PHP CVE-2026-109619 : RCE via stale global state, 21 octobre 2026
• Wiz Research : analyse PHP2Shell, 21 octobre 2026
• Cloudflare : tentatives d’attaque et protections observées, 21 octobre 2026
• CERT-EU : niveau de risque et recommandations, 21 octobre 2026
• Ubuntu : versions complètes des paquets corrigés, USN-8948-1
• Failles PHP : comprendre et protéger son site