PHP : quatre mises à jour corrigent deux failles critiques d'exécution de code à distance

Les correctifs sont disponibles. Après un avertissement lancé la veille, l'équipe de PHP a publié le 21 octobre 2026 quatre versions de sécurité contre deux failles critiques permettant, dans certains contextes, une exécution de code à distance sans authentification. Les administrateurs de sites et les hébergeurs utilisant PHP doivent désormais vérifier la version réellement exécutée par leurs services.
Le bulletin officiel de PHP cite les vulnérabilités CVE-2026-109618 et CVE-2026-109619. Le CERT-FR confirme le risque d'exécution de code arbitraire à distance. Il ne s'agit plus d'une simple annonce de correctifs à venir : les versions réparées sont publiées.
Quelles versions installer ?
Les versions corrigées annoncées par le projet sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Sur chacune de ces branches, une version inférieure reste concernée. Les branches plus anciennes ne reçoivent plus toutes des correctifs directs de la part du projet PHP ; des distributions Linux et fournisseurs de support à long terme peuvent néanmoins proposer des correctifs rétroportés.
Attention à ne pas confondre numéro de version apparent et niveau de protection. Sur un serveur administré par Debian, Ubuntu ou un hébergeur, le paquet fourni par le distributeur peut intégrer une correction sans adopter le dernier numéro de version publié sur php.net. L'information à vérifier est celle du bulletin de sécurité du fournisseur.
Deux failles, plusieurs configurations exposées
Le projet PHP décrit un problème de gestion de mémoire lorsque certaines données internes sont partiellement initialisées (CVE-2026-109618) et un second problème lié à un état interne conservé après la libération de sa mémoire (CVE-2026-109619). Ils peuvent conduire à une exécution de code dans le processus PHP.
Le risque concerne notamment les installations PHP servant des requêtes web, dont PHP-FPM, Apache avec mod_php, php-cgi et d'autres serveurs d'applications. PHP indique avoir démontré un scénario particulièrement critique avec mod_php, dans lequel une requête non authentifiée suffit avant même l'exécution du code applicatif. Cela ne veut pas dire que chaque site PHP a déjà été compromis.
Le projet précise aussi qu'aucune mesure d'atténuation partielle ne remplace une mise à jour. Modifier quelques réglages pour réduire l'exposition ne doit pas devenir un motif pour reporter le correctif.
Les gestes prioritaires pour les responsables de sites
Faire l'inventaire des applications utilisant PHP, confirmer les versions réellement chargées par les processus web, appliquer les paquets corrigés provenant du projet ou du distributeur, puis redémarrer les travailleurs PHP concernés pour qu'ils chargent le nouveau code. Il faut aussi tenir compte des environnements de test, conteneurs et hébergements mutualisés, où un site peut fonctionner sur une version différente de celle annoncée par son interface d'administration.
Avant une mise à jour sensible, conserver une sauvegarde exploitable et surveiller les journaux de fonctionnement. Cette précaution évite de confondre un problème de compatibilité après déploiement avec une attaque. Les utilisateurs ordinaires, eux, n'ont pas à modifier leur navigateur : la correction appartient surtout aux personnes et entreprises qui exploitent des serveurs PHP.

