Faille PHP : pourquoi le correctif dépend aussi de votre hébergeur

Pour corriger une vulnérabilité de PHP, mettre à jour WordPress, Drupal ou un autre CMS ne suffit pas nécessairement : le correctif doit concerner l’environnement PHP qui traite les requêtes du site. Cette distinction est importante pour les vulnérabilités CVE-2026-109618 et CVE-2026-109619, signalées en octobre 2026. Les versions corrigées et la marche à suivre diffèrent selon la façon dont le serveur est administré.

Les deux failles permettent, selon les comptes rendus publiés, l’exécution de code à distance sans authentification. La difficulté n’est donc pas seulement de savoir si un site utilise PHP, mais d’identifier où et par qui cette couche logicielle est mise à jour. Pour un hébergement administré, le premier interlocuteur est le prestataire ; sur un serveur autogéré, l’intervention revient à l’équipe qui gère les mises à jour et les services concernés.

Une faille PHP ne se corrige pas comme une faille de CMS

Un CMS est un logiciel installé sur le serveur. PHP, lui, est le langage et l’environnement qui exécutent une partie du code du site. Actualiser le CMS et actualiser PHP sont donc deux opérations distinctes.

Dans son compte rendu, Ginjfo précise que le correctif PHP ne se résume pas à une mise à jour du CMS et que plusieurs modes d’exécution sont concernés, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

Cette portée explique pourquoi changer de logiciel de site ou de serveur web ne permet pas, à lui seul, de conclure que le risque est écarté. Il faut connaître la version de PHP réellement utilisée et vérifier qu’elle a reçu le correctif.

La PHP Foundation, citée par Futura, souligne aussi la place centrale des mécanismes concernés dans PHP et la difficulté de les corriger sans affecter la compatibilité, les performances ou les extensions tierces. Autrement dit, la correction doit être apportée au bon niveau, puis rester compatible avec le reste de l’installation.

Deux situations d’administration, deux chemins de vérification

Configuration	Vérification utile	Point d’attention
Hébergement administré par un prestataire	Demander si le correctif PHP a été déployé sur l’environnement du site.	Ne pas déduire l’état de PHP de la seule mise à jour du CMS.
Serveur autogéré	Vérifier les mises à jour proposées par le fournisseur de PHP ou la distribution utilisée.	Appliquer le correctif puis redémarrer les services concernés lorsque c’est nécessaire.
Ancienne branche de PHP	Vérifier si un correctif est fourni pour la branche ou par le prestataire concerné.	Une mise à niveau ou un rétroportage peut demander une intervention spécifique.

Ce comparatif ne remplace pas une vérification technique : il aide à déterminer qui doit la faire. Pour un site hébergé, la question à poser est précise : quelle version de PHP exécute ce site, et le correctif correspondant est-il déployé ? Ginjfo recommande aux utilisateurs d’un hébergement administré de s’en assurer auprès de leur prestataire. Sur un serveur autogéré, l’article indique de passer par les mises à jour du fournisseur et de redémarrer les services concernés lorsque cela est nécessaire.

Les numéros de version à contrôler

Les correctifs mentionnés par Ginjfo sont intégrés aux versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. La version attendue dépend donc de la branche utilisée : il ne suffit pas de retenir un seul numéro ni de supposer que toute mise à jour récente est la bonne. Les administrateurs doivent comparer la version effectivement installée avec la branche et le correctif correspondant.

La situation est plus délicate pour les branches anciennes. Futura rapporte que les failles remontent au moins à PHP 5.4 et que PHP.net a aussi publié du code de rétroportage pour PHP 7.4, 8.0 et 8.1.

Cela ne signifie pas que chaque installation ancienne reçoit automatiquement ce correctif : selon le compte rendu, les administrateurs concernés doivent compiler les correctifs eux-mêmes ou attendre qu’une distribution Linux ou un dépôt tiers les fournisse. Le chemin de mise à jour dépend donc aussi de la manière dont PHP a été installé et maintenu.

Pourquoi le calendrier compte

La divulgation publique ne marque pas forcément le début du risque. Futura rapporte qu’Amazon avait détecté une attaque exploitant ces vulnérabilités le 17 octobre 2026, avant l’annonce publique du 21 octobre, et que d’autres attaques avaient ensuite été relevées. Cette chronologie, telle que rapportée par le média, explique pourquoi les administrateurs ne peuvent pas attendre une prochaine mise à jour de leur CMS pour vérifier PHP.

Le même compte rendu relève un obstacle moins visible : certains sites anciens dépendent de scripts ou d’extensions qui peuvent être incompatibles avec les versions récentes. Le propriétaire peut ne plus connaître tous les composants en place, ne pas avoir les compétences nécessaires pour intervenir ou ne pas disposer des accès à l’hébergement. Une mise à jour disponible ne garantit donc pas, à elle seule, qu’elle soit appliquée partout sans préparation.

Une vérification courte, mais au bon niveau

1. Identifier la version de PHP qui exécute le site, plutôt que de se fier à la version affichée par le CMS.
2. Déterminer qui administre cette installation : l’équipe du site, l’hébergeur ou un autre prestataire.
3. Comparer la branche utilisée aux versions corrigées indiquées pour PHP.
4. Pour une branche ancienne, demander explicitement si un correctif ou un rétroportage est disponible et qui doit l’appliquer.
5. Après intervention, confirmer que le correctif concerne bien l’environnement PHP du site et que les services concernés ont été redémarrés lorsque c’est nécessaire.

Ces vulnérabilités illustrent aussi une différence entre une faille dans une infrastructure partagée et une attaque visant un seul service. Le décryptage du piratage de la DGFiP porte sur un autre enchaînement de faiblesses ; il permet de comparer des enjeux de sécurité sans confondre les incidents ni leurs mécanismes.

Pour les responsables de sites, la priorité pratique est de faire confirmer la version PHP et le déploiement du correctif par la personne qui maîtrise l’hébergement. Pour les lecteurs, cette distinction aide à comprendre pourquoi un site peut rester exposé même si son interface ou son CMS paraît à jour. Les versions et recommandations citées ici correspondent aux informations publiées en octobre 2026 ; l’état d’une installation donnée doit être confirmé auprès de son administrateur ou de son hébergeur.

Sources : Alerte sur le Web : une IA vient de découvrir deux failles majeures que les pirates exploitent déjà.