L’équipe de sécurité de PHP a publié des mises à jour pour corriger deux vulnérabilités critiques susceptibles de permettre à un attaquant non authentifié d’exécuter du code à distance sur un serveur. Identifiées sous les références CVE-2026-109618 et CVE-2026-109619, les deux failles affichent un score de gravité de 9,2 sur 10 selon CVSS 4.0.
Le risque concerne les installations PHP qui traitent des requêtes web, notamment celles reposant sur PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed. L’équipe PHP considère que les configurations utilisant mod_php sont particulièrement exposées, car un exploit démontré peut déclencher la vulnérabilité avant même l’exécution du code de l’application.
Les administrateurs sont invités à mettre à jour leurs installations sans attendre.
Deux vulnérabilités pouvant conduire à une prise de contrôle
La première faille, CVE-2026-109618, concerne la gestion des erreurs d’allocation mémoire. Dans certaines circonstances, un échec lié à la mémoire peut interrompre PHP alors que des données internes de la requête ne sont pas entièrement initialisées. Le nettoyage qui suit peut alors traiter ces données invalides comme si elles étaient correctes, ouvrant la voie à une exécution de code à distance.
La seconde vulnérabilité, CVE-2026-109619, porte sur la persistance d’un état global interne après la libération de la mémoire associée. Une requête ultérieure traitée par le même processus peut réutiliser cet état devenu invalide avant que l’initialisation normale ne le réinitialise.
Dans les deux cas, le risque ne se limite pas à une erreur de fonctionnement du serveur. Une exploitation réussie peut permettre l’exécution de code arbitraire sans authentification préalable, avec des conséquences potentielles sur les données et les ressources accessibles au processus PHP.
Quelles versions de PHP sont concernées ?
L’avis officiel confirme la disponibilité de quatre versions correctives pour les branches maintenues :
| Branche PHP | Version corrigée |
|---|---|
| 8,5 PHP | 8.5.12 |
| 8,4 PHP | 8.4.27 |
| 8,3 PHP | 8.3.36 |
| 8,2 PHP | 8.2.35 |
Les versions antérieures à ces correctifs sont concernées. 8,1 PHP et les branches plus anciennes ne reçoivent plus directement de mises à jour de sécurité du projet PHP. Certains distributeurs Linux et fournisseurs de support à long terme peuvent néanmoins proposer des correctifs rétroportés.
Les administrateurs doivent donc vérifier non seulement le numéro de version installé, mais aussi la politique de maintenance de leur fournisseur. Pour les installations qui ne peuvent pas recevoir de correctif, une migration vers une version prise en charge doit être planifiée.
Une attention particulière s’impose pour 8,2 PHP : cette branche doit arriver en fin de vie le 31 décembre 2026. La version 8.2.35 corrige les vulnérabilités actuelles, mais les utilisateurs devront préparer leur migration pour continuer à recevoir des mises à jour de sécurité par la suite.
Comment protéger immédiatement un serveur PHP ?
La recommandation prioritaire est d’installer la version corrigée correspondant à la branche utilisée. PHP précise qu’aucune mesure de contournement ne remplace complètement la mise à jour.
Les administrateurs qui ne peuvent pas corriger immédiatement leur environnement doivent évaluer le risque et envisager d’isoler temporairement les systèmes vulnérables. Le CERT-FR recommande également cette approche pour les équipements concernés qui ne peuvent pas être mis à jour dans l’immédiat.
L’avis officiel de PHP décrit plusieurs mesures temporaires destinées à réduire l’exposition à des chemins d’attaque précis :
- Pour CVE-2026-109618, la configuration
memory_limit=-1peut empêcher le déclenchement du chemin vulnérable lié à la limite mémoire contrôlable par PHP. Cette mesure ne supprime toutefois pas tous les scénarios d’échec d’allocation mémoire. PHP recommande également de limiter la taille des requêtes entrantes, notamment avecpost_max_size, et de contrôler les volumes de données au niveau du serveur web ou du proxy. - Pour CVE-2026-109619, désactiver
session.upload_progress.enabledet redémarrer les processus concernés bloque certains chemins d’exploitation confirmés, mais pas toutes les variantes possibles. - Sur 8,5 PHP, désactiver les traces de pile associées aux erreurs fatales avec
fatal_error_backtraces=0réduit également une voie d’exploitation identifiée, sans constituer une protection générale.
Ces mesures nécessitent une configuration adaptée à l’environnement et peuvent modifier le comportement de certaines applications, notamment celles qui utilisent la progression des téléversements. Elles doivent être considérées comme des protections provisoires, et non comme une alternative au déploiement des versions corrigées. <Cite refs={[« turn221757view0 », »turn221757search3 »]}/>
WordPress et les autres applications PHP sont aussi concernés
Ces vulnérabilités ne sont pas spécifiques à WordPress. Elles touchent le moteur PHP lui-même et peuvent donc affecter toute application web exécutée sur une installation vulnérable, quelle que soit la plateforme utilisée.
L’équipe WordPress recommande aux propriétaires de sites de vérifier la version PHP utilisée par leur hébergement et de contacter leur fournisseur si une mise à jour est nécessaire. Dans WordPress, la version peut notamment être consultée dans Outils → Santé du site → Informations → Serveur. Aucune mise à jour spécifique de WordPress n’est requise pour corriger ces failles : c’est l’environnement PHP qui doit être mis à jour.
Les hébergeurs peuvent gérer les correctifs au niveau de leur infrastructure, mais les propriétaires de sites ne doivent pas supposer que l’opération a déjà été effectuée. Une vérification auprès du fournisseur reste nécessaire si la version installée ou l’état de la mise à jour n’est pas clairement indiqué.
Une mise à jour à traiter comme une priorité de sécurité
La publication des correctifs met fin à la période d’attente annoncée la veille par l’équipe PHP. Les administrateurs disposent désormais des versions corrigées et des informations nécessaires pour identifier les branches concernées.
Étant donné la possibilité d’exécution de code à distance sans authentification, la priorité consiste à inventorier les serveurs exposés, vérifier leur version de PHP et déployer le correctif approprié. Les systèmes qui ne peuvent pas être mis à jour immédiatement doivent faire l’objet de mesures temporaires et d’une évaluation du risque.
La consigne est claire : mettre PHP à jour sans délai. Les contournements peuvent réduire certaines possibilités d’exploitation, mais seule l’installation d’une version corrigée constitue la remédiation complète recommandée par le projet.
