PHP a publié des correctifs pour les branches prises en charge. Les distributions et hébergeurs peuvent intégrer un correctif rétroporté sans modifier le numéro de version. Consultez leur avis avant de conclure qu’un paquet reste vulnérable.
Ce que PHP a annoncé et les risques
Le 21 octobre 2026, le projet PHP a publié des correctifs pour CVE-2026-109618 et CVE-2026-109619, deux failles critiques du runtime. Dans certaines conditions, elles peuvent permettre une exécution de code à distance sans authentification sur des installations qui traitent des requêtes web. PHP recommande de considérer ces installations comme exposées tant que la version et le correctif du fournisseur ne sont pas confirmés.
CVE-2026-109618 concerne la corruption de l’état interne lors d’un manque de mémoire. CVE-2026-109619 décrit un état global qui peut conserver des références à la mémoire d’une requête précédente. Il n’est pas nécessaire de reproduire l’attaque pour appliquer le correctif : mettez à jour de façon contrôlée et vérifiez le fonctionnement de l’application.
L’avis signale un risque particulier pour Apache avec mod_php. Il mentionne également PHP-FPM, php-cgi, FrankenPHP et LiteSpeed. Le risque dépend du runtime, de la configuration et des parcours concernés ; ne supposez pas que toutes les installations sont exposées de la même façon.
Versions concernées et versions corrigées
Le tableau présente les versions publiées par PHP le 21 octobre 2026. « Corrigée à partir de » indique la première version de chaque branche qui contient le correctif officiel. Les paquets système, images de fournisseurs et services PHP gérés peuvent intégrer un correctif rétroporté sans changer le numéro affiché. Consultez aussi l’avis du fournisseur.
Le support de sécurité de PHP 8.2 doit prendre fin le 31 décembre 2026. La version 8.2.35 corrige ces CVE dans cette branche, mais prévoyez de migrer vers une version encore prise en charge. PHP ne publie plus de versions régulières pour 8.1 et les versions antérieures. Des correctifs minimaux existent pour 7.4, 8.0 et 8.1 ; certains fournisseurs maintiennent aussi leurs propres paquets. Vérifiez ce qui est réellement installé.
| Branche PHP | Vulnérable avant | Corrigée à partir de | Support sécurité |
|---|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 | Prise en charge |
| 8.4 | < 8.4.27 | 8.4.27 | Prise en charge |
| 8.3 | < 8.3.36 | 8.3.36 | Prise en charge |
| 8.2 | < 8.2.35 | 8.2.35 | Jusqu’au 31 déc. 2026 |
| 8.1, 8.0 et 7.4 | Concernées ; fin de vie | Correctif minimal ou paquet fournisseur | À confirmer auprès du fournisseur |
| 7.3 et antérieures | Concernées ; fin de vie | Aucune version upstream indiquée | Migrer ; ne pas supposer qu’un correctif existe |
Comparez les versions au sein de leur branche. Les paquets des distributions peuvent inclure des correctifs rétroportés et afficher un numéro différent.
Avant la mise à jour : inventaire et préparation
Repérez tous les environnements où PHP est utilisé : serveurs, conteneurs, images de base, panneaux d’hébergement, produits qui incluent PHP, tâches en arrière-plan et environnements de test. Un site peut utiliser plusieurs versions. Identifiez le service qui reçoit le trafic et la personne responsable de chaque mise à jour.
Notez la version et l’origine du paquet, le système, le serveur web, le runtime, l’image si nécessaire, l’application, l’environnement, le responsable et la marche à suivre pour revenir à la version précédente en cas de problème. Ne publiez pas `phpinfo()` : cette page peut révéler des informations sensibles. Utilisez l’inventaire interne ou les outils autorisés du fournisseur.
Lisez les notes du fournisseur et le guide de migration si vous changez de branche PHP. Prévoyez une fenêtre de maintenance, une sauvegarde restaurable et une marche arrière claire. Pour un service géré, demandez confirmation de la version et du redémarrage ou redéploiement nécessaire.
Mettre à jour sans perdre le fil
- Commencez par les services accessibles depuis Internet et vérifiez si le fournisseur propose le paquet corrigé.
- Mettez à jour un environnement représentatif en suivant les consignes du système, de l’hébergeur ou de l’image.
- Reconstruisez et redéployez les conteneurs depuis une image corrigée : mettre à jour l’hôte ne change pas PHP dans l’image.
- Redémarrez ou remplacez les processus PHP selon les consignes du fournisseur pour qu’ils chargent la nouvelle version.
- Confirmez la version dans l’environnement qui reçoit réellement le trafic.
- Faites les vérifications de base et les tests de régression prioritaires.
- Pendant la période convenue, surveillez les erreurs, les journaux et les indicateurs.
- Si un point critique échoue, arrêtez le déploiement, notez ce qui s’est passé et revenez à la version précédente selon le plan prévu. Un WAF ou une règle temporaire ne remplace pas le correctif.
- 01Inventorier PHP
- 02Appliquer le correctif
- 03Confirmer les processus actifs
- 04Tester les parcours
- 05Examiner les résultats
- 06Décider du déploiement
Préparer les tests de régression
Après une mise à jour, les tests de régression cherchent les effets inattendus dans l’application et ses intégrations. Ils ne prouvent pas que PHP ne présente plus de vulnérabilité et ne remplacent pas l’analyse de sécurité, des dépendances ou de la configuration.
Délimitez le changement : version de PHP, services, configuration, extensions, dépendances et environnements. Repérez les parcours qui utilisent PHP et les composants qui partagent processus, sessions, cache, fichiers ou files d’attente. Donnez la priorité à l’impact métier, à l’exposition et à la difficulté de retour arrière. Notez les dépendances inconnues comme des risques à vérifier.
Organisez les tests en trois niveaux : vérifications de base, tests ciblés sur les parcours touchés et suite plus large pour les composants les plus importants. Conservez la version, l’environnement et les données utilisées pour pouvoir comprendre et reproduire les résultats.
Exemples de cas de test
Adaptez ces exemples à votre architecture et à vos règles. Ils ne forment pas un jeu de tests universel : retirez ce qui ne s’applique pas et ajoutez vos parcours, extensions et intégrations. Utilisez des comptes de test et des données fictives, jamais de secrets ou de données personnelles réelles.
| Domaine | Exemple | À vérifier | Preuve utile |
|---|---|---|---|
| Disponibilité | Démarrage, état de santé et page principale | Processus actif et réponse attendue | Version, environnement, heure et journal expurgé |
| Connexion | Connexion, déconnexion et expiration | Session valide et fin de session | Compte fictif et résultat ; jamais de mot de passe |
| Droits | Accès autorisé ou refusé selon le rôle | Permissions et refus des accès interdits | Rôle, ressource et résultat observé |
| Formulaires | Créer ou modifier une donnée importante | Validation, enregistrement et règles métier | Données fictives et capture expurgée |
| API | Réponses de succès, erreur et délai dépassé | Code, champs, authentification et erreurs | Requête et réponse nettoyées |
| Fichiers | Envoyer, lire et télécharger un fichier | Type, taille, stockage et droits | Fichier fictif et résultat |
| Tâches en arrière-plan | File, tâche planifiée et nouvel essai | État final et traitement des erreurs | Identifiant, horaires et sortie expurgée |
| Données et sessions | Conservation entre requêtes et processus | Cohérence et séparation entre utilisateurs | Identifiants fictifs et état avant/après |
Quand les tests sont-ils terminés ?
Définissez avant de commencer les échecs qui empêchent le déploiement. Ne continuez pas si la connexion, les droits, une opération importante, les données ou une intégration essentielle ne fonctionnent pas, si la version corrigée ne peut pas être confirmée ou si de nouvelles erreurs restent inexpliquées. Un test bloqué par l’environnement ne compte pas comme réussi.
À la fin, comparez les résultats au périmètre prévu. Examinez les échecs, blocages, tâches en attente, preuves et risques restants. Une suite entièrement réussie ne décrit que les tests exécutés ; elle ne prouve pas que tous les serveurs ont été corrigés.
Liste de contrôle
- L’inventaire couvre serveurs, conteneurs et services du fournisseur.
- L’origine du paquet et l’avis utilisé sont consignés.
- Les processus qui reçoivent le trafic ont été redémarrés comme prévu.
- Version, environnement et données fictives sont indiqués.
- Les échecs, blocages et risques ont un responsable.
- Les secrets et données personnelles ont été retirés des preuves.
Conserver des preuves faciles à relire
Treseko permet d’organiser les cas, suites, versions, exécutions, résultats, défauts et pièces jointes. L’équipe doit configurer et exécuter les tests dans son propre environnement. Treseko n’installe pas le correctif et ne détecte pas automatiquement toutes les installations PHP.
Sources officielles et ressources utiles
- Avis de sécurité officiel de PHP
- Avis CVE-2026-109618 (PHP/GitHub)
- Avis CVE-2026-109619 (PHP/GitHub)
- Branches PHP prises en charge
- Téléchargements officiels de PHP
- Guide officiel de migration vers PHP 8.5
Ce guide est un contenu pédagogique QA. Il ne remplace pas les consignes de PHP, du système, du conteneur ou de l’hébergeur. Dernière révision : 21 octobre 2026.