Ce qui s'est passé
Deux vulnérabilités du cœur de PHP, découvertes par Wiz Research, ont été corrigées le 21 octobre. Toutes deux sont notées 9,2/10 (critique) en CVSS 4.0.
# CVE-2026-109618
Corruption mémoire lors de la gestion d'un dépassement de mémoire (« out of memory ») : PHP nettoie une requête dont les données internes ne sont qu'à moitié initialisées // score 9,2
# CVE-2026-109619
« Use-after-free » : un état interne survit à la libération de sa mémoire et est réutilisé par la requête suivante traitée par le même processus // score 9,2
La publication a été précipitée par une fuite. Le 20 octobre, un message sur Hacker News a révélé les identifiants CVE avant la date prévue, selon Infosecurity Magazine. L'équipe sécurité de PHP a alors publié ses correctifs le 21 octobre à 14 h GMT au lieu du 22. Le CERT-EU et le NCSC britannique ont aussitôt appelé à patcher sans délai.
# Qui est concerné
Pratiquement toute installation PHP qui sert des pages web est vulnérable : toutes les versions de 5.4 à 8.5.11, selon Google Cloud.
Branche PHP > Version corrigée
• 8.5 > 8.5.12
• 8.4 > 8.4.27
• 8.3 > 8.3.36
• 8.2 > 8.2.35
• 8.1 et antérieures > Aucun correctif officiel : migrer vers 8.2 ou plus, ou passer par un correctif de votre distribution
Tous les modes d'exécution sont touchés : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. Apache avec mod_php est le cas le plus exposé, car l'attaque peut réussir avant même que le code de l'application ne s'exécute (Rapid7). PHP-FPM, le plus répandu aujourd'hui, est aussi exploitable, par des chemins plus complexes.
Point d'attention : le suivi de progression des uploads de session (session.upload_progress), activé par défaut, ouvre une voie d'attaque même si votre application n'utilise jamais les sessions.
# Les risques concrets
Un attaquant peut prendre la main sur le serveur avec les droits du processus web, sans identifiant ni action de l'utilisateur. Concrètement, cela ouvre la porte à :
• l'installation d'une porte dérobée ou d'un web shell ;
• le vol de données : base clients, identifiants de base de données, clés d'API stockées dans la configuration ;
• la modification du site (injection de code malveillant, redirections, skimming de cartes sur un e-commerce) ;
• un rebond vers le reste de votre infrastructure.
Au 21 octobre, aucune exploitation active n'était encore confirmée. Mais les chercheurs ont déjà développé un exploit fonctionnel, plusieurs équipes reproduisent la recherche, et Rapid7 s'attend à la publication rapide d'un exploit public. Avec la part de PHP sur le web, les attaques de masse ne devraient pas tarder.
# Que faire maintenant
La seule vraie correction est la mise à jour vers une version qui embarque les deux correctifs. Voici l'ordre des opérations.
1. Inventorier. Repérez tous vos serveurs, conteneurs et hébergements PHP, y compris les vieux sites oubliés. Sur chaque machine, php -v donne la version.
2. Mettre à jour en urgence. Passez en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou appliquez le paquet de sécurité de votre distribution Linux (Debian, Ubuntu, Red Hat…), qui a reçu les correctifs en avance.
3. Redémarrer tous les processus PHP. Un PHP-FPM ou un Apache qui n'est pas redémarré continue d'exécuter l'ancien code.
4. Reconstruire les images Docker. Une image basée sur un PHP vulnérable reste vulnérable tant qu'elle n'est pas reconstruite et redéployée.
5. Solliciter votre hébergeur. En mutualisé ou en infogérance, vérifiez qu'il a bien appliqué le correctif ; c'est souvent lui qui gère la version de PHP.
6. Planifier la sortie des versions obsolètes. PHP 8.1 et antérieur ne recevront pas de correctif officiel : la migration vers 8.2 minimum devient prioritaire.
Si vous ne pouvez pas patcher tout de suite
Ces réglages, à placer dans php.ini ou dans la configuration du pool FPM (pas dans l'application), réduisent l'exposition sans la supprimer :
• session.upload_progress.enabled = 0, puis redémarrage de tous les workers ;
• sur PHP 8.5, fatal_error_backtraces = 0 ;
• limiter post_max_size (8M si vous n'avez pas d'upload, 32M sinon) ;
• bloquer les requêtes multipart au niveau du reverse proxy ou du WAF si votre application n'en a pas besoin ;
• à défaut, isoler les applications exposées sur Internet, comme le recommande le CERT-EU.
Attention aux fausses pistes : masquer les erreurs (display_errors, @) ne protège de rien, et l'absence de traces dans les logs ne prouve pas qu'un serveur est sain.
# En résumé
PHP2Shell fait partie des failles les plus sérieuses qu'ait connues PHP : exécution de code à distance, sans authentification, sur presque toutes les versions. La fenêtre avant les premières attaques de masse se compte en jours. Mettez à jour, redémarrez, vérifiez, et profitez-en pour faire le ménage dans vos versions de PHP en fin de vie.
