Un site qui fonctionne normalement peut utiliser une version vulnérable. À l’inverse, une page de maintenance ne prouve pas qu’un piratage a eu lieu. Cette alerte impose de distinguer trois situations : l’exposition à une faille, une interruption préventive et une compromission confirmée.
Failles PHP du 21 octobre 2026 : ce qui a été corrigé
Dans son avis de sécurité officiel sur les vulnérabilités PHP, l’équipe du langage appelle les utilisateurs concernés à mettre à jour immédiatement leurs installations.
Les deux vulnérabilités sont classées critiques, avec un score CVSS v4.0 de 9,2 sur 10. Elles touchent le fonctionnement interne de PHP, le langage exécuté sur le serveur pour produire les pages et traiter les demandes de nombreuses applications web.
Leur impact potentiel est une exécution de code avec les droits du processus web. Selon les permissions de ce dernier, une exploitation pourrait permettre de modifier des fichiers ou d’accéder à des informations de l’application. Cela ne signifie pas automatiquement un contrôle administrateur de toute la machine.
CVE-2026-109618 : une corruption de mémoire
La première vulnérabilité concerne la gestion des situations où PHP manque de mémoire. Une interruption peut laisser certaines données internes dans un état incomplet, puis provoquer un traitement incorrect lors du nettoyage de la requête.
CVE-2026-109619 : un état interne réutilisé à tort
La seconde concerne des informations internes qui peuvent subsister après la libération de la mémoire associée. Une requête ultérieure, traitée par le même processus, peut réutiliser cet état devenu invalide.
Pour un propriétaire de site, l’essentiel est opérationnel : ces défauts concernent PHP lui-même. La correction doit donc atteindre l’environnement qui exécute l’application.
Quelles versions de PHP faut-il mettre à jour ?
Les versions corrigées publiées le 21 octobre sont les suivantes :
| Branche PHP | Versions concernées dans la branche | Version corrigée |
|---|---|---|
| PHP 8.5 | Antérieures à 8.5.12 | 8.5.12 |
| PHP 8.4 | Antérieures à 8.4.27 | 8.4.27 |
| PHP 8.3 | Antérieures à 8.3.36 | 8.3.36 |
| PHP 8.2 | Antérieures à 8.2.35 | 8.2.35 |
PHP 8.1 et les branches plus anciennes ne bénéficient plus du support standard du projet. Certains fournisseurs proposent des correctifs spécifiques ; des adaptations minimales du code source existent aussi pour certaines anciennes branches. Cela ne constitue pas une reprise de leur maintenance normale. Une migration vers une branche maintenue reste à organiser.
WordPress est-il concerné par ces failles PHP ?
Un site WordPress peut être exposé si son environnement PHP est vulnérable. La mise à jour de WordPress, des thèmes ou des extensions ne remplace pas le correctif PHP.La documentation officielle sur la mise à jour de PHP pour WordPress rappelle que cette version est gérée au niveau du serveur, généralement par l’hébergeur.
La même vérification doit être menée pour les boutiques en ligne, les intranets et les applications métier qui reposent sur PHP. Le nom du logiciel utilisé ne permet pas, à lui seul, de connaître l’état de protection de son serveur.
Pour WordPress, la rubrique « Santé du site », puis les informations du serveur, peut aider à relever la version utilisée. Cette indication doit être rapprochée des informations de sécurité de l’hébergeur.
Que demander immédiatement à son hébergeur ?
Pour un dirigeant de TPE ou de PME, l’action la plus utile consiste à obtenir une réponse précise du prestataire responsable du serveur.
Voici les questions à lui transmettre :
- Quelle version de PHP exécute réellement mon site ?
- Les correctifs des CVE-2026-109618 et CVE-2026-109619 sont-ils appliqués ?
- La correction concerne-t-elle tous mes sites et environnements, y compris la préproduction ?
- Les processus concernés ont-ils été relancés pour charger la version corrigée ?
- Quelles vérifications de fonctionnement et de sécurité ont été réalisées ?
Une réponse indiquant seulement que « le site est à jour » reste insuffisante si elle porte uniquement sur le CMS. Demandez une confirmation concernant PHP et les deux identifiants de vulnérabilité.
Comment appliquer la mise à jour sans bloquer son activité ?
Si l’hébergement est administré par un prestataire, faites-lui confirmer le déploiement du correctif. Si votre équipe gère le serveur, elle doit suivre la procédure de son fournisseur et vérifier la version effectivement utilisée par le service web.
Avant une migration vers une autre branche PHP, prévoyez une sauvegarde exploitable et une vérification de compatibilité. Après intervention, testez les fonctions qui font vivre l’activité : connexion, formulaires, commande, paiement, téléversement de fichiers et accès à l’administration.
Un contrôle de la seule page d’accueil ne suffit pas à valider une boutique ou une application métier.
Faut-il mettre son site hors ligne ?
Le CERT-EU recommande de corriger immédiatement les installations PHP affectées. Lorsque cela n’est pas possible, il préconise d’envisager l’isolement des applications exposées à Internet jusqu’à l’application et à la vérification du correctif.
Une simple page de maintenance produite par l’application ne garantit pas cet isolement : PHP peut continuer à traiter des requêtes en arrière-plan. Le blocage doit être défini au niveau technique approprié avec l’administrateur ou l’hébergeur.
Les mesures temporaires de configuration décrites par les mainteneurs réduisent certaines possibilités d’attaque, mais ne remplacent pas la mise à jour.
Un site vulnérable a-t-il forcément été piraté ?
Non. Une vulnérabilité établit l’existence d’un risque, pas la preuve d’une intrusion sur chaque installation.
En cas de comportement inhabituel, faites examiner les journaux et les fichiers par le prestataire compétent. L’installation du correctif ferme les vulnérabilités concernées ; elle ne permet pas, à elle seule, d’écarter une compromission antérieure.
Pour les entreprises, le bon indicateur est donc une confirmation documentée du correctif, accompagnée des vérifications nécessaires au maintien de l’activité.
