Deux failles critiques dans PHP : votre site est-il concerné et que faire ?

Ce qui a été confirmé le 21 octobre

Le 20 octobre, l’équipe de sécurité de PHP a annoncé deux failles critiques, CVE-2026-109618 et CVE-2026-109619, chacune évaluée à 9,2 sur 10 selon CVSS 4.0. Le lendemain, elle a publié ses correctifs et son avis de sécurité. Les deux vulnérabilités peuvent permettre une exécution de code à distance sans authentification dans certaines conditions.

Les versions officielles corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. L’équipe PHP appelle les exploitants de sites à mettre à jour rapidement. Les fournisseurs Linux et les prestataires de support longue durée peuvent également proposer des paquets corrigés ou des correctifs rétroportés : dans ce cas, le numéro affiché ne raconte pas toujours toute l’histoire.

Le risque dépend de l’installation et de la configuration du serveur. L’avis PHP considère que les installations servant des requêtes web sont concernées et signale un risque particulièrement élevé avec mod_php. Une faille critique ne signifie pas que tous les sites PHP ont été compromis. Elle justifie une vérification et une mise à jour prioritaires.

Mise à jour éditoriale du 21 octobre 2026 : les correctifs sont désormais publiés. Cet article ne reprend donc pas les recommandations provisoires formulées avant leur sortie comme si elles constituaient encore la solution principale.

Pourquoi WordPress est concerné, sans être la cause de la faille

WordPress est un logiciel de gestion de contenu ; PHP est le moteur exécuté sur le serveur pour le faire fonctionner. WooCommerce repose sur WordPress et PHP. PrestaShop, Drupal, Joomla et les applications développées avec Laravel ou Symfony utilisent également PHP.

Un WordPress dont le cœur, les thèmes et les extensions sont à jour peut donc rester exposé si la version de PHP fournie par l’hébergement ne contient pas le correctif. À l’inverse, corriger PHP ne dispense pas de maintenir WordPress et ses extensions. Ce sont deux couches de sécurité distinctes.

Cliquer sur « Mettre à jour » dans l’administration WordPress ne met pas automatiquement le moteur PHP du serveur à jour.

Qui doit installer le correctif PHP ?

La réponse dépend de votre formule d’hébergement et de votre contrat de maintenance.

• Hébergement mutualisé : l’hébergeur gère l’infrastructure et les versions proposées. Vérifiez la version réellement utilisée par votre site et demandez au support si les correctifs du 21 octobre sont appliqués. Ne présumez pas que le correctif arrive immédiatement sur tous les serveurs.
• WordPress entièrement infogéré : le fournisseur prend normalement en charge l’environnement serveur. Consultez ses communications et demandez une confirmation pour votre offre et votre site.
• VPS ou serveur dédié : si vous administrez le serveur, la mise à jour vous revient, sauf si un contrat d’infogérance la confie à un prestataire. Elle doit suivre les paquets et consignes de votre distribution ou fournisseur.

La question utile à transmettre au support est précise : « Mon site utilise PHP [version]. Les correctifs de CVE-2026-109618 et CVE-2026-109619 sont-ils installés sur l’environnement qui exécute ce site ? Si oui, par quelle version ou quel correctif rétroporté ? »

Comment vérifier votre version PHP

Dans WordPress, ouvrez Outils → Santé du site → Informations → Serveur. La documentation WordPress confirme que cet écran indique la version PHP utilisée par le site. Notez le numéro complet, par exemple 8.4.26, et non seulement « PHP 8.4 ».

Chez Hostinger, la page Info PHP du hPanel présente également la configuration du site, dont sa version PHP. Le centre d’aide Hostinger décrit ce parcours. Vérifiez bien le site concerné : plusieurs domaines ou sous-domaines peuvent avoir des réglages distincts.

Comparez ensuite ce que vous voyez avec les versions corrigées officielles. Si votre hébergeur applique un correctif rétroporté, la version affichée peut ne pas suffire à conclure : demandez-lui confirmation. Évitez de publier une page phpinfo() accessible à tous pour effectuer cette vérification.

Faut-il changer immédiatement de branche PHP ?

Pas nécessairement. Passer de PHP 8.3.35 à 8.3.36 applique le correctif sans imposer une migration vers PHP 8.4 ou 8.5. Les branches 8.2, 8.3, 8.4 et 8.5 reçoivent encore des correctifs de sécurité de l’équipe PHP au 21 octobre 2026. PHP 8.2 arrive toutefois en fin de support officiel le 31 décembre 2026 : une migration doit donc être planifiée.

PHP 8.1 et les branches antérieures ne reçoivent plus de versions officielles de l’équipe PHP. Certains fournisseurs assurent un support prolongé ou des correctifs rétroportés, mais il faut en vérifier la réalité et préparer la migration. Choisir brutalement la branche la plus récente sans tester le site peut casser un thème, une extension ou du code sur mesure.

La priorité est une version effectivement corrigée et compatible avec le site, pas simplement le numéro de branche le plus élevé.

Que faire si le correctif n’est pas encore disponible chez vous ?

L’équipe PHP détaille des mesures de réduction du risque propres à chaque vulnérabilité, mais précise qu’aucune ne sécurise complètement une installation non corrigée. Certaines exigent de modifier la configuration du serveur et de redémarrer les processus PHP ; elles ne doivent pas être appliquées à l’aveugle depuis un panneau WordPress.

Contactez l’hébergeur ou l’administrateur chargé du serveur, faites confirmer son calendrier de correction et vérifiez vos sauvegardes. Pour un environnement sensible impossible à corriger rapidement, le CERT-EU recommande d’envisager un isolement temporaire des applications exposées à Internet.

Une extension de sécurité WordPress ou un pare-feu applicatif peut bloquer certaines requêtes, mais ne remplace pas l’installation du correctif PHP.

Cinq vérifications à effectuer maintenant

1. Identifier le responsable de la maintenance de PHP : hébergeur, infogérant ou votre propre équipe.
2. Relever la version exacte utilisée par chaque site ou environnement public.
3. Vérifier la correction effective : PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou correctif fournisseur confirmé.
4. Demander une réponse écrite au support si la version affichée ou le mode de déploiement reste ambigu.
5. Contrôler sauvegardes et fonctionnement après l’intervention : pages, formulaires, connexion, commandes et autres fonctions essentielles.

Questions fréquentes

Mon WordPress est à jour. Est-il automatiquement protégé ?

Non. Les mises à jour WordPress et les correctifs du moteur PHP sont indépendants.

Mon hébergeur fera-t-il la mise à jour automatiquement ?

Cela dépend de son offre, de son infrastructure et parfois de la version PHP sélectionnée pour votre site. Seule une vérification de l’environnement ou une confirmation du fournisseur permet de le savoir.

Une extension de sécurité suffit-elle ?

Non. Elle peut réduire certaines tentatives d’exploitation, mais elle ne corrige pas le code de PHP.

La découverte de ces failles signifie-t-elle que mon site a été piraté ?

Non. Vulnérabilité et compromission sont deux choses différentes. Si vous observez un comportement suspect, demandez une investigation adaptée et conservez les éléments utiles à l’analyse.

La sécurité d’un site ne s’arrête pas à son administration

Cette alerte rappelle qu’un site dépend de plusieurs couches : son CMS, ses extensions, son code, PHP et l’hébergement. Les responsabilités peuvent être partagées, mais elles doivent être claires.

Chez Avenue du Web, j’encourage une démarche simple : identifier la version réellement exécutée, savoir qui la maintient et obtenir confirmation que les correctifs sont en place. Si vous avez besoin d’aide pour comprendre votre environnement, parlons de votre site.

Sources consultées le 21 octobre 2026 : équipe de sécurité PHP et versions corrigées, versions PHP maintenues, CERT-EU, CERT-FR, documentation WordPress et documentation Hostinger.