Deux failles critiques dans PHP peuvent permettre à un attaquant d’exécuter du code sur un serveur sans s’authentifier. Le problème concerne le moteur utilisé par de nombreux sites WordPress, boutiques en ligne et applications professionnelles. Des correctifs ont été publiés ce jour à 15h30 pour les branches maintenues du langage. Les administrateurs et les hébergeurs sont appelés à les installer rapidement : les réglages provisoires ne suffisent pas à éliminer le risque.
Des attaques possibles avant même l’exécution du site
PHP travaille en coulisses pour générer les pages, traiter les formulaires ou communiquer avec les bases de données. Une vulnérabilité dans ce moteur peut donc affecter des applications très différentes, même lorsque leur propre code ne présente pas le défaut en question. D’après les relevés de W3Techs d’aujourd’hui, PHP est utilisé par 69,3 % des sites dont le langage côté serveur est identifié. Cette proportion mesure sa présence sur le Web, pas le nombre de sites compromis.
Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619. Évaluées à 9,2 sur 10 selon la grille CVSS 4.0, elles touchent la gestion interne de la mémoire. La première peut provoquer un traitement incorrect de données après une interruption liée à un manque de mémoire. La seconde permet la réutilisation d’informations dont la mémoire a déjà été libérée, lors du traitement d’une requête ultérieure.
Les conséquences peuvent dépasser un simple plantage : dans certaines conditions, un attaquant peut faire exécuter son propre code par le serveur.
Le risque est particulièrement élevé avec Apache utilisant le module mod_php. L’équipe PHP décrit une exploitation démontrée dans laquelle une requête sans authentification déclenche l’attaque avant même que le code de l’application commence à fonctionner. PHP-FPM figure également parmi les environnements concernés. Un site ne peut donc pas se considérer comme protégé uniquement parce que son logiciel de publication est à jour.
Quatre versions corrigées à installer sur les serveurs
Après une alerte publiée le 20 octobre, le projet a diffusé les mises à jour de sécurité. Son avis officiel demande de passer immédiatement à la version corrigée correspondant à la branche utilisée :
- PHP 8.2.35 pour la branche 8.2 ;
- PHP 8.3.36 pour la branche 8.3 ;
- PHP 8.4.27 pour la branche 8.4 ;
- PHP 8.5.12 pour la branche 8.5.
Sur un hébergement mutualisé ou administré, le déploiement dépend généralement du prestataire. Il faut lui demander confirmation que les deux correctifs ont été appliqués à l’environnement qui traite les requêtes du site. La publication d’une mise à jour ne signifie pas que tous les hébergements en disposent déjà.
Les distributions Linux et les fournisseurs de maintenance prolongée ont reçu les corrections en amont. Certains peuvent les intégrer à leurs propres paquets en conservant un numéro de version PHP antérieur. Dans ce cas, le bulletin de sécurité du fournisseur et la révision du paquet installé permettent de vérifier que les vulnérabilités sont corrigées.
La commande php -v constitue un premier contrôle, mais elle affiche uniquement la version de l’interpréteur lancé dans le terminal. Celle utilisée par le serveur web peut être différente, notamment lorsque plusieurs versions cohabitent sur la même machine. La vérification doit donc porter sur chaque environnement réellement utilisé par les sites, puis sur la bonne prise en compte du moteur corrigé par les services concernés.
Cette intervention reste distincte de la maintenance du logiciel de publication. Installer une version comme WordPress 7.1 ou corriger une faille d’Elementor ne met pas automatiquement à jour le moteur PHP de l’hébergement.
Dans php.ini, un réglage temporaire qui ne remplace pas le correctif
Pour les serveurs dont la mise à jour reste en attente, PHP décrit une mesure permettant de limiter certains chemins d’exploitation liés aux sessions. Elle consiste à désactiver le suivi de progression des envois de fichiers, en ajoutant ou en modifiant cette directive dans le fichier php.ini utilisé par le serveur web :
session.upload_progress.enabled = Off
Il faut ensuite redémarrer tous les processus PHP concernés : PHP-FPM lorsqu’il est utilisé, ou Apache lorsque PHP fonctionne comme module. Modifier uniquement le fichier de configuration destiné à la ligne de commande ne garantit pas que le réglage soit appliqué aux sites. La configuration doit être chargée avant l’analyse des requêtes ; un appel à ini_set() dans un script arrive trop tard, et PHP déconseille aussi de compter sur un fichier .user.ini avec PHP-FPM pour cette mesure.
La portée de ce changement reste limitée. Le bulletin technique officiel indique qu’il bloque des chemins d’attaque confirmés liés aux sessions pour CVE-2026-109619, mais pas toutes les variantes. Il ne constitue donc pas une protection complète contre les deux failles.
Cette option sert à suivre l’avancement d’un fichier envoyé vers le serveur. La désactiver peut affecter les indicateurs de progression qui reposent sur ce mécanisme, mais elle n’interdit pas les téléversements. Elle peut rester désactivée après correction si l’application n’en a pas besoin.
Attentions aux anciennes branches
PHP 8.1 et les versions antérieures ne bénéficient plus de la maintenance normale du projet. Face à la gravité de ces failles, l’équipe a néanmoins fourni des correctifs minimaux à intégrer au code source de PHP 7.4, 8.0 et 8.1. Des fournisseurs de support prolongé peuvent également proposer leurs propres paquets corrigés. Ces dispositions exceptionnelles ne rétablissent pas le suivi habituel de ces anciennes branches.
Pour les administrateurs restés sur PHP 8.2, une autre échéance approche : son support de sécurité par le projet prendra fin le 31 décembre 2026. L’installation de PHP 8.2.35 répond à l’urgence actuelle, tandis qu’une migration vers une branche maintenue plus longtemps doit également être préparée.
