Le projet PHP a publié le 21 octobre 2026 des correctifs pour deux failles critiques baptisées PHP2Shell (CVE-2026-109618 et CVE-2026-109619, score CVSS 9,2). Une seule requête HTTP non authentifiée peut suffire à exécuter du code sur le serveur, avant même le chargement de l'application. Une tentative d'exploitation a déjà été observée. Tous les serveurs Web qui exécutent PHP doivent être mis à jour sans délai.
Analyse
La première faille (CVE-2026-109618) survient lorsqu'une allocation mémoire échoue pendant l'initialisation d'une requête : PHP laisse des données partiellement initialisées que la routine de nettoyage traite ensuite comme valides, ce qui corrompt la mémoire et permet l'exécution de code.
La seconde faille (CVE-2026-109619) provient d'un état interne qui survit à la fin d'une requête alors que sa mémoire a été libérée. Une requête suivante traitée par le même processus peut réutiliser cet état périmé et en prendre le contrôle.
Ces failles touchent toute installation PHP qui sert des pages Web : PHP-FPM, Apache avec mod_php, php-cgi, LiteSpeed et FrankenPHP. Le traitement a lieu avant l'exécution du code applicatif, si bien que l'authentification de l'application ne protège pas. L'attaque ne provoque pas nécessairement de plantage, ce qui la rend discrète.
Le pot de miel d'Amazon a enregistré une tentative d'exploitation le 17 octobre 2026, soit quatre jours avant la divulgation publique. Les branches PHP 5 à 8.1 sont en fin de vie et ne recevront pas de correctif officiel.
Recommandations
- Mettre à jour PHP vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 selon la branche utilisée.
- Vérifier la version en service avec la commande php -v ou dans le gestionnaire PHP de l'hébergeur (cPanel, Plesk).
- Migrer sans attendre les applications encore sous PHP 8.1 ou antérieur vers une branche maintenue.
- Isoler ou mettre hors ligne tout serveur qui ne peut pas être corrigé immédiatement, comme le recommande le NCSC britannique.
- Activer les règles de pare-feu applicatif (WAF) disponibles en complément, sans les considérer comme un substitut au correctif.
- Ne pas se fier au contournement session.upload_progress.enabled=0, qui ne protège pas contre ces failles.
- Surveiller les processus shell lancés par PHP, les erreurs de mémoire épuisée et les envois de formulaires anormalement volumineux.
- Signaler au club tout incident ou indicateur de compromission constaté.