Deux CVE critiques : que sait-on ?
CVE-2026-109618 touche la gestion de mémoire insuffisante : des données de requête partiellement initialisées peuvent être mal interprétées lors du nettoyage. CVE-2026-109619 concerne un état interne conservé après libération de sa mémoire, susceptible d’être réutilisé lors d’une requête suivante. Les deux failles sont notées 9,2/10 (CVSS 4.0) par le projet PHP. Elles peuvent conduire à une exécution de code à distance sans authentification.
Le bulletin concerne les installations PHP qui traitent des requêtes web : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP considère le risque particulièrement élevé pour mod_php, avec une exploitation démontrée. Cela ne signifie pas que tous les sites ont été compromis.
Versions corrigées
- PHP 8.2 : 8.2.35
- PHP 8.3 : 8.3.36
- PHP 8.4 : 8.4.27
- PHP 8.5 : 8.5.12
PHP 8.1 et les branches antérieures ne sont plus corrigées par le projet PHP : migrer vers une version maintenue ou vérifier les correctifs rétroportés par le fournisseur. Les distributions Linux peuvent appliquer des correctifs sans adopter exactement le numéro de version amont. PHP 8.2 atteindra sa fin de support le 31 décembre 2026.
Vérifier la version réellement exécutée
Un php -v sur l’hôte ne renseigne pas forcément sur la version du service web. Avec Docker, il faut inspecter les images et les processus PHP dans les conteneurs. Exemple de commandes de lecture seule :
php -v
docker compose ps
docker compose exec -T NOM_DU_SERVICE php -vRemplacez NOM_DU_SERVICE par le service PHP réellement utilisé. Vérifiez également les paquets et bulletins de sécurité de la distribution.
Plan de correction
- Inventorier les instances PHP qui servent des requêtes publiques, y compris les conteneurs.
- Identifier la version corrigée ou le correctif rétroporté officiellement confirmé.
- Sauvegarder les données et tester la mise à jour en préproduction.
- Mettre à jour les paquets ou reconstruire les images avec une base corrigée, puis redéployer les services.
- Contrôler la version et les correctifs dans les nouveaux processus, les journaux et les parcours applicatifs.
Redémarrer un conteneur qui utilise encore une image vulnérable ne suffit pas. Les mesures de configuration évoquées par PHP ne protègent pas complètement : la mise à jour reste indispensable.
Et si le serveur était exposé avant la correction ?
Examiner les journaux, les anomalies et les éventuels indicateurs de compromission en fonction de l’exposition. Une version vulnérable ne prouve pas une intrusion ; une mise à jour n’efface pas une intrusion antérieure.
Pour organiser l’inventaire de vos composants, découvrez la Veille logiciels TechAtelier.