Michael JohnsonLe 21 octobre 2026, PHP a annoncé deux vulnérabilités critiques susceptibles de permettre l’exécution de code à distance sans authentification. Le même jour, le projet a publié des correctifs pour les branches 8.5, 8.4, 8.3 et 8.2 et a recommandé aux utilisateurs de mettre à jour sans délai. Les installations qui traitent des requêtes web peuvent être vulnérables, notamment PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed, indique PHP.
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces versions corrigent CVE-2026-109618, liée à la corruption de l’état en cas de manque de mémoire, et CVE-2026-109619, un problème par lequel l’état d’une requête pouvait persister dans un processus de travail et être réutilisé lors du traitement de la requête suivante. Les versions antérieures à celles indiquées sont concernées. Le projet ne publie plus de mises à jour pour PHP 8.1 et les branches plus anciennes ; les administrateurs de ces systèmes devraient donc vérifier si leur fournisseur de distribution ou leur prestataire de support à long terme propose des correctifs.
Deux erreurs dans le cycle de vie des requêtes web
Dans le cas de CVE-2026-109618, le traitement d’une requête peut être interrompu par un manque de mémoire alors que les données internes ne sont pas encore entièrement initialisées. À la fin de l’exécution, PHP peut alors accéder à un état incorrect. Dans son avis de sécurité, l’équipe décrit notamment des scénarios impliquant des requêtes multipart et l’épuisement de la limite mémoire. Pour Apache mod_php, un scénario où le problème survient avant même l’exécution du code de l’application a été confirmé ; PHP indique également que le risque est plus élevé pour cette configuration.
CVE-2026-109619 concerne l’état conservé par un processus de travail entre les requêtes. Si une opération échoue avant le nettoyage des données, la mémoire de la requête précédente est libérée, mais un pointeur vers celle-ci demeure. La requête suivante, si elle est traitée par le même processus, peut accéder à cet état périmé avant l’initialisation habituelle. Dans son avis de sécurité, PHP décrit des vecteurs confirmés passant par des opérations de diagnostic précoces et le traitement de la progression des téléversements de fichiers ; la pertinence de chaque vecteur dépend de la configuration, de l’application et des extensions utilisées.
Les deux vulnérabilités ont reçu une note de 9,2 selon CVSS 4.0. Selon PHP, l’impact confirmé comprend l’exécution de code avec les privilèges du processus de travail web. Pour le problème lié au manque de mémoire, l’avis confirme un scénario HTTP complet contre mod_php ; pour PHP-FPM, il décrit une analyse du code et les conditions de vulnérabilité. Il est donc important de distinguer ces éléments lors de l’évaluation d’un déploiement particulier.
Points à vérifier pour les administrateurs
Commencez par déterminer quelles versions de PHP traitent réellement le trafic web : un même serveur peut exécuter des versions distinctes pour CLI, FPM et Apache, tandis que les conteneurs et les nœuds d’un cluster sont mis à jour indépendamment. Installez, pour chaque branche prise en charge, la version corrigée correspondante ou un paquet du fournisseur contenant le correctif confirmé. Redémarrez ensuite tous les processus PHP et vérifiez leur version après le redémarrage : remplacer les fichiers sans redémarrer laisse les anciens processus en fonctionnement.
Pour PHP 8.1 et les versions antérieures, vérifiez le statut du support et la disponibilité d’un correctif rétroporté auprès de votre distribution ou de votre fournisseur de support à long terme. Si aucun paquet n’est proposé, planifiez la migration vers une branche prise en charge. PHP indique que les fournisseurs de distributions Linux ont reçu les correctifs à l’avance ; le numéro de version de leur paquet peut différer de celui de la version officielle de PHP. Vérifiez donc précisément si le correctif est inclus.
Des réglages temporaires et le filtrage des requêtes peuvent réduire certains vecteurs d’attaque, mais le projet considère la mise à jour comme le seul moyen de corriger complètement les deux problèmes. Pour les équipes, la priorité pratique consiste à inventorier tous les processus de travail web, installer le paquet corrigé, redémarrer les processus et vérifier le résultat sur chaque nœud. C’est cette démarche qui corrige les vulnérabilités confirmées, plutôt que de s’en remettre uniquement à la configuration du serveur web.