Deux vulnérabilités critiques de PHP peuvent permettre l’exécution de code à distance sans authentification. Les correctifs sont disponibles, et certaines indisponibilités observées le 21 octobre correspondaient à des coupures préventives pendant leur déploiement.
Deux vulnérabilités critiques ont été corrigées dans PHP, un composant utilisé par de nombreux sites et applications web. Elles peuvent permettre à un attaquant d’exécuter du code sur un serveur vulnérable sans devoir s’authentifier.
Les correctifs sont désormais disponibles. L’urgence a conduit plusieurs hébergeurs et organisations à interrompre temporairement certains services, le temps d’appliquer les mises à jour, de redémarrer les composants concernés et de vérifier le résultat. Voilà pourquoi plusieurs sites ont pu être indisponibles le 21 octobre.
Il est toutefois important de préciser le lien de cause à effet : ces indisponibilités étaient, dans plusieurs cas documentés, des mesures de protection ou des fenêtres de maintenance. Elles ne signifient pas automatiquement qu’un site a été attaqué, ni que la mise à jour a provoqué une panne.
Quelles vulnérabilités ont été corrigées ?
Les vulnérabilités CVE-2026-109618 et CVE-2026-109619 ont toutes deux reçu une note de 9,2 sur 10 selon CVSS v4.0. Elles touchent le fonctionnement interne de PHP et peuvent mener à une exécution de code à distance sans authentification.
Le projet PHP demande une mise à jour immédiate vers l’une des versions corrigées suivantes :
- PHP 8.5.12 ;
- PHP 8.4.27 ;
- PHP 8.3.36 ;
- PHP 8.2.35.
PHP 8.1 et les versions antérieures ne sont plus maintenues directement par le projet PHP. Certains fournisseurs de distributions Linux ou de support à long terme peuvent cependant proposer des correctifs rétroportés. Dans ce cas, le numéro de version affiché ne suffit pas : il faut vérifier le paquet exact et l’avis de sécurité du fournisseur.
Pourquoi certains sites ont-ils été temporairement arrêtés ?
Lorsqu’une vulnérabilité critique est rendue publique, les responsables doivent arbitrer entre continuité de service et exposition au risque. Si le correctif ne peut pas être appliqué immédiatement, l’Office fédéral de la cybersécurité recommande d’évaluer une déconnexion temporaire d’Internet ou une mise hors service de l’application concernée.
Plusieurs opérateurs ont suivi cette logique. Des services de l’administration néerlandaise et des outils de l’écosystème Wikimedia ont notamment été arrêtés par précaution. Open LMS a remis ses sites clients en ligne au fur et à mesure de leur correction et indiquait, le 21 octobre au soir, que la grande majorité était de nouveau disponible.
Une mise à jour PHP peut également nécessiter le redémarrage de PHP-FPM ou d’Apache, voire la reconstruction et le redéploiement de conteneurs. Sur une plateforme redondante, ces opérations peuvent être réalisées sans interruption visible. Sur une architecture plus simple ou plus ancienne, une courte fenêtre de maintenance peut être nécessaire.
Un site WordPress est-il automatiquement vulnérable ?
WordPress, Drupal, Joomla, Magento et de nombreuses autres applications utilisent PHP. La faille se situe toutefois dans PHP, pas dans ces applications elles-mêmes.
Le risque dépend donc de la version réellement exécutée par le serveur, du paquet fourni par l’hébergeur et de l’architecture utilisée. Une mise à jour du logiciel de gestion de contenu ne remplace pas la correction de PHP. Pour un hébergement géré, il convient de demander une confirmation claire à l’hébergeur.
Que faut-il vérifier maintenant ?
- Inventorier les sites, applications, interfaces d’administration, conteneurs et équipements qui utilisent PHP.
- Traiter en premier les services accessibles depuis Internet et ceux qui manipulent des données sensibles.
- Installer le correctif fourni par PHP, le système d’exploitation, l’hébergeur ou l’éditeur du produit.
- Redémarrer les processus PHP persistants et redéployer les conteneurs concernés.
- Confirmer la version ou le paquet réellement utilisé par le service en production.
- Examiner les journaux et les systèmes à la recherche de requêtes inhabituelles, de plantages, de fichiers modifiés ou de processus inattendus.
Les mesures transitoires proposées par les éditeurs peuvent réduire certains chemins d’attaque, mais elles ne remplacent pas la mise à jour.
La disponibilité fait aussi partie de la sécurité
Une interruption courte, annoncée et maîtrisée peut éviter une exposition plus grave. L’objectif n’est pas de choisir entre sécurité et disponibilité, mais d’organiser les mises à jour de manière à protéger les données tout en réduisant l’impact pour les utilisateurs.
CIFERA peut accompagner les entreprises dans l’inventaire des services concernés, la coordination avec les hébergeurs, la planification de la maintenance et le contrôle après mise à jour.
Vous exploitez un site, une application métier ou une interface d’administration reposant sur PHP ? Vérifiez que le correctif est réellement actif. En cas de doute, CIFERA peut vous aider à faire le point avec votre hébergeur ou votre prestataire.
Sources : PHP, Office fédéral de la cybersécurité, ENISA, Gouvernement des Pays-Bas, Wikimedia Foundation et Open LMS. Informations vérifiées le 22 octobre 2026.