Deux failles PHP critiques viennent de recevoir leur correctif ce 21 octobre 2026. Si ton WordPress fonctionne encore, cela ne dit rien de sa protection : le problème concerne le moteur qui exécute le site. Voici comment identifier le bon interlocuteur, vérifier le correctif et éviter les fausses bonnes idées dans l’urgence.
Les références sont CVE-2026-109618 et CVE-2026-109619. Le projet PHP annonce une possibilité d’exécution de code à distance sans authentification dans certaines conditions. Pour un propriétaire de blog, la question utile est immédiate : quelle version sert réellement mes pages web, et son fournisseur a-t-il livré le correctif ?
Failles PHP critiques : quelles versions corrigées installer ?
Le bulletin officiel PHP du 21 octobre annonce les versions suivantes. Ce tableau concerne les versions publiées directement par PHP ; les distributions peuvent intégrer une correction dans leurs propres paquets.
| Branche utilisée | Version corrigée publiée le 21 octobre |
|---|---|
| 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 précise que les installations traitant des requêtes web sont concernées. Cela inclut PHP-FPM et Apache avec mod_php. Une installation différente d’Apache ne constitue donc pas, à elle seule, une preuve de protection. Le projet souligne également qu’une mise à jour représente la seule solution complète.
Ce que changent ces failles PHP critiques pour WordPress
WordPress, le thème, les extensions, PHP et le serveur web forment plusieurs couches. Mettre une extension à jour ne remplace pas le correctif du moteur PHP. Inversement, corriger PHP ne dispense pas de maintenir les autres composants. Cette distinction évite de cliquer sur toutes les mises à jour du tableau de bord en croyant avoir traité l’alerte.
La PHP Foundation explique les deux mécanismes : l’un concerne la gestion d’un manque de mémoire, l’autre un état interne conservé après la libération de sa mémoire. Elle décrit notamment des scénarios d’exécution de code démontrés. Il ne s’agit pas simplement d’un avertissement cosmétique dans les journaux.
Pour autant, l’existence de ces failles ne prouve pas que ton site a été compromis. Il faut distinguer une exposition possible, un correctif installé et une intrusion constatée. Aucun de ces trois états ne se déduit automatiquement des deux autres.
Hébergement mutualisé : poser une question précise
Si un hébergeur administre le serveur, demande-lui une confirmation sur le domaine concerné. Le message peut rester simple : « La version PHP qui sert mon site intègre-t-elle les correctifs CVE-2026-109618 et CVE-2026-109619 ? Quelle version de paquet est déployée et les processus ont-ils été redémarrés ? »
Une réponse comme « nous utilisons PHP 8.4 » manque de précision. Elle indique une branche, pas son niveau de correction. À l’inverse, un numéro qui semble ancien peut correspondre à un paquet maintenu par une distribution avec des correctifs rétroportés. Il faut alors obtenir le bulletin du fournisseur et sa référence de paquet.
Ne publie pas une page phpinfo accessible à tous pour obtenir cette réponse. Elle peut exposer des informations de configuration inutiles aux visiteurs. L’outil de santé WordPress ou le panneau de l’hébergeur permet un premier relevé ; la confirmation du paquet reste du ressort de l’administrateur.
Serveur auto-hébergé : vérifier le PHP du site, pas seulement le terminal
Sur une machine administrée soi-même, la commande qui affiche PHP dans un terminal ne désigne pas forcément la version utilisée par le site. Plusieurs branches, pools PHP-FPM ou conteneurs peuvent coexister. Note le domaine, le service qui le traite et la provenance du paquet avant d’agir.
Ensuite, vérifie la disponibilité du correctif dans le dépôt réellement utilisé. Applique la procédure de maintenance de ce fournisseur, puis contrôle le redémarrage des services concernés. Une page publique qui répond à nouveau ne suffit pas : il faut aussi vérifier que les processus actifs utilisent bien la version corrigée.
Je recommande de garder une trace courte : version avant intervention, paquet installé, heure de redémarrage et contrôles après intervention. Cette trace servira beaucoup plus qu’une capture rassurante d’un voyant vert. Pour préparer la maintenance, le guide BlackFury sur la migration Debian et PHP d’un WordPress détaille les dépendances à inventorier.
Failles PHP critiques : ne pas confondre atténuation et garantie
Le bulletin PHP présente des mesures qui réduisent certains chemins d’attaque, mais indique qu’elles ne rendent pas une installation sûre. Copier un réglage trouvé sur un réseau social puis annoncer « problème résolu » serait donc trompeur. Ces mesures demandent en outre de comprendre les limites mémoire, le traitement des requêtes et les processus du serveur.
Si le correctif n’est pas encore accessible, fais décider la mesure temporaire par l’administrateur ou l’hébergeur à partir de l’avis officiel. Évite de mélanger plusieurs recettes sans connaître leurs effets sur la disponibilité. Ne teste pas une démonstration d’exploitation contre ton serveur de production pour te rassurer.
Après le correctif : cinq vérifications concrètes
- Confirmer le paquet corrigé auprès du fournisseur et la version PHP qui sert le domaine.
- Vérifier que tous les processus concernés ont repris avec le correctif.
- Tester l’accueil, une page article, la connexion et les fonctions essentielles, dont les formulaires.
- Examiner les journaux et les alertes de sécurité en cas de comportement inhabituel.
- Conserver les preuves de maintenance et vérifier la disponibilité d’une sauvegarde restaurable.
Si des indices de compromission apparaissent, la mise à jour seule ne permet pas de conclure que les fichiers et les accès sont sains. Il faut ouvrir une investigation adaptée et préserver les éléments utiles. Pour préparer une intervention, mon guide du plan de retour arrière WordPress aide à organiser les vérifications sans confondre sauvegarde et sécurité.
Mon avis : demander une preuve plutôt qu’une promesse
Dans une alerte de ce type, l’urgence doit produire une action vérifiable. Un numéro de paquet, un service redémarré et un test du site constituent des preuves concrètes. La mention « hébergement sécurisé » sur une page commerciale ne permet pas de savoir si cette intervention a été faite.
Le bon réflexe reste donc de joindre la personne qui administre PHP, d’obtenir la confirmation du correctif pour son site et de contrôler le résultat. Cet article est une synthèse documentaire des annonces officielles vérifiées le 21 octobre 2026, pas le compte rendu d’un test d’exploitation. Il ne prétend pas non plus confirmer l’état de protection de chaque hébergement.
