Le 21 octobre 2026, PHP a publié un avis officiel de sécurité et des mises à jour urgentes. Si votre entreprise utilise PHP, vérifiez les versions réellement exécutées et le responsable de chaque installation.
Ce guide a été vérifié le 23 octobre 2026. La priorité est d’appliquer le correctif, puis de lever les obstacles à la maintenance régulière.
Que s’est-il passé ?
CVE-2026-109618 concerne une corruption mémoire lors du traitement d’un manque de mémoire. CVE-2026-109619 concerne un état interne périmé entre les requêtes. Ces failles peuvent permettre une exécution de code à distance sans authentification.
Elles concernent l’environnement PHP. Mettre à jour uniquement le CMS ou ses extensions ne remplace pas le correctif du serveur, comme le précise le communiqué WordPress.
Comment corriger les failles
1. Recenser les installations PHP
Listez sites, boutiques, portails, API, conteneurs et outils internes. Notez fournisseur, responsable, version et exposition à Internet. Commencez par les systèmes publics.
Sur un serveur autogéré, php -v affiche la version en ligne de commande. Le site peut utiliser une autre version : vérifiez également le pool PHP-FPM, le module Apache ou l’image du conteneur servant les requêtes. Évitez de publier un fichier phpinfo() accessible sur Internet.
En hébergement géré, demandez confirmation du correctif pour chaque site. WordPress indique la version web dans Outils → Santé du site → Informations → Serveur, comme décrit dans son communiqué.
2. Identifier la mise à jour adaptée
L’avis PHP donne les versions corrigées suivantes :
| Branche | Version corrigée |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Installez cette version ou une version ultérieure de la même branche incluant les correctifs. Si votre distribution fournit des correctifs rétroportés, vérifiez son bulletin, la révision complète du paquet et la couverture des deux CVE. Le numéro de base ne suffit pas.
PHP 8.1 et les branches antérieures ne bénéficient plus du support du projet. Vérifiez si votre fournisseur propose une correction maintenue et préparez une migration vers une branche supportée.
3. Préparer la reprise et vérifier la compatibilité
Conservez une sauvegarde vérifiée des données, fichiers et configurations avec accès restreint. Désignez le responsable et la procédure de reprise. Testez connexion, commandes, paiements, formulaires et intégrations dans un environnement de test.
Préparez cette intervention sans prolonger l’exposition. Si le correctif ne peut être appliqué immédiatement, CERT-EU recommande d’envisager l’isolement des applications publiques. Une page de maintenance exécutée par PHP ne suffit pas à isoler le serveur vulnérable.
4. Mettre à jour tous les environnements concernés
Utilisez les paquets corrigés de votre distribution, le panneau d’hébergement ou une image de conteneur reconstruite et mise à jour. Incluez les extensions nécessaires et toutes les répliques servant du trafic. Il n’existe pas de commande universelle : la procédure dépend du système, du dépôt et de la branche installée.
Redémarrez ou remplacez tous les processus PHP chargeant encore l’ancien environnement. La seule mise à jour des fichiers sur disque peut laisser le service actif inchangé.
5. Vérifier le service réel
Confirmez la version ou révision corrigée dans l’environnement web effectif. Rejouez les processus critiques et examinez erreurs HTTP, journaux PHP et files de tâches. Documentez paquet, date et résultat pour chaque serveur ou conteneur.
Si une incompatibilité impose un retour arrière, gardez le service isolé plutôt que de réexposer une version vulnérable.
6. Rechercher des signes d’intrusion
Le correctif ne répare pas une compromission antérieure. Examinez fichiers inattendus, accès administratifs, processus et connexions inhabituels. En présence d’indices, activez la réponse à incident, préservez les preuves et renouvelez les identifiants concernés depuis un environnement fiable.
Les réglages temporaires et filtres WAF ne remplacent pas la mise à jour. L’avis PHP explique leurs limites ; évaluez les effets opérationnels avant de modifier la mémoire ou la configuration.
Quand la mise à jour révèle un problème de legacy
Si une mise à niveau casse l’application, inventoriez les dépendances, ajoutez des tests métier et préparez une migration progressive avec critères d’acceptation et retour arrière.
Codefuente propose la modernisation des applications : mises à niveau des environnements et frameworks, refactorisation, migration des données et intégrations, puis maintenance. Cette démarche réduit la dette technique et facilite les futurs correctifs sans garantir l’absence de nouvelles vulnérabilités.
Notre service de cybersécurité complète ce travail avec revue des accès, protection des systèmes et sauvegarde et reprise en complément, avec isolation, rétention et tests de restauration.
Présentez-nous l’application à mettre à jour pour définir un plan adapté à ses dépendances et à son rôle métier.